Hi,
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.
http://diydrones.com/profiles/blogs/octav-small-accident-key-learnings?xg_source=activity
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:
https://www.youtube.com/watch?v=_3bigN0phBU
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.
Replies
I had a runaway because of the GPS stall issue. I knew that the Mediatek GPS I had would sometimes stall (I asked about this on a different post) but I also wanted some telemetry data where the issue would show. I had therefore disabled all failsafe functions by my best knowledge or switched them to land only.
Now, however, I wanted some video from a greater height, so I put the copter on alt-hold and started climbing. Apparently somewhere after 100m the copter started acting weird and started speeding away. I would hear the MP tell me it had changed to RTL, which should not have been enabled at any failsafe or controller setting. I tried frantically to switch modes back and forth to regain control, but the copter was quickly out of visual range behind some trees.
Okay, so there is the Geofence, which had alt and circle selected, but it should have been disabled on the other selection. Did it still activate or did APM figure some other failsafe condition?
If I correlate the visual observation and the GPS track from telemetry, I see that the copter was not at all at the same location it thought is was, therefore triggering the behavior described in earlier replies.
I found the copter with sheer luck and luckily the damage was minimal. I see from the video it recorded that it suddenly makes some erratic maneuvers and starts zooming away, goes back and forth a little, makes a couple great circles and ultimately loses altitude making them, finally hitting a tree. Luckily the area is safe for flying in the sense that if the copter has any horizontal speed, it's likely to hit a tree rather than people or buildings.
So there are actually two different things: Failsafe or Geofence triggering without them being enabled and hard-to-control speedy escapades when GPS stalls or gives incoherent positions. Well, also it would not shut down the motors even though it was on the ground upside down, but luckily the ESC:s had stopped three out of four because they would not spin at all only making waste of one motor.
I'll link the video when I have edited 15 minutes of black screen and motor wailing out.
I have suggested Automatic disarm when flip/over preset tilt angle for Randy many months ago. I have even written the lines in the code to prove this is easy to do and will work. And I fly With it myself and all my friends. I use this for all modes With indirect throttle Control (althold, loiter, RTL, auto etc) except when in flip mode. Stabilize has no disarm on flip as you can manual stop With throttle stick. This may also be needed for restart if stuck in Threes etc.
Problem is if you crash upside Down With indirect throttle Control (eg RTL, althold) half of the motors will spinn at full Power trying to turn the copter around on its feet. This will burn the motors, and be a safety problem for random People finding the model.
So why is this not implemented yet Randy?
Why are you not listening to experienced pilots for safety advice?
Tony please PM me to get my personal safety improved Version of the code.
I am very much a new person to this craft. But after watching the video, the copter was the most unstable piece of equipment I have seen in any video, full stop. There are many issues here with this build before putting out a safety alert on the technology involved......
First problem sounds more like a field flight checklist failure than a hardware/software design failure. ie. you should always have control. So switch on (for me) is:
1. Power Tx, confirm battery level, throttle and switches at safe positions
2. Power Rx/APM at home position, and wait for GPS lock
3. Obtain telemetry - both in 3DR/MP, and on DX8
4. Confirm stabilise mode, DISARM and that voltages are flight ready
5. Connect flight batteries.
6. repeat step 4 before ARMING
Approaching aircraft after flight (crashed or otherwise):
1. Try and confirm DISARM and flight mode, either via MP telemetry or onboard LED activity.
2. Ensure position of craft is suitable for uninjured access to flight battery. Most craft can be flipped. Ironically, upside down is usually the best for me...;-)
3. Unplug flight battery
4. Unplug Rx/APM battery
re: The failsafe landed the drone but it failed to power down the motors while on the ground....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....
OK- so failsafe landed it, but it was crashed and upside down? What mode where you in when you lost control? How did failsafe get engaged - how did you lost control? Sorry, but there are contradictory statements here with crucial detail missing - you might want to upload so logs - perhaps one of the more experienced guys can help you identify root cause? If you put the craft in an unrecoverable attitude, no FC in the world will save it...
re: 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
Once deprived of power, the APM will not be sending *any* signals to the ESC's. It won't be doing *anything*. If your motors are doing *anything* without the APM in the loop, you need to look at your ESC's and your power distribution (including any BEC power to the APM, if you've got both rails seperated).
I have 2 APM powered quads, and they don't exhibit any strange motor behaviour if I cycle power to the APM. The ESC's bleep once every 3 seconds, and the props twitch, but that's it.
I don't mean to come across as negative, but most of the stories I read on here are often due to pilot error, construction error or checklist error. Ony a few genuine bugs in APM itself.