Ultimate Auto Mode Fail Safe Design: Logic inside PixHawk

I have been looking at Fail Safe Modes in Pixhawk/Mission Planner and I think the way the logic operates may not be the perfect solution, unless I am just lacking knowledge in Mission Planner.

Below is my thought on how Fail Safe should work in PixHawk or Ardu.

If someone has experience working on this in the past, I would love to hear your thoughts.

Thanks

Views: 579

Reply to This

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 think I already said in my post that I do not fully understand all the features. If we all knew the answers none of us would be on this web site for help :)

How do I accomplish the above diagram fail safe settings?

There is another thread going on where one pilot lost its drone due to GPS signal lost and his drone went into fail safe and landed in ocean rather went into for example loiter mode and waited out for the GPS signal to come back.

My proposed design is to avoid such scenarios. let me know how to do this.

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 ?

Well I am just begining to learn the coding around Ardu and PixHawk, so I can't do it by myself at this point.

If there are programmers out there who are willing to work on this with me, I am willing to invest money in it as well. So contact me if anyone is serious about it.

I have a better version of the fail safe flow concept that I have been working on for the past few weeks. The new design idea I have will make drones at least 100% more stable and reliable and we can all avoid unnecessary crashes.

Anyone interested, please contact me. You must have a strong programming background in MAVLink, Ardu and Pixhawk and GUI Interface design. C++ would also be essential.

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.

@Thomas - Good observations and suggestions.

We don't want our drones become Kamikaze devices :) Lets not give FAA another reason to go tough on all of us.

1. Right now the battery fail safe has one threshold which is not enough at all. There should be two fail safe warnings or even three.

a) First one kicks in when the battery reaches X percentage of draw after take off. That is the initial warning how much juice is left. This should just be a warning nothing else so the pilot can decide what to do. I don't want Pixhawk to take over control from the beginning. The reason is that I have seen battery losing power suddenly instead of declining at fixed rate which is I am going to explain below why they do that.

b) The second warning enables the safe mode as chosen by the pilot.

2. Your second idea is good one but a bit tricky one to implement. Here are my thoughts on that one. Feel free to add to it.


a) A pilot can predetermine (after testing) the flight time they will get out of for example a 4S@5200mAH battery (or calculated), however the calculation made one time will never be valid for the second flight. The reason is that batteries are chemical devices, so there discharge and voltage hold rate will vary day by day by X% factor as they age.

b) Time = (C rating of the battery)/Discharge Current

However, battery capacity decreases as the rate of discharge increases.

c) So we have to use Peukert's exponent.

t=\frac{C_p}{I^n},
where
n - Peukert's exponent
Cp - Peukert's capacity

I - discharge current

Note: Peukert's exponent changes as the battery ages.


READ THIS ARTICLE. It explains the whole thing in detail Peukert's exponent and Calculator I think this theory also applies to LiPo battery but the article is written for Lead Acid batteries I believe.

I also came across this Lipo battery Calculator. Not sure how accurate it is. LiPo battery Calculator

So as you can see its no easy task to automate this process of calculating real flight time out of a battery and building a FIXED or predefined fail safe system. The fail safe system has to adjust accordingly during flight.

I have been recently designing an automatic battery cut over system (yes I know we can connect two batteries in parallel). Basically you fly a drone with your 4S@5200mAH battery. You have all your fail safe in place but all of sudden the battery goes bonkers way too earlier than you expected. Your Drone will have a second battery, smaller size and weight such 2S, 3S as a backup.

The drone will switch to backup battery (with no loss of signal), and will send you a warning sign that switch over happened via Telemetry/OSD, than it will turn off all devices that have no use now such as gimbal control, OSD, Video Tx, etc. and we can even initiate an RTL along with it.

Just few ideas I am working on. Guys feel free to chime in any more suggestions.

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.

Thomas,


I checked the specs of MLVSS on-board LiPo sensor. Interesting product for sure. So I am assuming it will transmit the signal back to Mission planner? But the external Lipo voltage regulator (that comes with PixHawk) already does that so what is the added benefit here?

Sorry I haven't read on it too much yet, plus I am more of Futaba guy. I guess I need to buy a FrSky as well to play around with it :)

Futaba for example R7008SB receiver has an external battery monitor built in, but same challenge that the data will not come through mission planner, comes to Tx.

We are working on completely eliminating the Transmitters and RX altogether. Have the drone totally fly through mission planner via MAVLink (I know MavLink has delays etc. etc.) That is the ultimate goal while maintaining all the bells and whistles of a standard TX and RX setup as well.

the ultimate goal is that both standard TX/RX setup as well as Mission planner, both providing the same data. Thank I guess we can call it a complete dual redundant system/setup.

The two battery idea is not to increase the flight time (i.e. batteries in parallel), its more for commercial application where if one battery fails for whatever reason, you have switch over backup battery to rely on. That's all.

Input voltage differences can be easily handled via regulators if two batteries are not the same type, but I see your point why add more circuitry, just use two same type of batteries. I agree. Once the design is finalized, it will come to down to cost, weight etc.

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.

I believe MAVlink only shows over all voltage and over all current %. Also one has to tune GC initial measuring accuracy to get accurate readings.

I came from a hardware design background in telecom Industry. There is way we can do the cut over without any reboots period. That is not a challenge, it can be easily accomplished even at miniature level.


Yes telemetry along with Video over GSM, 4G LTE, and soon over 5G, we can do it already. We are also looking at over Satellite as backup (It will be burst of telemetry info not a direct link)

I liked your term, "each gram of weight costs you one second of flight time." :) Check this link, An alternative to Lipo battery, Tesla battery Tesla

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.    

David,

I have not thoroughly tested the Pixhawk on fixed plane yet, I am currently focused on Drone related issues.

That is a good point how to handle GPS fail on a fixed wing. On another thread I have been discussing the GPS loss issue with another pilot who lost his drone in the ocean due to GPS failure.He suggested a great idea.

For drones, we are going to test this GPS that uses Dead reckoning technology

https://drotek.com/shop/en/822-ublox-neo-m8u-gps-hmc5983-compass-xl...

I just got the product in the mail today. For those who are interested in learning how it works here is some documentation on it Technology Dead Reckoning (DR)


For Fixed Wing, off course Dead Reckoning is not going to solve any problem as the plane is in constant motion. I guess a new algorithm has to be written to take advantage of Dead reckoning combined with some new techniques to address GPS failures properly.

Reply to Discussion

RSS

© 2017   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service