I've just released ArduPlane 2.73 as a bug fix release for several important bugs in 2.72

The main reasons for this release are:

  • fixed a noise and scaling problem with airspeed sensors
  • fixed a potential flyaway problem with the L1 navigation controller
  • improved handling of poor GPS velocity for attitude correction

This release does not contain the new attitude controllers that I previously said would be in 2.73. Paul and I decided that it would be better to hold those over to the next release, and get this release out with just the above critical bug fixes.

The airspeed problem stemmed from a changed introduced in 2.72 to make ArduPlane automatically scale analog inputs with board voltage. That change was good for voltage and current sensing, but it added a lot of noise to airspeed sensing as the 3DR airspeed sensor is ratiometric (the sensor output scales with the supply voltage). The fix was to add support for ratiometric analog inputs. This release also fixes a bug in the airspeed ratio handling. To confirm the fix I have been driving around in my car with an APM2 and PX4 logging airspeed and GPS speed - that test confirmed the airspeed sensing is now accurate.

The flyaway bug in L1 was caused by an unusual situation where the previous waypoint was equal to the next waypoint, which can happen when a mission is interrupted and restarted. The L1 controller would then level the wings and fly straight ahead until the operator intervened. The bug fix was to make the L1 controller detect this situation and track directly to the next waypoint. I don't think many users would have seen this bug, but it definitely could happen and warranted a bug fix release.

The GPS handling bug was related to the MTK GPS, which can be very slow to report loss of GPS lock, which could lead to very poor attitude from DCM and even a crash if the plane tries to turn while the GPS is reporting incorrect velocity information. The fix was to watch the satellite count, and stop using the GPS velocity for accelerometer correction when it had less than 6 satellites. This is selectable with the new AHRS_GPS_MINSATS option.

Other changes

While this release doesn't have the new attitude controllers I decided to leave in some other smaller changes that have been made since the 2.72 release that I consider to be low risk, including:

  • fix the PX4 barometer driver to run at full rate
  • fixed handling of a saturated compass on PX4
  • added COMPASS_ORIENT option to support external compasses
  • fixed the compass in HIL simulation
  • added GCS messages to flash logs
  • allow 3D accel calibration over MAVLink
  • Added new ELEVON_OUTPUT option
  • removed MANUAL_LEVEL option (manual level is now always on)
  • improved pitch handling when inverted

Of these, perhaps the most useful is the ELEVON_OUTPUT option. That makes it possible to setup your transmitter with normal aileron/elevator and get the APM to do a software elevon mixer on output. That gives better control in FBWA mode than the previous elevon options.

I recommend that all users of 2.72 upgrade to 2.73. Happy flying!

Cheers, Tridge




Views: 28178

Reply to This

Replies to This Discussion

Hi Graham,

Sure i use AS sensor.

All i was takking about, have happened in the air.



I've also been curious with this since the new compass parameter came in... I have the APM mounted at yaw270 using Board Orientation (AHRS_ORIENTATION) but haven't touched the Compass orientation (COMPASS_ORIENT) as I'm using a APM 2.5 with compass on board... so I'm assuming you don't need to set both?! 

I've only been flying in stabilised mode so far... so am wondering if it is going to have trouble once it starts navigating itself?!

That's question I want to know, do I need to change orientation of onboard compass together with board, or is it orientation is for external compass relative to the board. But by now, it works great with compass disabled.

I mostly use Arducopter with an APM2.5, and I'll be soon using my old APM2.0 with a Funcub. There are several things very nice with Arducopter I didn't find in Arduplane like UserCode and UserVariables to implement some custom code, and COPTER_LEDS to have visual information, like GPS fix, flight mode, etc.

Do you plan any release with those elements ?


Hi...I've been trying to fly 2.73 (on an APM 2.5) using Hardware in the Loop with Flightgear.  Everything connects and starts up just fine.  Manual and stabilize also work well.  However, when I switch to auto mode I get a minute or two of stable flight before the reported pitch (in Mission Planner) suddenly starts to drift from actual (Flightgear).  This causes a pitch response on the plane which it really doesn't need.  Depending on which way the drift happens it either pitches up and stalls or nose dives.  At this point the reported attitude is usually spinning wildly and the plane cannot recover.

Has anyone seen behavior like this before?  Any thoughts are appreciated.  Thanks.

Hi Andrew.

Could you tell me what conditions needed to make motor work in auto mode or RTL mode.

In flight last Saturday use my own GCS, With a fixwing plane, at airspeed 10m/s, height 15-20m to ground, and The distance from plane to GCS is about 40m, I switch mode from stabilize to auto, then,the motor is shut down, and plane crashed.

