• This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn more.

Failsafe

nilsen

Senior Member
#1
i was flying and my dear little miniquad went into failsafe... I managed to get it on camera.

Note how the props stop, and then start up again and the quad drifts down.

[video]https://youtu.be/_3qvlNCGkP8[/video]
 

Snarls

Gravity Tester
Mentor
#3
Very nice save. A controlled decent followed by cutting the motors. I guess the tricky part is timing the shut off so as to not damage the motors in the event you land in such a way that the motor can't spin.
 

jhitesma

Some guy in the desert
Mentor
#5
Nice, here's one I caught - but I go for 1 second before disarm when failsafe triggers (This was with baseflight at the time) :


I was flying on my openLRS and at 1:10 I suspect the antenna vibrated loose which is why I lost signal :)
 

nilsen

Senior Member
#6
Thanks although I didn't save it at all, the shutoff is probably receiver failsafe and then the motors spinning slowly is cleanflight failsafe.
I think it's set to 1300 or so. I would absolutely hate to have a quad fly away, just floating off like a balloon...
 
#7
So cleanflight still doesnt have "autoland" ? Cant imagine that being so hard to program and would be extremely useful as failsafe setting.

Speaking of, well, "fails"; last year my brother and I where flying FPV miniquads when he suddenly completely lost his video link. I quickly landed to help spot his mini. Couldnt see it. I could hear it faintly though. So we ran in that direction looked. I had assumed he had engaged his altitude hold, but asked him just to be sure, and he said he did. We looked and walked and listened for minutes as the sound faded. It wasnt that windy, how far could it be? I had pretty much given up when I heard a very VERY faint beep. lipo alarm. almost directly above us. Getting louder. And louder. Then I saw something the size of insect, 100's of meters high. Nope, he had not engaged altitude hold, his quad had been climbing the entire time. Came down with at pretty much free fall speed as the battery was completely gone, only 100 meters or so from us. In to sand. Stunningly, there was no real damage beyond props and some plastic spacers. ZMR 250 carbon frame, that Bruce says cant take any abuse. Ha!. Took us 10 minutes to find the mobius but unfortunately we never found the sd card which was ejected on impact.

Moral of the story: put some tape over the sd card, so if you do something really stupid, at least you'll have some video to show :p
 
Last edited:

jhitesma

Some guy in the desert
Mentor
#8
So cleanflight still doesnt have "autoland" ? Cant imagine that being so hard to program and would be extremely useful as failsafe setting.
Autoland is ridiculously difficult to do correctly. The naze doesn't have the sensors, memory or processing power to do an intelligent autoland.

Even on more powerful setups with additional sensors it's really tough to do right and often causes just as many or more issues as it solves. Just look at all the videos of DJI's doing crazy stupid and dangerous stuff when they loose signal and try to RTH or land on their own.
 

FinalGlideAus

terrorizing squirrels
#9
Plus auto land is a really good way to break electronics or loose the entire quad. Mini quads are generally pretty tough. Dead duck failsafe means you get the quad back and hopefully only break a few props. The few who do more are usually at 300ft when it happens but that is mostly a strange place to be for a mini quad to be and more unlikely because you are usually more LOS without obstacles to block the signal.
 
#10
Autoland is ridiculously difficult to do correctly. The naze doesn't have the sensors, memory or processing power to do an intelligent autoland.
I dont mean an "intelligent" RTH/GPS autoland. Just a controlled descent as failsafe.Which should be very easy if you have a baro, its essentially altitude hold with an offset, and still pretty easy if you have the acro version, by just using the accelerometers.

As for RTH, I got it working on an multiwii board which has far less processing power than a naze. Not saying the software part is easy, its not, but its not a matter of hardware resources.
 
Last edited:

FinalGlideAus

terrorizing squirrels
#11
The problem with auto land is if the board doesn't turn off the motors when it should you will fry your esc's. Even with a perfectly functioning Baro like you said you're kind of stuffed if you land in a tree or land on a hill that was higher than where you took off etc.
 
