Hi everyone,
I was testing RTL failsafe today using 2.9.1b and my hex flew away, losing altitude and crashing before it got too far.
I had successfully tested LOITER, RTL and a quick AUTO prior to nervously switching off my transmitter to test the failsafe RTL. It was at the home position on the ground so I was expecting it to just switch to LAND and power down but it took off and flew away on maximum left bank and max forward pitch. I immediately turned the tx back on to recover control but was too late.
Looking at the tlog it seems the compass was working fine earlier but not during that RTL - the red heading line is fixed oriented north during the bad RTL when it was actually heading off south-east.
Which raises some questions:
- it was at the home position when failsafe commanded RTL, I thought in this case it would just LAND?
- why did it over-bank and over-pitch to the point of crashing? Isn't attitude the highest priority controller?
- any clues as to what went wrong with the compass in the bad RTL given the previous LOITER+RTL+AUTO worked well?
- even with a bad compass, shouldn't the GPS inferred course have begun to influence it? Likely toilet bowling of course, but in this case it just headed straight away
Logs attached (dataflash+kmz+tlog). It's the last RTL in the log and at 55% in the tlog.
Any help appreciated, I'm pretty rattled by this one - thanks guys.
BTW, which field from the dataflash logs are compass heading? I couldn't find it in there. If YAW, what's the conversion to heading?
AC.
Replies
what parameter(s) exactly need to be disabled to avoid this temporarily ? (is unchecking the checkbox Auto in Hardware tab enough?)
@criro1999 - it's a uBlox.
GPS performance was great in this case but the compass was very far off, and the ArduCopter code currently doesn't take into account a GPS derived course.
@Andrew, Just curious, what GPS are you using? MediaTek or uBlox?
I have this issue with 2.9.1b also.
Never happened to me on 2.8.1.
When I am testing Loiter, from 10 flights, 2 Loiters are randomly working and from time to time RTL does fly away also.
Initially I did believe is because of power wires, but when switch back to 2.8.1, RTL work fine.
I believe issue is specific to 2.9.1b, I did find many comments about disabling COMPASS LEARN, or AUTO, etc.
My feeling is this issue (RTL or Loiter, even Auto - fly away) is related to INAV.
When I have a good vibration level, all is OK for Loiter, RTL, Auto. But if the vibration raise in flight after a value, then RTL or Loiter loose performance.
I keep running in 2.9.1b because Alt_Hold is real good, but I am not 100% in RTL or Loiter. As I said, it acts randomly for me.
It was days when Loiter and RTL was amazing for 9 flights. Then next day, same setup and PID, Loiter was unstable. When I tried RTL, fly away also. But as I said, I am using this carefully, hope next release to completely fix the Loiter or RTL fly away.
AC,
I'm very sorry to hear about your crash.
I've looked at your logs and the problem is that your APM didn't know which way it was facing because the Compass Learn function learned very bad offsets due to motor interference. Here is a graph of your throttle vs magfield. it starts off ok with the throttle at zero and the magfield at just over 300. This is a very good mag field. Then over the flight you can see that the field falls and falls until it's down at 50 when you finally disarm just before the bad flight.
For AC3.0 we've introduce compass motor compensation which allows you to somewhat offset the motor interference by doing a somewhat scary test in which you strap down the copter and fire up the motors with all the props on and ArduCopter measures the interference. With this in place, I'm going to recommend that people turn off compass learn or if they do leave it on, only leave it on for a short flight and then disable it - this seems to produce decent results.
I think 3dr is working on a GPS module with a compass built in which may make it easier to get the compass away from the motors and ESCs.
A couple of extra answers to some of your questions:
You're right, there is a bug in 2.9.1b. It is incorrectly comparing the waypoint raidius (which is meters) with the distance to home (which is cm) and the check is always failing. I found (and fixed) this bug about 1 week ago when checking the new fence code for 3.0.
No, the navigation controller in 2.9.1b (and earlier) has separate horizontal and vertical position controllers and the roll-pitch controller won't let off the gas to allow the alt-hold controller to do it's job properly. This is also fixed in 3.0. We've completely rewritten the nav controllers and this was one of the main things we wanted to sort out.
No, we don't use the GPS heading (which is actually the direction that you're moving in) and compare it with the copter's heading. It's slightly more complex because the copter can move in any direction so we can't simply compare heading with GPS course ... but we could compare desired direction of movement with the actual direction of movement from the GPS and do something if they become horribly out of whack. There would need to be checks built in re the speed and there's also nearly 1/2 second of delay from the GPS we would need to deal with .... but I have been thinking of trying to do something like this....
Hope this helps. The compass interference problems are a big problem and we've been trying to sort it out as part of 3.0 because it becomes very obvious with the new xy inertial nav.
This bad compass issue seems to be popping up all over the place, mine included.
One question: are you running the 3DR current sensor, and if so is it the only power to the APM or are you running a BEC as well.
Just trying to collect information looking for any common denominator on this.
you sould have a problem with you compass
try to make manual calibration