Multirotor inverted crash detection

[breadoven]

Disarms a multirotor if it has ended up inverted on the ground following a crash and can't be disarmed manually due to loss of control.

Detection is based simply on a roll angle > 100 degrees or a pitch angle > 70 degrees together with Baro altitude rate remaining below 2m/s. These conditions must be maintained for at least a minimum of 4s before disarm occurs. The time delay to disarm can be increased by a user setting which also allows detection to be disabled by setting to 0 (default setting).

Seems to work as expected with static tests but not tested with motors running yet.

[Jetrell]

I gave it some tests. Having nav_mc_inverted_crash_detection = 4.
Although I could only get it to work every now and then.. Displaying Disarming by Failsafe.

Most of the time it wouldn't disarm at all.. Which I think was because the landing detector expects the quad to be sitting still.. Which is not going to happen when the quad is upside down, with the props chewing up the grass.

I also notice, even with failsafe_stick_threshold = 0, the FS condition could not be reset, even when the RC link was re-established. Only after a power cycle was the condition cleared.

[breadoven]

How did you test @Jetrell, motors running or not ? I assume you didn't try it with props mashing up the grass ? One of the problems I can see is the vibration from props hitting the ground and being damaged causing vibration. This will potentially screw up the altitude estimations which will prevent this PR from working if the estimated Z velocity exceeds 1 m/s. Other than that the logic is very simple, just needs to be upside down. Did you try just holding it inverted without the props hitting anything (or motors disabled using ground test mode).

One of the problems with this is a proper test will likely damage props and motors, something most people aren't going to want to do. Testing with a whoop I guess is one option but then you don't get the vibration that might upset the Z velocity estimation. I guess the other possibility is to look for the vibration but then some quads might have clear props when inverted so that's not fool proof either.

Not sure about the Failsafe issue. It reset correctly when I tested just now.

[Jetrell]

How did you test motors running or not ? I assume you didn't try it with props mashing up the grass ?

Yes, with motors running.. I figured it wasn't much point unless the quad was in nav rth. And I triggered an RX failsafe straight after wards. To simulate what happened in the cases this feature was designed to protect against.

I've got used to mitigating damage in tests. But the grass still sticks through the cage I made for testing.. Although I'll have to print another cage.. But the quad wasn't damaged. And these are the results I seen after 7 tests..
It disarmed twice by Failsafe. Once by Landing. And not at all 4 times.

Not sure about the Failsafe issue. It reset correctly when I tested just now.

It would operate after the RC link was re-established.. But the OSD FS warning message and FS flight mode wouldn't go away until after a reboot.

[breadoven]

Well you'd need to look at the logs. Check attitude[0] and attitude[1] and also navVel[2], see if they remain within limits for the time delay you set (2 + 4 = 6s). navVel[2] should be below 1 m/s. Can't see why it didn't work if these values remain within limits.

I assume landing detection was active when you tested. It needs throttle above hover throttle and some movement to activate the landing detection which is required for this PR to work.

Failsafe sounds like it's just stuck in Failsafe mode even after the Rx is re-connected. What does the log say ?

Edit:
I assume you disarmed when trying to recover out of Failsafe ? If Failsafe has disarmed on landing you need to deactivate the arm switch before you can exit Failsafe.

[Jetrell]

Yes, landing detection was active.
The times it did disarm. It was in the range of-0.4 to -0.9m/s..

But the times it didn't disarm, it was between -1 to -3m/s.

When upside down, the Baro altitude remained with 0.5m fluctuation. And GNSS EPV was relatively constant, around 200.

Failsafe sounds like it's just stuck in Failsafe mode even after the Rx is re-connected. What does the log say ?

It stayed in FAILSAFE RX LOSS MONITORING

Edit:
I assume you disarmed when trying to recover out of Failsafe ? If Failsafe has disarmed on landing you need to deactivate the arm switch before you can exit Failsafe.

Yes.. Disarmed and rearmed.

It needs throttle above hover throttle and some movement to activate the landing detection which is required for this PR to work.

Yes, as always. Airmode throttle threshold and hover throttle is well and truly meet before these tests.

[breadoven]

So the quad is in a crash cage and the props aren't clipping anything solid causing vibration ? Is vibration high in the logs ?

I thought the Z velocity might be an issue. I guess the fact the quad body is on the ground with motors spinning creates vibration in itself which screws things up. Might have to think of something else in that case.

To get out of Failsafe after a landing you need to waggle the stick then wait 30s and be disarmed ... then it should reset. Worked last time I tried it on a fixed wing.

[Jetrell]

accVib was intermittent. Raising to over 4000 and then dropping to 300. Which is likely expected under the conditions.

Thanks for the tip about the 30s failsafe landing reset. I didn't know about that.

Can I ask. How motionless did you have your quad before it disarmed, when you performed the bench tests ?

[breadoven]

Can I ask. How motionless did you have your quad before it disarmed, when you performed the bench tests ?

I was just wobbling it about and shaking it at the same time .. which probably doesn't simulate the sort of vibration you get from motors.

