Configurable failsafe action

[brat002]

Could anybody implement configurable failsafe actions that will be triggered by low voltage or RC signal lost events. I think, we can have several possible actions:

• shutdown motors
• land with previously defined motors rotation speed
• land (if GPS signal available)
• pos hold
• return to home and pos hold
• return to home and land

[dustin]

There are a few failsafe bugs Josh that may cover your request.

On Thu, Feb 18, 2016, 12:17 brat002 notifications@github.com wrote:

Could anybody implement configurable failsafe actions that will be triggered by low voltage or RC signal lost events. I think, we can have several possible actions:

• shutdown motors
• land with previously defined motors rotation speed
• land (if GPS signal available)
• pos hold
• return to home and pos hold
• return to home and land

— Reply to this email directly or view it on GitHub https://github.com/d-ronin/dRonin/issues/673.

[tracernz]

There isn't one covering this but it has been discussed a lot. There is a high bar for GPS/nav-related failsafe modes IMO. Fly-aways are the last thing we want to be associated with dRonin.

[mlyle]

Yes. The sophisticated autonomous modes are likely to be awhile before we implement them. In the shorter term there's some interest in intermediate modes to ride-out failures (e.g. short times-- a second or two-- of leveling at low power to do something better during brief signal losses than stopping the motors).

[brat002]

If navigation capabilities is not available dRonin can fallback to simple failsafe actions like

• land with previously defined motors rotation speed(failsafe in cleanflight firmware)
• shutdown motors

2016-02-19 0:48 GMT+03:00 Michael Lyle notifications@github.com:

Yes. The sophisticated autonomous modes are likely to be awhile before we implement them. In the shorter term there's some interest in intermediate modes to ride-out failures (e.g. short times-- a second or two-- of leveling at low power to do something better during brief signal losses than stopping the motors).

— Reply to this email directly or view it on GitHub https://github.com/d-ronin/dRonin/issues/673#issuecomment-185936559.

[mlyle]

The problem isn't just lack of availability. It's that we have no infrastructure to tell if they are working. We could have a magnetometer error and fly away forever. We need to be able to tell when advanced modes are not making progress towards their objectives so we can fail to safer, less complicated approaches.

IE, if the magnetometer lies and we fly off in the wrong direction, that's super bad. We would keep going that way forever.

[cehteh]

Some random blurbs:

Failsafe autolanding could be done w/ accelerometer only (level, set to 8.5g or something like that). This will possibly a be bumpy landing but needs less math and setup than vario/altimeter assisted landing. At least this should be better than fixed throttle level. Touchdown could also be detected when acc sums to >9.8g. Disarming and shutting motors down.

Magnetometer could be used (optionally) to turn the copter into the same direction it faced when armed. Sometimes a Pilot has the copter still in sight, but got disoriented. Switching on failsafe (which does a sequenced action like 30sec hoovering, 45sec autolanding, shutdown) may help to regain control then.

[nouser2013]

I'd like to just chime in to push this up the wishlist, nearly (literally) lost my camera copter in a corn field last weekend due to the hardcoded "drop out of the sky" logic. Naza and other boards offer at least a position hold on link loss, so can we have this here also?

Failsafe autolanding could be done w/ accelerometer only (level, set to 8.5g or something like that).

Doubtful. You'd have to constantly increase speed downwards to maintain / regulate to 8.5g. So, imo you'd need the barometer in any case for autoland.

The problem isn't just lack of availability. It's that we have no infrastructure to tell if they are working.

Well, the hardware kinda "can-do", at least on MPU-9250 enabled boards. They do have a selftest feature available, "simply" writing and reading a few registers more on regular intervals.

GPS does have the DOP feature to estimate sensor data quality. And we do have sanity checks also: vehicle cannot move more than 10m/s, so check each GPS measurement against previous one. I know it's a lot of coding, but on the other hand, we're not trying to navigate airliners...

And autoland with working baro and MPU should be not too difficult:

• Wait in level for 30 seconds
• descend with 30cm/s
• if alt reading does not change "much" for 5 seconds, cut engines

Landing in a corn field still will likely fry your ESCs anyway due to blocked props...

[dustin]

I'd like to just chime in to push this up the wishlist, nearly (literally) lost my camera copter in a corn field last weekend due to the hardcoded "drop out of the sky" logic. Naza and other boards offer at least a position hold on link loss, so can we have this here also?

It's too easy to make that do really terrible things and/or be very inappropriate under unexpected conditions.

Sometimes (e.g., in your case assuming you've set things up really well) it might be safe. Many of the times I've hit failsafe, it wouldn't be (e.g. radio came completely unplugged so it'd never regain contact or I was in a place where attempting to PH would not be safe).

If you have control and it's a good idea, flipping into PH is an option. If you've lost radio contact, it's not clear that, in general, trying to PH is wise.

[nouser2013]

It's too easy to make that do really terrible things and/or be very inappropriate under unexpected conditions.

Look, I have read the discussion of course. I also believe to have a fair understanding of the risks involved. And I do understand that a 3kg chopper can cause serious harm and is not a toy. Also, in the country where I live in, some laws apply:

• don't fly in living areas
• don't fly over people
• maintain line of sight at all times
• no higher than 150m agl

If you have control and it's a good idea, flipping into PH is an option. If you've lost radio contact, it's not clear that, in general, trying to PH is wise.

I disagree: a craft maintaining position and alt gives you time for action, e.g. to shout "MOVE PEOPLE" or close the distance and try to regain control. A craft simply dropping does not (2-4 seconds to impact!). Also, the craft will revert to "drop" latest when the battery is empty. So you don't really lose anything by PH imho.

... use RX predefined settings on link loss to set RTL mode ...

I'd consider this extremely dirty:

• arming state is default "on"
• Throttle is somewhere center

So, forget to turn on TX, craft may immediately shoot away...

I guess all I'm asking for is to be given a choice =) for example:

• introduce a new flight mode "autoland" with soft descent
• make failsafe a state machine based mode, e.g.:
  • flight mode 1 + time to remain in that mode
  • then flight mode 2 + time to remain in that mode
  • ...