Dear developers, I had an unfortunate crash with a large hexa due to a single errorous ppm frame.
I am using the Motor Emergency Stop feature on channel 12 and while flying normally at low altitude the pixhawk received a single errorous frame which caused many channels to suddenly jump. An event was logged to stop the motors, which is as expected, but the event only cleared after approx 300 milliseconds and after this it took a further 600 milliseconds to even start spinning up the motors.
The blue line is RCIN12 (the emergency stop channel) and the others are the motor signals.
Why does it take so long to even clear the emergency stop event and why are the motor signals not immediatelly restored to their previous values? I am not an expert, but it seems like, that the PID controller stops working and is not executed in case of an emergency stop event. Is it possible to fix this issue? Do you know of any similar cases?
Another thing, that could have prevented the crash would be to only activate the emergency stop when the signal is received for lets say at least 1/4 of a second. Is there any chance this could be implemented in the next release?
My setup is a hexa, pixhawk cube black with Arducopter 3.6.12, RFD868x modules and a Horus. I am already in contact with the RFD guys to check the modems.
This is probably a similar scenario to the recent accidental parachute deployment. The discussion then (maybe a week ago) was perhaps aux options that are crash-o-match should require X number of loops or X milliseconds of RC input before triggering. This is probably another good example of that need.
But… When emergency stop was first released years ago, there was a delay. And that was a problem. If you’ve got a big copter flying towards someones head, you want that switch to work IMMEDIATELY.
Although I guess there could be a happy balance, where the switch throw is nearly immediate, but still a short delay to stop one bad frame from causing the problem.
It looks generally wrong to fly a big copter so close to someone’s heads. Having a milliseconds for the emergency stop trigger should not be the reason to do that
IMHO you must fly in a way that even 1000 ms triggering time shall be enough to not to hurt anyone.
I’m not saying anyone is intentionally flying near peoples heads… It’s called “emergency” for a reason… Sometimes things go wrong.
1 second is definitely too long, though. That’s about what it was when it was first released, and that one second could be the difference between stopping the motors and falling onto the ground, and slamming into a building.
We’re not all flying out in the open sky… Some people are doing inspections and flying very close to wires and buildings, etc.
I agree, that one second is too long, but something like 1/4 to 1/2 of a second should be adequate. Another possibility would be to make this a parameter, so everyone could decide for themself.
I don’t see a code path for such a delay so I’m not sure why it would take so long to being spinning the motors again. The code path is basically this:
When the emergency stop is activated, or the interlock is deactivated, it forces the AP_Motors spool state to shutdown, which forces the PWM output and max thrust to 0. The motors will stop immediately.
It will then automatically disarm after half disarm_delay parameter value.
If you reset the e-stop, or re-enable the interlock before the one half distarm_delay timer expires, the spool state will be immediately changed back to the state commanded by the flight mode you were in, which is usually THROTTLE_UNLIMITED. That restores full throttle control immediately without delay.
Actually yes. That is the reason. I missed the part where the spool state steps through shutdown to ground idle to spool up then to unlimited. That’s also why you see the line going up slowly from the e-stop being disabled.
Regarding the spool time, you can certainly reduce it all the way to 0 if you want. The idea behind it is to ramp the motors up from a stop to the minimum speed (aka ground idle). On smaller copters, this prevents sudden motor torque from flopping the copter around the ground when arming. On larger copters, it may be of no use. due to the copter’s own weight. Try setting it for zero and see if it handles ok. Or just a smaller value.
It appears to be 308ms from the time the motors stopped to the time they began spooling up. I’m not sure what the hz rate of logging is for all of this. So some of that delay is undoubtedly because it happens faster than it gets logged.
