Altitude jumps by TAKEOFF command height when repeating mission + RTL fly-aways

(Posting this here since there seems to be no Plane 3.9 forum yet)

I have been trying Arduplane in a small flying wing on the revo-mini, it’s pretty amazing that we can get this much functionality in a total weight of 180 grams! In general this little plane flew surprisingly well even in some decent wind and was very successful in all flight modes I tried, other than what I’m about to mention here :slight_smile:

Over my two days of trials I struck a couple of problems, one being that the altitude gets messed up after a mission, the other being fly-aways in RTL mode.

I’m running plane 3.9.0 (ChibiOS) and other than some basic changes necessary to set up a flying wing config, and my desired loiter radius and height etc, I have only changed these parameters:


(In hindsight these changes were probably not necessary, I was originally trying the night_ghost build for revo-mini which had a problem with EK2 and these fixed… I mean side- stepped it). You can see other details of my setup here:

The most common problem was that after successfully completing a mission containing a TAKEOFF command and a LAND command, subsequently switching into auto mode would sometimes cause the altitude to jump by the altitude setting of the TAKEOFF command. Due to this the plane would think it was higher than it really was, and fly too low. In some cases it seemed to think it was already flying when actually still on the ground, so that switching into auto mode even with throttle at zero would spin the prop.

A closely related symptom was that switching into auto mode would also set the ‘Dist to WP’ value to 65535, or if it was already 65535 then switching into auto mode would set it back to something sensible.

On one occasion both altitude and wp_dist became invalid at the same time, with no stick or switch input at all, about 20 seconds after a successful landing. This one might be related to having the throttle raised during the entire landing and kept raised afterward.

I never saw these symptoms until after at least one mission had been completed, and they did not occur at all after I removed the TAKEOFF command from the mission (keeping the LAND) command. I suspect there might be either some state/flag not being cleared correctly when resetting a mission, or an invalid index for the command list is being used somewhere. I have not looked at the code at all, that’s just a programmer’s guess/intuition… I did not test what happens if the mission contains a TAKEOFF command but not a LAND command.

Unlike the altitude issue which was iirc was 100% reproducible, the flyaways did not happen so consistently (only 3 times over two days) so any pattern they might follow was harder to pin down. Two of them happened when the plane was facing almost directly away from the home point and it just kept going in the worst possible direction, but the third did not… Two of them happened when the altitude and wp_dist was messed up as mentioned above, but the third did not. In all cases the GPS fix appeared to be healthy, at least judging by satellite count and hdop. Although I saw no flyaways after removing the TAKEOFF command, I did see one before ever putting AUTO mode on a switch to do missions, so I don’t think the flyaway issue is related to the altitude/wp_dist issue.

In one case the vehicle location had been jumping around a bit (40 meters or so in the vicinity of the actual location) on the map as it sometimes does when first getting a fix, but the satellite count (17) and hdop (0.7) looked fine. This could perhaps be a bad GPS module…?

This video shows one example each of the above issues, see the video description for annotated event times:

One other strange thing I noticed that’s not really a major issue, is that a couple of times when switching into RTL when facing away from the home point, the plane would turn to the left when I was kinda expecting it would turn to the right. It would then do almost a full 360 degree left turn until facing away from the home point again, and then join the RTL loiter circle turning right (clockwise on map view). In both cases the plane was quite close to home when entering RTL mode, so I’m guessing the standard behavior is to always simply turn toward the home point when entering RTL mode. It just seems a bit unnatural, I’m sure that when very close to home like this a human pilot would turn to the right to begin with to join onto the RTL circle quicker and make the overall distance travelled shorter.

Finally, I wanted to try flying with the compass disabled, but even after 20 minutes it would not let me arm, saying AHRS and GPS differ by too much, so I gave up on that. Isn’t plane supposed to work without a compass?

Let me know if there are some other things it would be useful to test. Since I live right where I’m doing this testing I don’t really want to post the logs publicly, send me a mail at if you’d like to see them.

Thanks Chris,
great videos/channel by the way - I think they’ll be of great benefit for a lot of users.
@tridge @MagicRuB some good feedback here.

Specifically regarding the final point, with compass disabled, the heading comes from the gps velocity vectors. I’m guessing it couldn’t get a solution on the ground (ie too much noise in the gps vector). There should be a way around this but it escapes me right now.

email sent. Lets get this figured out!

I have flown without compass several times. Works remarkably well.