Ultimate Auto Mode Fail Safe Design: Logic inside PixHawk

Views: 673

Replies are closed for this discussion.

Replies to This Discussion

I t looks like you think about ArduCopter, and not to insult you, but it seems like you are not that familiar with it's current abilities or features.

There is no one-fits-all failsafe setting, so the user can, as is.

It would be easier if you had a specific scenario you don't think ArduCopter/Plane don't handle the way you wish.

+1 for effort of manual sketch :)

I like this idea. This would lead to the implementation of a workflow concept in Ardupilot where we could configure conditional links (a flow) between each individual failsafe triggers and actions. Currently in ardupilot you can only configure individual failsafes (on battery low, on radio loss, etc.) independently of each other. Your idea is about linking these failsafes with a flow and let the user configure this flow logic (with a drawing interface, like on your sheet of paper, would be nice).

Maybe a future feature in Ardupilot ?

While we're at it, here is two additional thoughts on failsafes:

  • add altitude into the quotation. A battery failsafe @ 500 Metres would need to come at a higher voltage than @ 20 Meters.
  • check feasability of an auto-mission e.g. total distance to fly vs. battery remaining. My setting is such that RC-LOS (Loss of signal) is ignored when in Auto-mode. If the pixhawk has an Auto-mission stored which is hundreds of miles away and I let somebody fly who accidently hits the Auto-button and I don't realize it before LOS - that copter will be a goner. I hence suggest the flight-stack checks feasability of any auto-mission it is tasked with and based on proper knowledge of performance refuses to switch into Auto if unable to complete by a wide margin.

Asim,

let us assume healthy batteries with the discharge curve we are accustomed to. If you want to cover a weak battery I propose to use FRSky MLVSS or FLVSS monitors for individual cells. While the Pixhawk (AFAIK) does not trigger on individual cell voltages, it will show on your Telemetry screen on the remote.

And why would you not put two Lipo in parallel if you decide to go with two (identical) batteries ? Once they are charged fully, they won't "bite" each other when connecting in parallel.

And please avoid switching over to a battery with lower voltage. Else you'd need to reset your PID to that environment, too.

somebody correct me if I am wrong, but AFAIK the Mavlink protocoll does provide for single cell monitoring:

However as for the GC I am not aware of any which will display single-cell voltage.

===

understand the logic for your secondary battery. Just apply a same xS, smaller Ah Battery with or without a failsafe-switch over (mind the inflight reboot) and consider the rule of thumb that in the multicopter world each gram of weight costs you one second of flight time.

===

for telemetry on your RC and GC you might want to consider one of the telemetry-over-gsm modules which are available. If you favor a stand-alone setup with good range, the RFD900+ module would be a candidate.

Asim,   For the ArduPilot Plane the plane transitions into "Circle" if GPS is lost.    Loiter requires GPS.    Circle does not, but the aircraft will drift with the wind. 

http://ardupilot.org/plane/docs/circle-mode.html#circle-mode

I accidentally tried this out recently when a trial RC receiver's telemetry transmission jammed the my autopilot GPS.      Apparently the Frsky X8R's telemetry transmit power increases as the distance from the RC Controller increases. 

There was nothing smooth about the failsafe though.    

there are a lot of variables at play here guys, I had this GPS glitch scenario too during AUTO mission and my quad landed on top of some trees as a result....BUT I wasnt supposed to be flying outside visual and RC range neither, then this wouldnt have happened....

you can only do so much about battery failsafe to return home, how about if you have a head wind on the return?? there goes all your calculation for remaining power right out the window.

what we need is what real aircraft have, and is not GPS, is INS (Inertial Nav or Dead Reckoning as said before), aircraft rules dont allow primary GPS navigation only.

I do use dual-GPS setup now on my bird, and I have to say flying daily now over a year have never had a GPS incident, the Arducopter redundant GPS feature works really nice and its been reliable to me.

I think the bottom line is to not have the craft lose track of  its position, rather than figure out remaining power and all that

this discussion starts to have some entertainment value, ArduPilot already have INS, I would suggest that participants check out all the features/possible config that is already there, then maybe work on some specific solution for a specific scenario that is *not* already there.

There is an advanced failsafe system in the ArduPilot Fixedwing branch.

http://ardupilot.org/plane/docs/advanced-failsafe-configuration.html

Looks like this provides quite a bit of additional capability.

so why are these advanced features only on Ardupilot and not Arducopter? do they apply for AC was well or no?

I also seen some of the newer GPS (M8N) have built-in EKF or INS, specially the RTK ones, has anyone looked at those?

yes uBlox GPS units.

so the advance failsafe features can only be used on plane right? not multirotor?

Asim said:

I don't believe these features can not be used on fixed wing aircraft if that's what you mean.

Are you referring Ublox GPS here?

AFS is on both, again; for a thread that is suscussing improvements, everybody should first be familiar with documentation and existing features: http://ardupilot.org/ardupilot/



Ivan R said:

so why are these advanced features only on Ardupilot and not Arducopter? do they apply for AC was well or no?

RSS

Groups

Season Two of the Trust Time Trial (T3) Contest 
A list of all T3 contests is here. The current round, the Vertical Horizontal one, is here

© 2017   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service