Hi,
I encountered an interesting crash today.
Quadcopter running 3.4.2 on a pixhawk with zubax gps, idled all 4 motors in the air for no apparent reason.
The quad was in guided mode and fell from the sky.
Reviewing the log showed all 4 motors going down to 1000 with no reason.
I suspect it has some thing to do with 3.4.2 since my other quads (2 of them with 3.3) fly perfectly with the same configuration.
2016-11-27 14-27-43.bin (3.1 MB)
I went over the log again. It is very disturbing!! (If I understand it correctly)
Flight mode is POSHOLD throttle input is 1500, all 4 motors go to 1000.
After touching the ground (crashing…) motors came back to life.
This might be a very crucial bug.
Double check your parameters, Ch7 - Ch12 for a value of (command) 31
You triggered an emergency motor stop alright.
@pmshop double checked CH7 - CH12 and all are CH#_OPT=0.
Any other ideas?
@rmackay9 you might want to look in to this unless I overlooked something.
I’ve had a look at the logs and this one is very strange which is not a good thing.
At line 82290 there is a 2 millisecond delay and then the EKF declares that it got a home position, and we get a print out of the flight mode and some other events including that the vehicle is armed, interlock-disabled, etc.
I’m not sure what has happened here so I’ll discuss with the other developers.
Raviv,
Looks like you were using a GCS. Do you have a tlog? also any other details you can give on what was going on at the time would be helpful. Which GCS were you using and was anything else happening at the time?
Tridge, Peter and I had a deeper look at the logs and we’ve found the problem. If the GCS sends an “arm” message while in flight, it can trigger this behaviour. The issue has been there in previous versions of the code as well, but in AC3.4 we ensure the motors don’t spin for two seconds after arming.
We will add a check that the vehicle isn’t already armed and push out a fix as soon as possible.
We were using our companion computer module (Percepto Core) which acts as a GCS and either relays commands from our cloud system or drives the vehicle autonomously according to some algorithm. It’s possible that due to an error by the cloud system operator an ARM command was issued while the vehicle was in flight. At the moment we don’t prevent this from happening (this behavior will change).
We also know that the motors began spinning again right after the vehicle has hit the ground so I believe your analysis of the issue was accurate and I am very grateful for your help!