#12
Why? Its not hard to detect altitude is no longer decreasing even as the rpm's are reduced; it means you have landed and you can and should turn off the motors. Surely thats better than after x seconds, the way it is now.
 
#14
I havent inadvertently triggered failsafe's yet, Ive got RSSI telemetry and a good radio, but that doesnt mean simpler is better in this case. Now you have to predefine a throttle setting; if one day you fly without gopro or with a significantly lighter battery, or both, or larger props, or a 4S instead of a 3S, your craft may climb instead of descend. Not very safe indeed (and rather silly if you have a baro which registers this climb!). And it turns off the motors after X seconds, regardless if you are still flying or on the ground, which might be great if you were at 30 meter, but not so great at 300.

Now in the case of autopilots, there I agree and would say sometimes simpler is better, and I dont understand why DJI stuff doesnt just autoland on baro when it detects (or should detect) that GPS and/or RTH isnt working. Instead it keeps "navigating" towards Eastern Africa until the battery dies.
 
Last edited:

cranialrectosis

Faster than a speeding faceplant!
Mentor
#15
I'm with FGA and jhitesma on this one.

I cannot ethically release a flying robot that is out of my control within range of people or property. There is no excuse for hitting someone with a copter. NONE. I will never forgive myself if my copter flies away and hits some kid in the head.

I will not risk it.


No copter is worth a person. If I am not in complete control of the copter, I want the copter on the ground, shut down, immediately.
 
#16
If I am not in complete control of the copter, I want the copter on the ground, shut down, immediately.
What if its >100m up in the air? Do you really want it to free fall to the ground? I cant for my life understand why you'd think that is safer than a controlled descend. The simplest, safest approach is to make the craft hover for a while, possibly allowing you to reestablish control. After that it should come down, but preferably no where near 9.8m/s². A fixed throttle position doesnt guarantee anything of that, it may even cause a further climb before free falling.
 
Last edited:

cranialrectosis

Faster than a speeding faceplant!
Mentor
#17
Once I am no longer in control, I want the copter stopped and on the ground as soon as that can be made to happen. I can control where the copter lands so long as I am in control. The longer the copter is out of my control the more dangerous it becomes.

I don't fly over people but I fly within my copter's range of people.

There are lots of videos on Youtube of copters just flying away because of a poorly set 'intelligent' failsafe. I don't want my copter to ever be able to just fly away on its own.

If my copter is 'just hovering' at 100m for 1 minute, how far away can the wind push it? Can it be pushed far enough away that it is now over people?

If I am flying over people I am already wrong and being reckless.

If I am flying safely, the altitude doesn't matter. There isn't anyone below the copter to hit and that is all I care about.

All I have to do is prevent the copter from flying over people on its own. The simplest way to do that is to bring it straight down, right now.
 
Last edited:

jhitesma

Some guy in the desert
Mentor
#18
I dont mean an "intelligent" RTH/GPS autoland. Just a controlled descent as failsafe.Which should be very easy if you have a baro, its essentially altitude hold with an offset, and still pretty easy if you have the acro version, by just using the accelerometers.

As for RTH, I got it working on an multiwii board which has far less processing power than a naze. Not saying the software part is easy, its not, but its not a matter of hardware resources.
Getting them to work in simple best case situations and working as a demonstration is one thing. Getting them to work reliably enough to actually be safety features - that's a whole different story.

Baro's alone are not enough for controlled descent, you need accels as well and to really do it safely you also need sonar and optical flow would be a very good idea as well. Otherwise you can get into all kinds of situations where things can go ugly fast. The baro sensor is not really an absolute sensor - it's relative. It's also noisy and notoriously unreliable - so it needs assistance. And while baro and accel can tell you if you're going up or down and at what rate - determing if you've actually landed is another story. To just assume that because you're not seeing descent means you've landed seems like a simple solution - but there are quite a few situations where it's the wrong assumption.

