There has been a lot of development activity in ArduPlane lately, and 2.60 is shaping up to be a major release. I'll cover the main points below and I'd also like to get some feedback from ArduPlane users on some of the changes.

Wind Estimation

The AHRS library will now do wind estimation while flying. It does this in two ways. If an airspeed sensor is fitted and the plane is not turning, then it uses the simple method of

 wind = gps_velocity - airspeed_in_earth_frame

A low pass filter is applied to smooth the result. When the plane is turning or an airspeed sensor is not available, it instead uses Bill Premerlani's wind estimation algorithm, which was ported to ArduPlane by Jon Challinger. This uses the aerodynamic properties of an aeroplane to estimate wind by the effect on the planes attitude, combined with ground speed.

The resulting wind estimate is logged over MAVLink in a new 'WIND' message. The wind estimation code has been tested both in the simulator and in real planes and performs very well. It is in the master git repository now, ready for the next release.

Dead Reckoning

With a wind estimate available it became possible to do long term dead-reckoning. This now kicks in automatically when GPS lock is lost. Previously ArduPlane would stop attempting to navigate when it lost GPS lock, and it would also stop doing acceleration compensation. It now uses the wind estimate plus airspeed (if available) or the last GPS speed (if no airspeed available) to estimate the planes ground velocity vector. This allows it to keep navigating for quite a long time - it should be long enough to allow the plane to RTL from several kilometres away.

The dead reckoning has been tested a lot in the SITL simulator, plus has been test flown in 7 m/s winds by Jon Challinger, with great results. Jon's plane was able to loiter accurately with no GPS lock for a couple of minutes (and probably could do so for much longer).

Note that you need to have a compass enabled for dead-reckoning to work, as otherwise gyro drift will throw off the yaw. It will also work much better with airspeed than without.

The dead reckoning code is in git master ready for the next release.

Wheeled takeoff and landing

We now have support for steering a plane on takeoff/landing using a wheel coupled to the rudder. This allows you to perform auto takeoff and landing with wheeled planes.

To do a wheeled takeoff you need to setup the WHEELSTEER PID. I'd suggest you start with WHEELSTEER_P=1 and WHEELSTEER_I=0.3. Then test the steering by setting THR_MAX to a value small enough that the plane won't takeoff (eg. THR_MAX=15) and try an auto-takeoff. While it is rolling along the runway use stick mixing on the rudder to deliberately take the plane off course, and check that it comes back on course quickly but without oscillating.

New 'OBC' failsafe system

As part of the CanberraUAV teams entry in the Outback Challenge we've been developing a new failsafe system for ArduPlane that allows us to meet the OBC rules. The way it works is that you say what waypoint to change to for each failsafe condition. So you set FS_WP_GPS_LOSS to a waypoint number for when GPS lock is lost, and FS_WP_COMMS to a waypoint for when ground station heatbeats stop. You then setup a mission to do whatever you want at those waypoints. In our case we have waypoints setup to loiter for 30s on GPS lock loss, then fly to airfield home. If the GPS comes back, the plane will automatically resume its mission where it left off.

The new failsafe code is a compile time option, enabled by setting "#define OBC_FAILSAFE ENABLED" in APM_Config.h.

To support this new code there have also been fixes to some of the mission commands. For example, the LOITER_TIME now correctly takes the number of seconds to loiter, and you can ask the plane to "loiter in current location" by setting lat and lng to zero in a loiter.

New controllers

The other big change planned for 2.60 is the new roll/pitch/yaw controllers that Jon Challinger has developed. You can read about those on Jons blog. Those aren't integrated into master yet (mostly because I haven't test flown them myself yet). Jon has been flying them a lot in his E-Flite Apprentice with great results.

There have been lots of other smaller changes, but the above are the highlights. Please test out master if you get a chance and give some feedback before the release!

Cheers, Tridge

Views: 2872

Reply to This

Replies to This Discussion

Hi Eagle,

The dead reckoning code is in master, so you need to use git to fetch it. I'll do a zip file when we are closer to release. Meanwhile, check it out with git if you want to give it a try!

You can test dead reckoning by setting the parameter AHRS_GPS_USE to 0 while flying. It will continue to log GPS data in the GPS_RAW_INT MAVLink messages, but will log the dead reckoning position in GLOBAL_POSITION_INT. I have also updated the mavproxy map widget to display two planes when this happens - a blue plane for the true GPS position and a red plane for the dead-reckoning position. Set AHRS_GPS_USE back to 1 to start using the GPS again.

