Hello, I got a really weird “crash” today and could use some help with the log. The background is as follows:
Typical mapping mission on a plane running latest Arduplane V3.8.2 on a windy day. I have enabled crash detection with a threshold of 25.
Took off in AUTO and performed fine until a few minutes into the flight I got a message on Mission Planner informing me of a crash detection and disarmed motor. I armed again on MP and put the plane back in AUTO. After a short while, I decided to bring it back down. I sent it downwind in GUIDED, manually selected the waypoint before landing and put it back in AUTO. I watched it coming in but suddenly, at a moderate altitude (~50 metres or so by eyeballing it) MP shouted that the motor had disarmed again. I rushed back to the laptop and tried to re-arm but got nothing in response. With no motor, fighting a strong headwind, all I could do was put it in STABILIZE and watch from a distance as the plane glided with almost zero forward groundspeed into short trees and bushes. The craft suffered no damage.
I was quite surprised by two things:
1 - The triggering of the crash detection
2 - the failure to arm the second time I tried.
By looking at the log, IMU.AccX, IMU.AccY and IMU.AccZ I see a spike reaching 50 very early on. This is likely the plane rolling off a low table while being prepared and had nothing to do with the flight. Now, at around 10 minutes, I see an IMU.AccX spike reaching 5 roughly at the same time as a “Throttle disarmed” message.
Now, what are the units here? The IMU.AccZ value seems to be hovering more or less around -10 so I 'm presuming they are metres per second square, something which seems to be corroborated by the documentation for CRASH_ACC_THRESH. If this is indeed the location in the log where I got my crash trigger, could it be that there is a unit mix up?
P.S. I cannot seem to upload my .bin file. The Upload percentage indicator goes up, then drops back to zero and the process repeats a few times, then finally it says “Saved” but I see no uploaded file.
Strange, I don’t see anything about crash detection, nor do I see how it would be triggered, - what gave you the impression it was crash detection ?
To me it looks like a disarm (and I would check tlog if it was GCS that commanded it, as there is no clue in the .BIN)
This was out of the blue during AUTO flying in a straight line and nobody had touched the GCS laptop. It was the first time I ever got a crash detection message so I was quite shocked, especially given the boring bit of flight it decided to occur in.
Throttle is rearmed at around 75.10% of the playback and plane continues the mission on AUTO till around 77.40% when I put it in GUIDED and send it downwind and to a lower altitude.
At around 78.40% of the playback I switch to AUTO with the pre-landing waypoint selected.
At 79.33% of the playback, I get a THROTTLE DISARMED. I was standing next to the GCS looking at the plane and nobody was touching the GCS laptop. I immediately issued ARM again through the GCS but nothing happened. Though the rest of the tlog claims AUTO, I had selected STABILIZE through the RC Tx mode switch, not sure if it got implemented on the plane.
I also have video from onboard camera, I can upload it if anyone thinks it might help.
Which log are you replaying here? The one you uploaded or a telemetry log?
See, there’s a problem with the code you’re running in that we log this crash-detected message into dataflash after disarming the vehicle - but because you don’t have LOG_DISARMED set (the default), that message is instead dropped…
tridge recently committed a patch into master which logs these even when disarmed.
Getting late here, my brain is fried. But I don’t think this is coincidence; your GPS speed drops below 150cm/second in both cases where the is-flying-probability drops:
airspeed_movement is probably false as without an airspeed sensor I believe it is being derived from the wind-speed estimate and gps speed here: https://github.com/ardupilot/ardupilot/blob//libraries/AP_AHRS/AP_AHRS_DCM.cpp#L651 and thus it is as low as groundspeed; I just wish I knew where we logged the estimated airspeed (EKF delegates this estimation to DCM)
is_flying_bool being false leads to the graph above with the rapid decay of isFlyProb
So… was your vehicle really moving at <1.5metre/second as the logs seem to indicate? If your vehicle can really fly that slowly, setting MIN_GNDSPD_CM may stop this occuring.
Yes! The wind speed was quite high, especially at altitude. I can verify from the video footage that it is very likely that, with the motor off, I had close to zero or even negative (with respect to vehicle heading) ground speed at the height of a gust.
OK, I found the wind estimate with a bit of help (NKF2.VWN and NKF2.VWE).
At the time the GPS speed drops below its threshold, the wind speed estimate is also low enough that the estimated airspeed is below a threshold based on the default parameter value (unchanged).
Your estimated airspeed has to be more has 3/4 of the fbw_min speed to pass the airspeed check. The combination of the wind estimate and ground speed wouldn’t have met that threshold.
You could lower that minimum speed.
But if you are planning on flying this slowly - an airspeed sensor might be a good idea!
Aha, let me see if I understand correctly. You are saying that low GS led to the autopilot deciding the vehicle was no longer in flight, correct?
Now, this leads me to the following questions:
Does this (low GS based, non flying quesstimate) qualify as a crash? The documentation of crash detection suggests that it is based on acceleration trigger only. If other factors are in play, should it not also be mentioned somewhere?
Is it the same criterion (low GS) that caused both DISARM events? If so, why did I get a crash detection message in the GCS only in the first case?
What log analyzing software are you using for your graphs above?
Finally, as a potential future feature request, would it not be possible to make crash detection a bit smarter? My rough ideas are based on two criteria:
1 - suspiciously still IMU values and
2 - no response to control surface deflections.
It is not as easy as using trigger values but might be a further check, invoked once trigger values indicate that perhaps something is wrong.
Aha, let me see if I understand correctly. You are saying that low GS led to
the autopilot deciding the vehicle was no longer in flight, correct?
Correct.
Does this (low GS based, non flying quesstimate) qualify as a crash? The
documentation of crash detection suggests that it is based on
acceleration trigger only. If other factors are in play, should it not
also be mentioned somewhere?
The documentation is inaccurate. There is an acceleration trigger,
however. Yes, it should be mentioned!
Is it the same criterion (low GS) that caused both DISARM events? If so,
why did I get a crash detection message in the GCS only in the first
case?
That I don’t know. I’m hoping it is lost telemetry packets; 1.6% were
lost.
What log analyzing software are you using for your graphs above?
MAVExplorer
Finally, as a potential future feature request, would it not be possible to
make crash detection a bit smarter? My rough ideas are based on two
criteria:
1 - suspiciously still IMU values and
2 - no response to control surface deflections.
IMU values may not be still if the vehicle is still trying to drive
itself. This sometimes happens onquadcopters when they bounce around on
the ground so the IMUs never quiesce. May still be feasible. And I would
guess that if you’re in a mode where you should be upright we should be
able to check if gravity’s the wrong way up and disarm based on that.
Not responding to commands is another option.
It is not as easy as using trigger values but might be a further check,
invoked once trigger values indicate that perhaps something is wrong.
Yeah, trigger values are not great, but accumulating evidence (e.g.
roll/pitch discrepancies over time) is problematic. Possibly we could
check the integrators to see if they’re so wound up we really have to be
crashed.
Also - not using the estimated airspeed unless you have an airspeed sensor
is another option we should consider.
(EKF delegates this estimation to DCM)