Could use Baro rate instead of estimated Z velocity I guess, which is available, but not sure how well that will work to differentiate between a quad jumping about on the ground upside down and a quad free falling during flips etc.

[breadoven]

I'm thinking now it might be better to just use estimated altitude to check for vertical movement and increase the minimum delay to 5s which should still help significantly to limit damage and risk from an out of control quad.

@Jetrell it would be useful if you could check what navPos[2] was doing during the tests you did above. I get the impression Position isn't as sensitive to acceleration factors as Velocity is so maybe it's a more reliable value to use.

[Jetrell]

Sorry. I deleted those logs, thinking I wouldn't need them anymore.

I do remember looking at it. And comparing it to baro altitude. The two were reasonably steady, within a meter of each other.. Although this particular quad has good separation between the GNSS module and other RF noise emitting devices. Meaning it held a good fix and low HDOP, even when the GNSS module antenna was facing the ground.
While this might not always be the case on many copter builds.. The navPos[2] is likely to drift considerably more if the GNSS module antenna is facing the ground and the copter has more localized GNSS band RF noise coming from a device like a HD VTX.

[breadoven]

Changed to use an inflight sanity check based on vertical position rather than velocity. Hopefully more reliable.

[Jetrell]

I tried two types of tests using vertical position.

1) Taking off and entering a hover, and then flipping it over just above the ground, while entering failsafe.
Due to this one being within failsafe_min_distance it would just enter RTH_LAND and disarm by landing in the 5 seconds it was set to.
navPos[2] was <2m in these tests most of the time. Although the vertical position would drift and become greater, the longer the GNSS module antenna faced the ground. While the Baro altitude was more accurate in both test types. On this copter anyway.

2) Took off and flew >10m from the arming location at 2m above the ground. Flipping it over and entering failsafe.
It enters RTH_CLIMB_TO SAFE_ALT. And once on the ground navPos[2] was always >-2m in all of these tests. Preventing it from disarming by failsafe at all.. Likely seems the inverted fall (GNSS antenna facing downward) and the vibrations from the motors and props hitting the grass are effecting the vertical position estimation.
Imaging how much worse vibrations would be if a copter was flipped on hard ground and broke or bent a prop blade.

I could trick it to disarm by failsafe with the motors running and the props removed. When I did a ground test.. But not every time.. And its not a real world situation.

This showed the worst case from the 2nd test method.

[breadoven]

OK, maybe this should just use Baro for a sanity check and increase the altitude margin to say 5m. Can't see a flying quad remaining within a 5m altitude band for >4s when inverted. Theoretically it could stay within a 5m attitude band for at most around 2s in flight when inverted assuming the props don't provide any significant translational lift. The props if anything should push the quad earthward when inverted even at idle.

I suppose the other question is how long can a quad realistically fly for inverted, in ACRO mode I guess ? Never tried it but I assume it's possible to flip it on its back and freefall inverted ... so available height is your only limitation timewise ?

[Jetrell]

Yes.. In theory any prop draft will be blowing skywards, when the copter is inverted after a flip crash. So the barometer is less likely to see prop-wash effect it.. So the barometer should provide a stable means of measurement.
However, i guess it all depends on how far and fast the copter falls, if it did crash inverted in a failsafe.. Air compression on the barometer can cause an increased short term error read.

You can use thrust to start a climb before the quad is flipped inverted and the throttle lowered. So hang time could possible be a few seconds before it looses upward inertial motion, and starts to descend.. We are seeing more BF freestyle pilots giving INAV a crack.
The only other exception maybe people that fly inverted 3D freestyle.. I have tried it with INAV before. But I'm not sure how many INAV pilots still use it. Its seems more popular with BF.

[breadoven]

OK 3rd attempt at getting this to work reliably. Changed to using Baro rate to detect vertical movement which is probably what should have been used to begin with given it shouldn't be affected by vibration.

Inverted detection should now only trigger if Baro rate is below 2 m/s. This could be adjusted higher if it still causes problems from testing. It certainly stops it triggering just by moving the quad rapidly up and down by hand which results in a Baro rate slightly higher than the 2m/s limit.

[Jetrell]

Looks much better with this method.
I tested it 6 times with an inverted flip over, followed by FS.. Both at the launch location, and at a distance away with a couple of meters drop.
On each attempt It Disarmed by Landing.

And I also held it down once in FS without instigating a flip before hand. And it didn't disarm when upright. Which seems correct.

nav_mc_inverted_crash_detection = 4 in these tests as well.

[breadoven]

I did work out that if you assume a flipped quad in flight acts like a projectile then at the normal expected flight speeds or even just moving vertically it shouldn't remain within the +2 to -2 m/s vertical velocity range for any longer than only around 0.5s. In reality there will be some thrust pushing it earthward so it would probably be even less time than this. So a minimum disarm delay of 4s leaves a lot of margin.

Although I've just realised this needs inhibiting during Turtle mode. Should be OK to merge otherwise.