I don't have a way to do this from the transmitter yet, so you'll need to put it in a loiter then use the GCS to change the value.

Cheers, Tridge

Hi Eagle,

yes, using mission planner or a text editor. We use a python script to generate the waypoints we're using for our OBC entry. I've attached our current set of generated waypoints below. You can see comments in the waypoint file for the various failsafe waypoints.

Cheers, Tridge



Thanks a lot for the work and for keeping us in the loop! I'd also have a few questions that I may figure out myself looking at the code but since they are of general interest to APM 1 users I think they could be asked here:

- Chris mentioned something of taking away the CLI switch code. Personally, I'm a big fan of the switch and since it's there on the hardware I'm happy to use it. Can you confirm that it's still there just #iffdeffed out as previously also?

- The new features that are gonna consume lots of flash, are they also possible to #iffdeff out? (thinking of the APM 1280 here). I'm interested in the new controllers and possibly wind estimation but don't really need the other things IMHO. I suppose I could branch off the master but it would be nicer to stay closer to the code base.

Anyway.. thanks again,


Hi Andrew,

Thanks for your great job! Will be possible to compile this new version on the olds 1280 APMs?


What about RSSI and a second battery voltage readings? Any news? :)


Regards from Spain,





Hi Andre,

I'm afraid the CLI switch is going away, along with the dip switches. I'm sorry you are losing a feature you like like - it has been the cause of quite a few bug reports, and the "hit enter 3 times" works with all the APM boards, so it seems simpler to just adopt the one method.

I think it will be still possible to use a 1280 in 2.60, but only by choosing the features you need in APM_Config.h quite carefully. We do test that in the autotest system, and it will auto-select some features to make it fit. Look for __AVR_ATmega1280__ in config.h to see which ones it selects.

Cheers, Tridge

Thanks for the quick reply. Will follow your advice.

Cheers, Andre


I wonder whether anybody else has problems with this current code and 2 aileron servos (i.e., RC_5 aux is the second aileron servo)? That worked fine previously but now behaves very strangely. Essentially deflaction into one direction is OK, but the other side becomes extremely sensitive (essentially moving from neutral to complete deflection in an instant). This happens for example in FBWA. Strangely enough, the first few seconds after rebooting all is fine. Only say 30 seconds later this takes effect.

I noticed that there were quite a few changes in the RC_Channel library. Most notable, the ANGLE_MIN and ANGLE_MAX have disappeared. So my suspicion is currently that something broke in the process. Still trying to track this down, once I have a lead I'll post an issue I guess.

Cheers, Andre

It seems that in this case the RC_i_MIN values for i>4 are somehow set to 0 even though they are initially calibrated via CLI and the CLI shows values that look correct (so are corectly stored in EEPROM). I wonder if the AP_NESTEDGROUPINFO inside the aux channels has something to do with that (since function is initalized to zero, which could overwrite MIN), but that's just a guess so far.

Andre,  ANGLE_MIN and ANGLE_MAX are for camera mount only. They were moved to  Mount.cpp were they are used. For control surfaces I believe only the RC_Channel min/max apply. The problem must be elsewhere.


Any work on outputing RSSI info?

Just a few lines of code to send a value 0 to 255 on the "mavlink_msg_rc_channels_raw_send" message?

Right now it is fixed at 1.Some code like this would give the MiniOSD a way to display it.

       static AP_AnalogSource_Arduino RSSI_pin(8); //on amp1 is A7 pin closes to xbee pins.
       temprssi = RSSI_pin.read_average(); //need rssi to be 8 bit value so div by 4, highest value is 1024
       temprssi = temprssi - 4;
       if (temprssi < 0 ){
                 temprssi = 0;
        rssi = temprssi / 4; // by now rssi should be 0 to 255, on decode * by 4 for full value, lose 4 points

This code in the sensor.pde.

A new rssi value, and of course to comment out the rssi = 1 in the GCS_Mavlink.pde.

A lot of users could use it.

On the Miniosd side the voltages that the various RSSI outputs, could be set for high and low values and output a % on the screen.



Greg, thanks for the heads up. Yeah, I believe you are right. Currently I think the problem may lie somewhere with the nested EEPROM parameters. Added an issue now. Would be great if someone could reproduce the problem to make sure it's not due to my own changes. But I can't see how these could have an effect on this. Anyway.. thanks for your reply. The issue report is there.

Nice, very nice.

Reply to Discussion


© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service