Copter: crash detection on hard terrain

[lvale]

If a copter crashes upside down on hard terrain and the propellers keep spinning the crash detection won't disarm the copter because the copter is jerking around inverted, usually with high prop speed.

Shared an example log (5.bin) when such an event occurred

[fmckeogh]

This also occurs on softer terrain when the copter is in Land mode and a leg catches on grass, causing the copter to tip over while the motors spin at close to full speed.

[rmackay9]

Here's the line in question where it checks for no more than 3m/s/s of acceleration. One simple solution may be to increase CRASH_CHECK_ACCEL_MAX from 300 to 400 or 500. https://github.com/diydrones/ardupilot/blob/master/ArduCopter/crash_check.cpp#L30

[lvale]

https://github.com/diydrones/ardupilot/blob/master/ArduCopter/crash_check.cpp#L8 ??

can't we also check for acceleration burst/peak per axis, specially z ?

[rmackay9]

@lvale, that might work. Sure that might work. The tough part is coming up with the right math plus then doing the testing that it works without leading to false positives.

[rmackay9]

My guess is what we should do is remove or greatly increase the maximum acceleration as the angle error increases. So once the angle error is >90 deg or >120 degrees we pretty much remove the accel check completely. That would at least work for vehicles that have completely flipped over.

[R-Lefebvre]

I think that makes sense Randy. It's like a probability check. If we're >90 for for 2 seconds, pretty good chance we've crashed.

This is always tricky to get right.

[lvale]

a few days ago someone at RCG shared this with me, that would be part of the current crash check.cpp:

#define CRASH_CHECK_IMPACT_THRESHOLD    17f    // vehicle is considered crashed if accel values go above then below threshold

  if (acc.x > CRASH_CHECK_IMPACT_THRESHOLD))
          impact_threshold_crossed = true;
      if (acc.y > CRASH_CHECK_IMPACT_THRESHOLD))
          impact_threshold_crossed = true;
      if (acc.z > CRASH_CHECK_IMPACT_THRESHOLD))
          impact_threshold_crossed = true;    

I'll have to go see who it was :) (destey?)

found it http://www.rcgroups.com/forums/showpost.php?p=34156707&postcount=8021

[rmackay9]

@lvale, ok, so that's also adding an impact check. It's a decent idea I just personally haven't seen enough data to know if that will work. As always it's a balance because some copters with high vibrations will breach it all the time, others won't hit the ground hard enough to trigger it.

[lvale]

@rmackay9 The vibration part was one concern I had when I saw that initially, but vibrations would tend to last longer in time, right ? And if they vibrate a lot, better not having them flying, because the level of vibration would make EKF go nuts. Now the hitting on the ground would require some kind of "crash" testing, on a pre-determined set of test conditions, for a "thump" value to be determined.

[proficnc]

Cases for vibration in flight of a well setup copter need to be concidered,

1. prop partial failure can induce huge vibrations.
2. Bird strike
3. Clipping an object, but not crashing.
4. Mechanical issues, like a motor bearing failure inflight.

[magicrub]

I added an x axis peak detector 300ms hold to the raw accel data for plane land crash detection purposes. I added it for all axises but tridge vetoed it, leaving just half of one. My fork does peak detection of all 6 peaks for better crash detection. I can add that back in, along with a MAVLink packet I use for it if tridge is willing to accept it. On Mar 13, 2016 8:34 PM, "proficnc" notifications@github.com wrote:

Cases for vibration in flight of a well setup copter need to be concidered,

1. prop partial failure can induce huge vibrations.
2. Bird strike
3. Clipping an object, but not crashing.
4. Mechanical issues, like a motor bearing failure inflight.

— Reply to this email directly or view it on GitHub https://github.com/diydrones/ardupilot/issues/3486#issuecomment-196121999 .

[R-Lefebvre]

I think the key concept here is no simply the peak value, but the impulse. That being force times time. This would solve the problem with vibration, as vibration oscillates (unless it's aliasing really badly but then the copter is dead anyway) and the oscillation would cancel out the impulse.

So along the lines of what Tom is suggesting.

You need a peak accel to dwell for some period of time.

[MrYar]

(destey from rcgroups here) Seems one way to discern a crash could be to keep a max accel value of vibration (bounds of the oscillation) with a check that its oscillating as much in each direction of that axis. If its in the air and only vibrating, not crashing, it should have about an equal magnitude oscillation. This crash (log graph) has about a half magnitude "oscillation" on the rebound, and some magnitude more on the down than the max vibration oscillation. Then check that max accel value (bounds of vibration oscillation) against a potential impact "oscillation." Which won't be as much on the rebound.

[tomarigr]

why don't we just collect crash logs all over the planet ? im sure there would be many of them!!! then process the data and come up with something that works 90% right or more !

[aercamti]

We have experienced a copter falling out of the sky at 70m AGL or so during an auto mission, with the crash check being triggered in flight, according to the log. We concluded that this occurred due to sudden strong winds at altitude, resulting in a drastic lean angle and a subsequent out of control flight phase in recovery. (Sorry, unable to share log of client)

While having a crash check on the ground is a great safety feature, it must never be able occur whenever there is still a change in altitude occurring. In a situation as above with unusually strong lean angles, or in a drastic change of altitude due to an evasive maneuver with an manned aircraft approaching, a crash check simply may never trigger.

P.S.: I am aware of the 5 conditions having to be in place for 2 secs acc. to the docs, but in our case the vehicle definitely had not landed, yet a crash check event was recorded while still in flight

[auturgy]

No reason to close. It’s a valid enhancement request.