Some one tell me if airspeed less than 3m/s, the motor will be shut down. Could you tell me more thing about auto/RTL mode? What conditions does APM/ArduPlane needed to make motor work in auto/RTL mode?

Yesterday, I  analysis mavlink message between APM/ArduPlane and GCS, and I found I lost Home point data to upload. perhaps this is one reason which make  motor shut down?

Sorry for my poor english, expect your help.


This is my own GCS developed by Visual C++, but it's telemetry data format not same with tlogs, I will try to make it compitable with tlogs in next.

I've got the same problem with 2.73.

My skywalker doesn't not hold altitude in any computer controlled mode.In RTL it goes full throttle and turns to home where it circles and slowly loses altitude.

How does APM control speed in RTL mode? Which parameter limits maximum throttle? I couldn't find information about this. Thanks in advance.

I notice that the default altitude in the WP screen of the flight planner window sometimes resets to 0 even though it displays 300. Unless I click read to reload WP data from apm I can't tell what it's actually set at. I'm still not entirely sure what causes this but it happens when apm powers down before disconnecting in MP and it also happens when reloading WP missions from a file sometimes, even if the original mission was set to 300ft. Either way, what happens is the plane turns toward home and starts decreasing in altitude. If its close enough to home it circles in a steady descent trying to reach 0alt.
In other auto modes I've experienced loss in altitude when the board is under powered or there isn't a solid 3d gps lock. I typically use a 10a ubec to power the entire board via output rail with jp1 in place or 10a ubec on output and apm power module powering the input side. I found that with a separate 3a ubec or the 3a esc power, if running 6 12g servos and the mediatek (ublox draws less power) gps, altitude loss was one of the resulting symptoms. Since ensuring proper power I have not experienced this problem in any arduplane version from 2.69 up. I did fly with the apm power module and esc power with mediatek gps the other day on a 4 servo plane and had no problems.


First do you have a tlog you can upload? I am assuming you are using an airspeed sensor right? Second you seem to be flying quite low and close to home are those numbers right (50-65ft ALT and 131 ft from home)? What altitude do you have your RTL set to?

In the current version of the Mission Planner you can set RTL to the default altitude as shown here by checking the box as shown.

If your ALT_HOLD_RTL parameter is set below your current altitude and your airspeed is below the target airspeed as defined in the parameter TRIM_ARSPD_CM (measured in centimeters) then your motor will go to the minumum setting defined in the parameter THR_MIN. It should also be noted that you must define the correct throttle position to achieve TRIM_ASPD_CM in the parameter TRIM_THROTTLE, expressed as a percentage of total stick volume. For example, if you desired cruise speed is 50Kph that is equal to 13.88 m/sec or 1388cm, and your TRIM_AIRSPEED_CM setting would be 1388. If you required 1/2 throttle to achieve this cruise speed you would set TRIM_THROTTLE to 50. Lastly THR_MIN and THR_MAX can be set from 0-100 to define the range of throttle the Autopilot may use. One more parameter you can tune is THR_SLEWRATE which can be set from 0-100 and tells the Autopilot what percentage of change may be applied to the current throttle setting over a period of one second. For example if you set THR_SLEWRATE to 30 the autopilot may apply no more than 30% increase or decrease in throttle over one second. So to go from 0% throttle to 100% would take just over 3 seconds (if THR_MIN and THR_MAX allow this range of throttle).

Hope this helps,


Nathaniel ~KD2DEY


I don't think this will help solve this issue, however for a better understanding of what parameters affect airspeed in RTL, see my response in this thread here.

If you can post a tlog of one of your flights with RTL engaged.


Nathaniel ~KD2DEY

Has anyone been able to get the new ELEVON_OUTPUT mode to work? I tried this by setting my transmitter to normal aileron/elevator output and when I move the sticks on the controller the surfaces move the correct direction but in autopilot mode the surfaces do not move the correct direction. I can't figure out why it is only half working like this.

Thanks Nathaniel, Your help is so important and useful to me.

Since my GCS is developed by myself, It's telemetry data don't compitable with tlogs now, but I will make it compitable with tlogs later.

In my failed flight last Saturday, The plane's height is about 15-20m, when I switch mode to AUTO. Now, I think it too low indeed. The altitude which I set for RTL is 60m, but I am not sure about it. since i didn't recognized the importance of this parameter before.

Your help and example is detailed enough, thanks again. I will make test flight again in this weekend. And I will pay more attention to those parameters which you mentioned.

Sorry for my poor english.



Reply to Discussion


© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service