After many successful flights over the past few days I started my second autopilot flight this morning with my IRIS+.
I powered up the drone, had it connected to my PC via 900Mhz telemetry. Turned on the remote.
Pressed the arm button on the top of the drone. Remote was in acro mode. Throttle joystick down and to the right to arm the drone.
Drone armed. Switched to auto. Throttle up slightly and drone took off.
I then switched off the remote to save battery because it’s on auto and I’ve disabled any RTL if it loses comms with the remote. I’ve done this many times.
It may have been less than a second that passed and all engines shut down and drone fell out of the sky from about 10 meters altitude. Hit a concrete pillar in front of us and broke two arms, damaged body, destroyed gimbal, scratched gopro.
I’ve downloaded the log for the flight and it is attached.
First thing I noticed is that it switched back to “Acro” and it looks like before it switches the ThrOut is around 800 and then it drops to zero. Checked the remote after flight and I’m pretty sure the throttle on the remote at the time the fall began was at 25% - so not completely zero.
So did me switching off the remote control trigger a mode change to acro and then a zero throttle? If so, why on earth would it do that? I’ve turned off the remote as standard procedure for the past 10 or so flights without anything like this happening.
Something else I noticed in the video is that the motors cut and it generates a double beep right before impact:
Any help diagnosing this would be very much appreciated. I’m concerned because this happened on takeoff with 4 people standing around the drone and it happened to not fall on one of them. If it had, it could have been a much worse morning. I’ve never even heard of an IRIS+ or any arducopter doing this.
My Iris+ is doing the exact same thing. It will take off and fly from 1 to 15 seconds and then fall out of the sky. My problems didn’t start until after a crash in a Mission Planner flight. Flying low over grass til this one is figured out.
It looks like when you turned the Transmitter off it saw the mode switch change to 0. Flight Mode 1 is Acro so it switched to Acro mode. This did not happen right away though and it should have detected this as a failsafe condition and continued the mission.
You didn’t happen to change it to Acro mode since Auto and Acro are close together. Also don’t see the failsafe message in the logs but don’t know if you have that turned off if it just doesn’t report it.
The double beep just before impact was the pixhawk disarming.
Set your throttle failsafe to 2 not 0. Then an auto mission will always carry on but you still have a radio failsafe when flying in non auto mode. This may have prevented the crash as having it on 0 is why no failsafe was generated.
More importantly though DON’T turn off the transmitter! it’s asking for trouble. If the auto mission is going wrong you should be able to just flip the flight mode switch and re-take control which is a bit tricky when you have the transmitter turned off.
“DON’T turn off the transmitter! it’s asking for trouble.” and “+1 on never turning the TX off, very bad practice that.” <-hmmm!
These statements are not congruent with reliable and fail-safe flight controller software. The flight controller should be able to handle a lack of signal from the RC transmitter; should NEVER be “asking for trouble”. Whether the copter shuts down or continues should be at the discretion of the operator’s desired mode of fail-safe operation. i.e., land when RC transmitter signal lost, etc.
My car has cruise control, are you saying I should remove the accelerator pedal.
What if theres a hardware failure with the gps? What if theres a problem withe a mission parameter? What if you miscalculated the height of that tree? What if you’re about to fly into a full size craft? What if you haven’t set the failsafe?
So yes, turning off the transmitter IS asking for trouble as is relying on failsafes to get you out of trouble. A failsafe is a last resort imo.
When I fly an auto mission the transmitter stays on and throttle at 50% because I can’t predict the unexpected and want to be able to retake control should I need to. Our flying field has had unexpected low over passes from police helicopters in the past and I certainly dont want to hit one of those.
I attached a log file from one of my failed flights. The Iris+ took off normally and then motors stopped and it dropped straight back down. I have not ever turned off my transmitter during a flight. This problem has started after a programmed flight that ended in a crash.
Size (kb) 657.931640625
No of lines 9180
Duration 0:00:37
Vehicletype ArduCopter
Firmware Version V3.2.1
Firmware Hash 36b405fb
Hardware Type
Free Mem 0
Skipped Lines 0
Test: Autotune = UNKNOWN - No ATUN log data
Test: Balance/Twist = GOOD -
Test: Brownout = GOOD -
Test: Compass = WARN - Moderate change in mag_field (25.13%)
Max mag field length (577.67) > recommended (550.00)
Test: Dupe Log Data = GOOD -
Test: Empty = GOOD -
Test: Event/Failsafe = FAIL - ERR found: CRASH
Test: GPS = GOOD -
Test: IMU Mismatch = FAIL - Check vibration or accelerometer calibration. (Mismatch: 34.43, WARN: 0.75, FAIL: 1.50)
Test: Parameters = GOOD -
Test: PM = WARN - 3 slow loop lines found, max 8.85% on line 4764
Test: Pitch/Roll = GOOD -
Test: Thrust = FAIL - Avg climb rate 48.43 cm/s for throttle avg 733
Test: VCC = GOOD -
This data flash log is even worse than the previous one:
Size (kb) 841.0458984375
No of lines 11743
Duration 0:00:48
Vehicletype ArduCopter
Firmware Version V3.2.1
Firmware Hash 36b405fb
Hardware Type
Free Mem 0
Skipped Lines 0
Test: Autotune = UNKNOWN - No ATUN log data
Test: Balance/Twist = GOOD -
Test: Brownout = GOOD -
Test: Compass = GOOD - mag_field interference within limits (17.79%)
Max mag field length (562.33) > recommended (550.00)
Test: Dupe Log Data = GOOD -
Test: Empty = GOOD -
Test: Event/Failsafe = FAIL - ERRs found: CRASH GPS_GLITCH
Test: GPS = FAIL - GPS glitch errors found (1)
Min satellites: 7, Max HDop: 2.14
Test: IMU Mismatch = FAIL - Check vibration or accelerometer calibration. (Mismatch: 97.01, WARN: 0.75, FAIL: 1.50)
Test: Parameters = GOOD -
Test: PM = WARN - 4 slow loop lines found, max 8.65% on line 1703
Test: Pitch/Roll = GOOD -
Test: Thrust = GOOD -
Test: VCC = GOOD -
You still have an IMU issue and now there was a GPS glitch.
I believe that the IMU mismatch is due to one of the two IMUs having a definite problem.
Thanks iseries. I think you’re probably on the right track - I’d guess the power-down may have been misinterpreted as a switch to acro but I want to be sure that’s what it is. Thinking about switching around channels on the mode switch so that 0 is ‘auto’. No I didn’t change to acro manually.
Thanks MarkM - interesting that it disarmed and a bit weird. I guess in acro with throttle at zero it might disarm, but that quickly? And without a joystick bottom-right to disarm it?
Regarding the “bad practice” debate. My focus is really on understanding how the software is supposed to behave and how that compares to real-world experience. I’m deeply interested in ArduCopter and drone’s in general and I’ve contributed to debugging ArduPilot: github.com/diydrones/ardupilot/ … t-68571525
So really just want to thoroughly understand what happened here - and if we uncover it there may be other conditions that would lead to the same problem. For example an antenna disconnect or a transceiver failure or the drone or pilot inadvertently entering a faraday cage or similar with sudden drop in signal.
FS_THR_ENABLE is set to 0 which means turning off the transmitter will result in the crash you had as the FC has been told not to do anything when you lose the rc link.
Set it to 2 that way it will RTL with loss of radio signal when flying normally but if you are on an auto mission it will still carry on with a loss of radio signal.