Same with RTH. Getting a MW to follow a GPS back to where it thinks it's "home" is is hard...but not undoable. But getting it to navigate home in a safe manner where it won't cause more issues. That's another story. Even with GPS working reliably (which is a VERY dangerous assumption) there's the issues of obstructions and altitude. Like I said look at all the videos of DJI's flying into things when trying to return home because they just draw a line from where they are to where they want to go and assume they can follow it. You knew to fly around or over that building - the FC doesn't because it doesn't know the building is there.


Autoland and RTH are fun and cool. No debate there and that's why I've experimented with them. But they're a long ways from being reliable enough to be considered safety features or to trust for a failsafe situation.
 

jhitesma

Some guy in the desert
Mentor
#19
I think the best way I can put is is this. What seems simple to us usually isn't to a computer.

And landing and returning to home aren't really even that simple to us - hence so many people wanting automated assistance with them.

These things really do get incredibly complex when you start to think about all the possible failure modes and use cases. In a big open field with no one around and no obstructions - that's one thing. But at a typical flying field (or worse the kinds of inappropriate places more and more people are trying to fly) things really aren't as simple as it may seem. Obstructions, winds, sensor failures/hiccups, GPS sometimes jumps 10-15 feet even with a good high def lock when one sat goes over the horizon or a new one comes up...it will eventually correct itself...but that can take a few minutes which can easily be too late. And that's just the issues that come immediately to mind but there are dozens more that may seem trivial or unlikely - but have been documented in testing as causing major issues with autoland and rth type of functionality.

Not saying we'll never get there. But the current state of the art really is that these things are novelties and tech demos at this point in time and not safety features and should not be considered as such.
 
#20
And landing and returning to home aren't really even that simple to us - hence so many people wanting automated assistance with them.
Return to home and controlled descend arent in the same league. Yes, return to home is fairly tricky to do well, otoh, using a baro, or if no baro is present, the Z-axis accelerometer, to find out if you are still flying or climbing, is not. Its way easier than keeping a multirotor stable. Im not talking about a nice, soft, landing. Im talking about a controlled descend, or if you prefer, controlled crash, which is what the current software does anyway. But something safer (and more elegant) than a predefined throttle setting that may cause nearly free fall or an ascend depending on whatever you happen to fly that day, and cutting the motors from whatever altitude.

On top of that, you can and probably should, put additional safeguards on the failsafe. It only takes like 3 lines of code to detect descend isnt working for whatever reason, and still cut the power if you arent losing ~x meter per second over the past Y seconds. Or if by some weird coincidence both the RF link and the baro went haywire, you can still decide to cut the throttle and tumble from the sky. Unfortunately Dominique prefers to write code for complex flashing patterns with RGB LED strips. Neat as they may be.

As for RTH; doing it right isnt that easy, I'll grant that; in general GPS navigation isnt, but please dont read from the countless Naza flyaways that those flyaways are that difficult to prevent. Im willing to bet that if you checked the code, you will see no sanity checks regarding distance to home (after reading perhaps 100 reports on RCG, Im quite confident its returning to 'home' in Ghana, ie 0°N 0°E, if it loses its GPS lock during RTH or home wasnt properly initialized) , closing speed (it should, but clearly doesnt stop trying if home isnt getting any closer, due to compass or other issues) etc; if they where in there, Im am very confident they would stop the RTH attempt with flaky GPS reception or non initialized home position, compass issues or even most malfunctions, and revert to an autoland (/crash) instead. And gone would be 99.9% of the countless reports of phantom/naza flyaways. But the naza doesnt do that, any of it, because no one at DJI apparently bothered to put in those safeguards.

And thats irony; they have figured out the difficult part. It does fly pretty well, its GPS position hold and navigation is impressive, at least as long as everything is working as expected. Figuring out things are going wrong for whatever reason, and taking the decision to do a controlled crash landing, by comparison is so much easier. And descending using a baro is trivial.
 
Last edited: