After more than two hundred flights with my APM2 equipped quad, today, in the remotest of possible locations my quad failed to respond and attempted to fly away by itself! All I can say is thank goodness for Knobthorn trees.
I wanted to get some video of the area but didn't have my small cam with me so I attached my Galaxy Smartphone to the front of the quad, I have done this before and know that the video won't be that great (lots of jello) but will at least give an idea of the scenery. I waited for satellite lock and then hand launched (too much dust on the ground) just in front of where I was standing, I went slowly up to about 20m, hoverered then did a 180deg pirouette and slowly started descending back towards my position.
When the quad was about 3m from me and 2m off the ground I throttled up to stop the descent which was fine but now the quad was drifting forward slowly so I tried to tilt it backwards... suddenly I had that sickening realization that it wasn't responding, I wiggled the sticks...NOTHING!. I ran towards it but it was still drifting forward and climbing very slowly, now at about 2.5m. It continued very calmly and smoothly and I briefly considered throwing the only thing in hand (my transmitter) at it to try bring it down, but it flew on until it collided with a Knobthron tree at about 4m high.
3 motors were jammed by branches but one was still spinning away calmly. I wasn't... I was able to run to the nearby parked pickup and drive under the tree, reach up to unplug the battery and then get the quad down.
I have read the horror stories of fly-aways but one naturally never expects it to 'happen to me'.
- My radio is a tried and tested two year old Hitec Aurora 9 which has one of the most robust AFHSS 2.4GHz systems. The quad was 3m from me when it happened!
- My failsafe is setup correctly and double-tested, with the throttle channel going to 900ms on event of signal loss.
- All four my SS 30A ESC's (2A BEC) power the APM2 (each tested 0.09v of each other) effectively quadrupling the current capacity. I've never had a suggestion of a brownout.
So what happened? I don't know, I can't see anything definative in the logs (attached). If someone has any ideas I'd be very grateful!
As for now my faith in APM2 has been shattered, like an old friend you can no longer trust.
Your first 'GPS' logged data is halfway through the log at line 7021/22...
this implies the GPS lock did not occur until this line. How to sync up the GPS stamp with the flight events??
Causality is not assured though GPS lock discussions abound.
The 'NTUN' tagged lines also start showing up at this time. Again, causality??
Yes the flight modes were configured correctly and validated in the mission planner. You can see the configuration in the log file. They were position 0, 3 and 5. As you can see none of them have RTL. I'm not sure why the log analysis shows I was in RTL or flying in RTL as I was not and had no ability to switch to that mode.
My 2 cents either the analysis is getting confused between position 3 (alt hold with simple) or somehow the APM decided to switch itself into RTL mode.
Pos 0: STABILIZE, Simple: OFF
Pos 1: STABILIZE, Simple: OFF
Pos 2: STABILIZE, Simple: OFF
Pos 3: ALT_HOLD, Simple: ON
Pos 4: STABILIZE, Simple: OFF
Pos 5: LOITER, Simple: OFF
Craig, John Arne Birkeland (developer of the PPM software) and I spent a couple of hours going over the logs and brain storming ideas that could lead to the loss of radio signal.
It's clear from the logs that at line 10151 all radio updates stop. The throttle pwm does not drop below 975 so the APM doesn't think that anything is wrong. You were in stabilize mode as you said and besides the radio input freezing there are almost no other signs of troubles....except we do see some increase in the gps delays around the time of the problem which adds some evidence that the phone was outputting a strong enough signal to disrupt the gps at least (and you could extrapolate that maybe it also affected the radio).
We performed various tests of the ppm software on an APM2 and APM2.5 and confirmed that:
1. if you disconnect power or ground to the radio the ppm enters failsafe (throttle drops <975)
2. if you disconnect a single channel that channel simply stops updating except for the throttle channel on the latest ppm software which ships with the APM2.5. On 2.5 boards it goes into failsafe.
3. if you disconnect all signal wires between the apm and the radio the apm enters failsafe.
...so basically we didn't have any luck reproducing the problem. The ideas that we came up with were:
a) your radio failsafe isn't set-up and your rx/tx lost contact (unlikely because you were only 3m away and you said you've tested this)
b) the wires for channels 1 to 4 (roll, pitch, yaw, throttle) somehow became disconnected (physically unlikely)
c) the phone caused some low-level interference to either the radio or the APM.
d) you're somehow running a very old version of the ppm encoder software and had a brownout (seems unlikely that you would have downgraded your ppm software)
e) a hardware fault that breaks the connection between the ppm encoder chip and the main Atmel 2560
..these are all very unlikely so we'd really like your help in trying to reproduce the events that led to the failure.
1. turn off your radio and confirm that your throttle drops to below 975
2. try disconnecting some of the signal wires and confirm that only the disconnected wire stops updating
3. put your phone on top of your APM & receiver and switch in and out of airplane mode and see if your rx/tx stops updating
Also could you tell us if your receiver is connected with separate wires for each channel to the APM2? You're not using ppm-sum or anything like that?
There's some additional failsafes that, based upon this event, we're thinking of adding to the code:
1. check in the main code that the ppm encoder is still providing values to the main chip
2. check that values from the rx have changed at least a little bit within the last two seconds
I've replied over on your thread about your particular crash. I think it's caused by two issues...a radio failure which caused your copter to go into RTL although it then appears you regained control. ...and I also think your copter PIDs are quite off. Maybe the Roll and Pitch P values are too low which may have contributed to an 'out of control' type feeling.
Your situation seems quite different from Graham Dyer's although it's interesting that you're both using the same radio. Perhaps it's a very common radio though, I'm not sure.
Apologies if I've read the situation wrong, it's hard to tell everything from the log files.
I'm very interested to see your log files. Sometimes very different problems can exhibit similar symptoms.
Hi Randy, thank you so much for assisting me with this. I'm back home now so am able to run the tests requested.
Attached is the .log and .tlog from the following test.
1) Connect, wait for 3D Sat fix, take off (simulated - no props on), switch off Tx, wait, switch on Tx, throttle down.
3) Connect, check for 3D Sat fix, take off (simulated - no props on), place phone directly on top of APM2, wait, switch on Airplane mode, Switch Airplane mode off, switch WiFi on, switch WiFi off, remove phone, throttle down.
Which wires would you like me to disconnect, Rx to APM or APM to ESC's?
Sorry, correct .tlog
KMZ of the flight and crash, max vertical height was 32m and max horizontal distance from Tx was 28m
Graham, please could you give us you Hitec transmitter and receiver firmware version ? Did you update them ?