Hi Droners. I've been having a problem with RTL using ArduCopter 2.6 for a while. It's intermittent, but annoying and a bit worrisome. When I take off I always test RTL if I'm going to fly FPV. That way it can come home if I have trouble. The problem is, for the last few versions of AC2, RTL occasionally flies away, instead of flying home. Not only away, but away at crazy high speed.

Take a look at the attached video for an example. Note that when switched into RTL mode (mode is shown lower right), the 'copter starts to move (away from me, mind you) and gradually pitches more and more until I abort the RTL and go back to STABILIZE mode. Also note the distance to home, as indicated in the OSD is 24m, which is about right.

Looking at the log file (also attached), when switching to RTL mode, the lat_error/long_error goes from 0/0 to 521/1000 (and grows throughout the RTL event). Is that in metres? Lat/Long decimal places?

Has this been observed by anyone else? Is it confirmed fixed in a particular version? Are there any other tests I should perform to try to catch this silly bug?

* APM2 hardware
* External MediaTek GPS
* Spectrum RCRx
* AC2.6 firmware
* XAircraft Quad
* GoPro and VTx streams recorded

Keep dronin',

p.s. I know what many of you will think: "Just upgrade to 2.7.3 and this will go away". Maybe, but I can't install 2.7+ on my current batch of APM2. I can install it on APM2.5, but not APM2. This will be a subject of a future analysis and bug report forum post.

Views: 3304


Reply to This

Replies to This Discussion

Maybe one of the reason, when you take off, Home position saved with same error (in example 1km far from your location). While you flying, GPS got more accurate position. Now you switch to RTL and copter start to moving to inaccurate Home position. If I'm right, this situation must be in logs...

That's possible, and from the logs, I can't tell.  However, a few things lead me to think this is not the cause:

* I take off with a good solid lock (10 satellites in this case)

* The copter accelerates to a higher speed than normal while returning home

* Given time, the copter will pitch very steeply (about 30 degrees in this example).  How far I don't know because I always go back to STABILIZE before it goes too crazy. 

I will try a few other experiments, however, including using the new LEA-6 GPS which is far more accurate, but I think it's something else. 

So, nobody else has had this problem?

I actually do have the same problem in 2.7.3.

I have to say I didn't test RTL too much. Just 4/5 times. The first time it was ok. Landing point was shifted by 10 to 20 meters but behavior was fine. The other times it was just flying crazy fast in some random direction. My yaw pids are not perfect but I don't think this is a problem. I will test further.

I agree.  I also have seen some strange behaviour with 2.7.3 RTL.  I don't completely trust it.  

I slowed the NAV speed a bit and tested RTL more times (around 10) and it always worked decently. I didn't change too much of the other parameters, wonder what it was that made it go crazy.

I still don't trust it 100 %. Also I'd like the switching between flight modes to be faster (in order to recover a crazy auto mode in time). Currently there is a delay of around a second and this is also true when you enter failsafe. If I turn off the radio in stabilize mode, the copter drops 5 to 10 meters with motors off before entering RTL.

Interesting.  So it happens in 2.7 as well.  Perhaps some developers could weigh in on this problem; perhaps we could gather more real-world data to help track it down.  Maybe we have to go back to older firmwares to see where the problem first appeared.

I'm also not aware of a bug report for this problem.  I'll see about adding one so it can be regressed properly. 

Slowing NAV speed is a good idea.  It does seem the drone tries to fly away at an unreasonable speed. Keep at trying to reproduce it.  I note that sometimes it happens 100% of the time, other packs it never happens.  I've also got a flyable 2.7.3 firmware now so I can test it beside the 2.6 firmware. 

It sucks to not be able to trust RTL.  I consider it a key feature of an autopilot and essential for FPV flying.  When you're way out and your video begins to crud up, it's comforting to know RTL works. 


This looks familiar, although in my case my quad was running in autopilot and suddenly decided to take it's own route. Within seconds and before I could react, it was completely off course and out of line of site.

As a last resort I activated the RTL failsafe and surprisingly the quad made it back but was flying backwards, unfortunately it fell out of the sky before I could land it.

Analysis of the logs and on board video seem to indicate that there was a compass/heading error which slowly magnified as the mission progressed. As such, it flew perfectly fine on the first 3-4 waypoints, then started to get it's bearings wrong,  after which it snowballed into a crazy race across the sky.

I suspect there is something wrong with the compass, but after retrieving and repairing the quad, all bench tests seem to prove otherwise. I will test it again in the field tomorrow.

I did more test and happen to find the problem again (although rarely). I usually wait 20 seconds more after getting the gps fix in order to be safer and usually works but RTL is the safety related mode and should be fully trustable.

Anyway, if it's a problem in setting the home position it should fly consistent to the wrong home (and this could be due to a twitch in gps during arming such as those deeply discussed in the main 2.7.3 released thread). But the behaviour is somewhat different. The copter, when functional, rises straight up 15 meters stay there a while and start cruising home. Instead when crazy it start rising 15 meters while drifting or rotating a bit (or a lot sometimes) and then without stopping at all starts increasing this drift speed to a random direction.

Will test further but so far (in around 5 flights) I noticed that if it goes well the first time it goes well always (which might lead to think that the problem is during arming). For now I'm just testing it right after take off and if it works ok, I feel decently safe.

Hi Agusto.  Thanks for looking into this problem more.

One test I did is to reproduce the problem while recording the GPS telemetry via the OSD.  What I find is that the distance  to home and direction are correct.  As it usually flies away very fast, the distance home actually increases.  You can see this in the video I posted above.

I will look at similar flights to try to diagnose the problem more from existing data.

OK, I analyzed some more data and found a better example.  In this example I use RTL twice and the second time I let it run a few seconds.  I've attached a video, an excerpted flight log and the flight log stripped down to the NTUN and MOD lines. 

Some interesting points:

* The drone flies in the direction of the home arrow, though that direction changes. 

* Distance home increases.

* long_error and lat_error from the NTUN lines of the log (second and third numbers, respectively) increase rapidly while in RTL mode.  See Flightlog119ExerptNTUN.txt

* target_bearing changes (perhaps to match moving lat_error and long_error)

* during this test the compass bearing shown on the OSD is incorrect (off by nearly 180 degrees), as it was in the flight video posted above.  In a similar flight from the same day, where RTL worked fine, the compass reports correctly.  Coincidence?  Probably not. 

OK, I'm going to create a bug report using this data.  Can someone post similar data from a flight with a 2.7 firmware?  I will if I can duplicate it, but my best examples are all with 2.6 firmware. 


Ouch, I didn't notice the distance and arrow the first time i saw the video but yes, that is the behavior!

I wish I had renamed the logs of my experiences but now I have no idea which ones were about this problem. Sorry, I'll keep them if I face it again (next weekend maybe).

If you observe the problem, download your logs after the flight for analysis.  Feel free to comment on the bug report with your additional data:


Reply to Discussion


© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service