I’m not really sure that this is an ArduCopter issue. It seems more likely that it’s a BLHeli issue, but someone that saw my post over on RCGroups suggested that I post information about this episode here, so here it is.
A few weeks ago we were working through a series of quick test flights on a batch of small quads which use PixRacer and an Odroid as a secondary controller. They are roughly stretched racing drones with all CF frames and typical race motors and ESCs, running 7" props. We’ve got maybe 6 or 8 hours of flight time on them, and have them pretty well tuned.
When we configure these quads with the Odroid and Wifi, we abandon the usual 900MHz telemetry radio, and we have a failsafe behavior built in that trips an RTL if we lose a heartbeat to the ground for 20 seconds. We have the system setup for full auto flights, launch to recovery, but have a safety pilot (me) standing by in case things don’t go as planned. On about the 5th quad that we tested for the day, the GCS operator got the quad to arm, but it never launched. We decided that I should takeoff manually in stabilized mode and then switch to auto once in the air. That worked fine, but when I switched to auto it was supposed to climb about 20m and then transition to a WP course. Instead it kept climbing. My GCS operator indicated that he wasn’t getting any feedback from the copter, so I should take control. It was at about 70m at this point. Unfortunately, instead of switching the mode switch, I accidentally disarmed (switches next to each other, and not the first time this has happened). I quickly rearmed, but when the motors started back up, they started in reverse, and of course the rest of the flight was pretty short. I did not think that this was possible. I race drones as a hobby, and have disarmed and re-armed in flight countless times, and have never had this happen.
I’m pretty sure that all 4 motors were reversed, as the copter remained extremely level as it accelerated at the ground. It hit completely flat, and one prop bent down enough to strike one of the CF arms, with the trailing edge getting a pretty significant gouge where it hit the arm, a pretty good indicator that the props were spinning backward. We had done something similar once before, with a solid 50m of free-fall, and rearming worked just fine. We are running a dev version of 3.5.7 which does not support Dshot, so we were running Oneshot125. To my knowledge, there is no way to command motor reversal over the Oneshot protocol, hence my feeling that this is most likely a BLHeli issue.
Unfortunately, the log file is truncated shortly before the disarm. I can tell from the log why it was climbing unexpectedly though - we had lost coms with the GCS, and had hit the 20 second timeout, and it was actually climbing to the RTL point. Sadly, if I had let it be, it would probably have reach RTL and then landed safely by itself. On the bright side, the use of a race-type frame paid off. The only damage was the one prop with the dinged trailing edge and the Odroid that bent from the g’s at impact. It actually ejected the chip off of the eMMC card. The battery is on the bottom of the frame and serves as our landing gear, in typical race-fashion, and amazingly it survived as well.
I’ve rebooted the PixRacer on both USB and battery power, and it boots fine, and all the motors arm in the usual direction. I’m not sure if it matters, but the ESCs are Emax 20Amp Bullets, with whatever version of BLHeli shipped on them. They support Dshot, but as I mentioned, our PixRacer firmware did not.
If anyone has ever heard of such a thing, please share. I’m at a loss.