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: 3315


Reply to This

Replies to This Discussion

I have observed this on my Quad for every version of APM I have used  (I have had my Quad about 7 months).  RTL has worked maybe 10% of the time.... the remaining 90% is scary.  I have mentioned this on few posts as far back as April.  I know others have the same problem.


The last time I tried RTL my quad ended up in a tree.. so I have given up on it and really have no idea how to fix it.  Stabilize, loiter and Alt Hold all have worked well for me.

I tried RTL a few times on the weekend in the heli, it seemed to work fine.  I'm really not sure why sometimes it seems to not work.

I set:

#define RTL_YAW YAW_LOOK_AT_HOME and this allows me to see which way it thinks home is.  So that helps too.

But, for whatever reason, it worked fine this weekend.

Hello all!

Im pretty new to this whole adrucopter (used since 2.6) and I have had this same problem since then as well.

Recently I got the 3dr radio setup and took my laptop to the field with me to fly.

On my first run both RTL and Auto seemed to run away (in the same direction interestingly enough).

When reviewing it appears as tho the quad had not *really* found home.

The GPS placement showed 30-40m from where the copter was really at. Mission planner showed gps 3dfix and both lights on apm2 were blue.

This happened at the begging of subsequent missions however by waiting a few more minutes the gps slowly corrected itself over time to very nearly the correct point. (SatCount was 6 or more at all time) and 6 missions were flown w/o incident and quite accurate landings (within 2m of take of point) once the settle in time was allowed.

Im kind of wondering if the "locked gps home wandering" has anything to do with seemingly run away RTL's etc.

Any one have any thoughts or experience any thing like this?


Neil - newbie here.

You didn't say which APM you have, but I was experiencing problems with the GPS on the APM2 showing my copter 20- to 50-ft from where it actually was, after several minutes of GPS Locked.  So far off that I was afraid to fly a mission.  I replaced the on-board GPS with the external UBlox GPS and the accuracy is now within a few feet.  And I am flying missions.

Thanks for the report, Neil.  Were you using a MediaTek GPS, perchance?  They're routinely off by that amount, at least early in the flight. 

As per my analysis earlier, the problem I've observed is with the 'copter thinking home is at least 1000m away - and moving!  Not quite the same situation.

Do you have flightlogs?  I could take a look at them to see if yours is the same problem. 

Thanks guys!

Im using the media tek GPS so it sounds like Im having that issue rather than what you (Fete Moblie)  experience then.


To Stephen -

I did say which apm I had! (Hidden in the middle where no one looks =)

Quote -

The GPS placement showed 30-40m from where the copter was really at. Mission planner showed gps 3dfix and both lights on apm2 were blue.


But alas just having a little fun! Thanks for the real world advice that the ublox will do much better.

Ill post if I have any other fly away type events once I let the media tek "settle", and get a ublox in a bit here.

Thanks all!


Hi droners. I did some testing with a newly-upgraded quad today and was able to gather more data on the bug.

I upgraded the firmware on one of my afflicted drones to AC2.7.3. I also upgraded the GPS on this bird from the Mtx to the Ublox, for greater accuracy, and installed new props. I was able to reliably reproduce this bug in 3 out of 4 flights. I was also able to figure out (sort of) a work-around. Please review the footage attached to this new thread (I created a new thread as I don't know how to add attachments to replies):


The flight log excerpts display the same sort of jump in long_error/lat_error differences as before (3rd and 4th numbers, respectively):

NTUN, 2548, 88, 0, 0, 1159, 338, 80, -137, 0, 0
NTUN, 2509, 86, 0, 0, 1159, 338, 100, -160, 0, 0
NTUN, 2496, 87, 0, 0, 1159, 338, 101, -136, 0, 0
MOD:RTL, 481
NTUN, 4140, 108, 3695, -1216, 739, 0, 138, -174, 2, 3
NTUN, 4128, 106, 3664, -1185, 413, -354, 152, -154, 6, 6
NTUN, 4026, 106, 3626, -1154, 490, -449, 191, -154, 9, 10

Some additional notes from these flights:
* When RTL is acting strange, Loiter also doesn't work well.
* The point it thinks is home is moving around a lot, and very fast, as evidenced by the home arrow on the OSD moving even when the copter is hovering stationary.
* I don't have a work-around, but in the video I explain a simple test that will determine if you can use RTL that flight.
* Re-arming the APM doesn't fix the problem, but rebooting the APM sometime does.

So, where do we start debugging this problem? Here are some ideas. Maybe some of the developers could weigh in on this problem as well.
* Custom build of APM with lots of features (limits, camera etc.) turned off.
* Custom build of OSD to display additional data from the APM, like lat_error and long_error.
* Dig through the code and figure out what's causing the lat_error and long_error to move so much. Maybe something to do with waypoints?

Can you provide an entire log and not just the excerpt. I need to see all the messages from the beginning.



I added logs as an attachment to the other thread:


Hmmm.  Didn't know until now that I can do that.  I don't think it's the exact same log as from the flight I edited excerpts from but shows the same signs of long_error/lat_error craziness. 

My next test will be to use a build of AC2.7.3 with limits and other features disabled.  I've also added the WP distance/arrow panel to my OSD so I can visualize the error and get an early warning that RTL is not to be trusted.  I'll also go back to ATTITUDE_MED for logging so the logfiles aren't so large. 

not sure if the compass was the reason, but it reminds me of when mine crashed into the sea.


maybe you can see some similarities.

Looking through your logs helped me find a small bug where the AP commands were failed to be reset when flying in Stab mode. It was a minor bug but could account for your strange behavior. It would however correct itself after a few seconds.

I'll post a fix soon for the next version.

Oh wow, so this is potentially real?  But would eventually fix itself?  Because I've seen it too, or think I did.  Sometimes it's hard to be sure it's not just user error.

Reply to Discussion


© 2020   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service