While flying conservation training in the Cerrado of Brazil, an F450 Quad flew away despite tripping failsafe and geofence. The F450 was operating with a Pixracer V1 flight controller with Arduplane 3.6. The plane was recovered undamaged on top of a 45 foot tree. Analysis of the hardware indicated a faulty ia6b RC Radio. We have not been able to determine why RTL did not return the plane or how to prevent a fly away in a similar situation.2019-02-06 13-35-09.tlog (856.2 KB)
Hi David,
My mistake concerning firmware, we installed Arducopter 3.6.
The ia6b receiver failed in hardware, not due to interference. My concern is with how Arducopter responded to the failed RC receiver. As you can see in the telemetry, the failed RC receiver sent spurious signals to include 2000 pwm on RC 3 (throttle), driving the aircraft up even though it should have been landing. It seems Arducopter is taking “guidance” from the failed RC receiver rather than ignoring the failed RC receiver. My understanding is that in RTL mode, Arducopter does take “guidance” from the RC receiver. Perhaps if we had set a Fence, Arducopter would have gone into GUIDANCE mode. If GUIDANCE mode ignores RC inputs while in FENCE BREACH, then perhaps the aircraft would have been contained. So let me restate my question, “In what modes and under what conditions does Arducopter 3.6 ignore RC inputs?”
Thanks
If there’s a dataflash log (aka .bin file) that would be good… but perhaps that’s not possible because the vehicle has been lost?
It doesn’t look like the fence was enabled because FENCE_ENABLE = 0.
Near the end of the log it looks like the vehicle was switched to stabilize mode (from the ground station or maybe the receiver is setup to increase channel 5 to full when it loses contact with the transmitter?) and throttle went to full. I guess this is what you mean when you say there was an issue with the RC transmitter and receiver? It’s definitely a good idea to test the failsafe when the vehicle is on the ground. Anyway, I guess this is obvious in hind sight and it’s no fun to hear this.
The vibration levels on the vehicle are a bit high and there’s a lot of “clipping” (means IMU accelerations are beyond the range of the sensors). If the GCS was Mission Planner you might have noticed that the “Vibe” field turned red on the HUD?
High vibrations can lead to bad altitude and climb rate estimates which can cause the vehicle to not be able to control it’s altitude. I think this happened during this flight because the vehicle continues to climb when switch to RTL and LAND. In the tlogs we also see the sign of the EKF being confused because it shows a negative climb rate (i.e. it thinks it is falling) but the altitude is going up. I think this is caused by high vibration although we need to improve AP’s ability to deal with this situation as well.
Really sorry for the loss of this copter. I guess there’s some thing you can do on your side for the next vehicle:
- use more vibration dampening foam or use an autopilot with build-in vibration isolation (like the Cube)
- double check the failsafes (fence, RC)
An on the AP software side we will work on improving (again) our resistance to high vibration levels.
Thanks for the analysis. If you follow the log to the end you will notice we picked up some telemetry after the copter landed in the top of a tall tree. Two of the rangers climbed the tree and recovered the copter undamaged. We assessed the hardware and discovered the ia6b RC radio was faulty. We helped the rangers build 5 copters and several fixed wing aircraft during the week, so the tempo was high and we simply could not take to time for more thorough evaluation before each flight. This aircraft had flown three prior times that day with RTL working fine. We were using Mission Planner and I did notice the vibration but it did not appear the cause. When the copter started to climb telemetry indicated throttle (RC3) at 2000 but throttle was low (1000). After the flight we discovered the RC Radio was bound but not responding correctly to RC transmitter signals. I commanded RTL via GCS during flight as the faulty RC Radio was inhibiting Arducopter from sensing RC Failsafe. As you noticed we did not have a fence on that flight. I am hopeful that if we had a fence set the copter would have switched to GUIDED MODE and ignored the faulty RC signals. Following recovery we replaced the RC radio and the copter performed well again.
This is a link to dataflash: https://drive.google.com/file/d/17N7wwayl2H_SBnn_esjV6acNIRB3zewh/view?usp=sharing