We have been experimenting with two heavy photography octocopters running 2.9.1 and we have run into some safety issues regarding the Arducopter. The purpose of this post is not to blame anyone, but to find solutions and notify other users about some erratic and possibly dangerous behaviour of the Ardu that can be triggered with various actions.
The Ardupilot was chosen because of its features and the good reputation both of the software and the community over other possible alternatives but now we find that our arducopter-running photography drones may be too unsafe to be flown at public.
We run the Ardu on RCTimer RCFlyer boards. Sorry. But as the board is a complete clone, I suspect that these may be issues with the software, occurring also at original hardware, which is why I want to share these with you.
Here are our findings:
-1: Random throttling of motors with older firmware in Atmega32-U2.
This caused my 5 kg drone to flip uncontrollably suddenly at full throtle, on ground. Luckily it did not hit me. After searching this forum and Internet, I found that the older firmware was suspectible causing spikes in channel values in certain configurations which has caused for example erroneus few return-to-home activations leading to crashes. I managed to reproduce this without propellers. This behaviour was corrected when the firmware was updated. Only material damages involved.
-2: Random throttling of motors when the board is reset while flight batteries are connected.
If the FC is supplied with its own power supply, be sure NOT to power it up AFTER flight batteries are connected OR cause the board reset in some other way. When the board is reset while the motors are energized, the FC -WILL- spin the motors at full throttle randomly for a short period of time.
I noticed this behaviour first when I was tuning the copter with my laptop. Once in a while, when plugging the USB onto the board, the motors spun randomly for a short period of time. Also if the reset is caused by cutting the power to the FC, the motors also were throttled up randomly. Note that this has nothing to do whether the board is in armed state of not. The FC sends probably erroneus PWM signal to the ESCs which react to it as spinning the motors. Because no other Atmega-based FC I have had does this, I suspect this to be a software problem?
Unfortunately, my friend who has a similar copter, had an accident involving this. He runs his FC from separate battery for redundancy than the motors. He accidentally powered the board up while the motors were already energized and at the moment the FC booted, the 300+W high torque motors spinning 12" propellers were brought up to full throttle. He had his hand and foot severed by the propellers quite seriously.
This issue is present and can be reproduced on 2.9.1.
-3. Erratic behaviour of the failsafe.
This happened to me few days ago. I was flying my drone while it lost control. The failsafe landed the drone but it failed to power down the motors while on the ground. The failsafe functionality was tested a day before the flight without propellers and it did work; it first dropped the throttle to pre-defined value and then shut down the motors. But not this time. Also when I approached the crashed drone, it did not respond to any commands. It just ran on a high throttle setting, digging holes in the ground and as I did not want to approach it until the batteries ran out, one of the blocked motors caught fire, shorted and destroyed its esc.
The drone survived the crash but not the almost full-throttle run of the throttles on ground upside-down.
For something like three years ago when I built my first multirotor drone, I added a feature to the FC I used that shuts down the motors if a pre-defined roll/pitch angle is exceeded to prevent motors burning if the drone is crashed upside down. But I had not implemented it yet on the Ardu.. with the following results:
Radio equipment I have: 35 MHz Corona 6 channel receiver, 2,4 GHz XBee modem, Hitec Optic 6 transmitter. The radios work fine.. the other drone has FrSky systems without radio modem.
The ESCs run SimonK firmware.
-4. On OctaV frames, the Mission Planner software changes the frame mode to non-V-octa when configuration settings are changed.
The Mission Planner has no OctaV frame configuration available on its drop-down menu. When any other parameter is changed, the Mission Planner switches the OctaV mode to Octa X or +, every time. No indications on this. If the user does not remember to change this back to OctaV on command-line an attept to take-off leads to a crash. This could also be a potentially dangerous bug.