I've just released ArduPlane 2.69 [UPDATE: revised to version 2.70 after bug fix (see comments). This release includes a lot of internal changes, principally the AP_HAL changes, which is why it took so long. I've also been doing a lot of test flights to try to ensure that all these large changes haven't broken anything.

As has been discussed previously, the biggest change in this release is the move to the new AP_HAL hardware abstraction layer. This was a large internal change, that by itself didn't change the behaviour of ArduPlane, but did allow us to make ArduPlane much more portable. As a result, this is the first release of ArduPlane that works on the new PX4 autopilot board. Unfortunately the documentation on how to setup ArduPlane on PX4 is still lacking, so if you have a PX4 and want to run the 2.69 release then you will either have to dive into things a bit yourself to get it to work or wait a bit longer for the documentation updates. Sorry about that!

Of course we still support the APM1 and APM2 and I plan on keeping ArduPlane working on both those boards as long as possible. What I expect to happen is that some new features in future releases will only be enabled on the PX4, but for now ArduPlane on the PX4 works just the same as it does on the APM1 and APM2.

As you might expect from the fact that it has been over 2 months since the last ArduPlane release, there have also been quite a few changes not related to the AP_HAL and PX4 work. Many thanks to everyone who has contributed patches and ideas that made it into this release! I know not every requested feature made it in, but I thought it was better to get the new release out now.

Some of the key changes in this release are:

  • new flight mode 'TRAINING'
  • support for PX4 autopilot
  • CIRCLE mode now holds altitude
  • support for counter-clockwise loiter (thanks to Jochen)
  • support for the 1.9 firmware on MTK GPS
  • support for mounting the APM board in lots of different orientations
  • improved the MPU6000 accel/gyro filtering a bit more
  • secondary elevator support (thanks to Michael Warren)

One of the changes I am most pleased with is the addition of a new flight mode called TRAINING mode. This mode was developed in cooperation with a MAAA flight instructor, and is designed to help people to learn R/C manual flying. When you are in TRAINING mode you have manual control over roll until you reach the LIM_ROLL_CD roll limit, at which point the plane won't roll over any more. The same applies to pitch - you have manual pitch control until you reach LIM_PITCH_MIN or LIM_PITCH_MAX, at which point the plane won't pitch beyond those limits. This means that as long as you stay within the configured limits you are flying the plane manually, and you can quickly learn to fly an R/C plane manually, knowing that the APM will prevent the plane from going upside down. I'll do a separate blog post about how we are using TRAINING mode to teach new pilots good R/C manual piloting skills.

Another significant change in mode behaviour is that CIRCLE mode now holds altitude. This is important because CIRCLE is used in the first stage of failsafe conditions, and if your plane is badly trimmed it could lose quite a lot of altitude before the RTL stage of failsafe kicks in. Note that this doesn't mean that CIRCLE is now the same as LOITER - in a LOITER the plane will adjust its roll to keep going around the target position, whereas in CIRCLE the position of the plane isn't considered - it just holds a small roll angle, which results in a large circle that drifts with the wind. This is deliberate as we want CIRCLE to not be dependent on the GPS, and to involve no sharp turns.

The other change that is probably worth expanding on is the ability to mount the APM in many possible orientations. This has been an open request for a long time as for certain types of airframes it is very useful. Just set the AHRS_ORIENTATION parameter to one of the supported orientations and your APM will quite happily work upside down or sideways.

I'm expecting it won't be 2 months till the next release, as I have a bunch of other changes pending that I held off for this release (for example, the AP_Mission code from Brandon, and the new AP_Scheduler code), but meanwhile I'm very happy with how this release is flying, and I hope you all will be too!

Happy flying!

Views: 15768

Reply to This

Replies to This Discussion

Tuning ArduPlane roll and pitch controllers


That sounds like a much improved control system. Why is that not incorporated into standard APM firmware – or is it? I looked at loading V2.60 from the Mission Planner but none of the tuning parameters he talks about showed up??????

I am not a programmer so I have to ask if this firmware is available using the Mission Planner to load it. I am not into compiling and loading my own code.




I think we're pulling the thread a bit off-side, but...

To enable the Challinger controllers you need the following in APM_config.h:

     #define APM_CONTROL ENABLED    // This flag enables the new controllers for pitch and roll

When this is done, unused gains will be greyed out in Planner.

I'm flying the following gains on my Stinger UAV and upcoming Stinger HAB mission.  These were flown in HIL, checked out on the UAV, and autopilot state variables have been telemetered to see if the relative magnitudes of inner and outer loops look reasonable. They're pretty robust at AS operating points of 20-30 m/s on the Stinger.  I've also effectivey doubled and halved the gains by putting test multipliers on the AS scaling equations.  The Stinger airframe is SENSITIVE in roll and not so much in pitch.  I give the autopilot full rate control in roll, but only manually fly on low rate.  Pitch control is almost +/- 30 deg for the autopilot and manual.  No dual rate.  i.e. you need to think about how your plane flies WRT these comments and these gains to choose a starting point.  The proportions of PI&D and FF should be about right.


Larry D. Grater


Anyone managed to solve the logs download problem??

someone has the values ​​P, I, D NAV_ROLL_PID, the defaults do not work, waves are generated in the navigation and loiter. I'm flying a skywalker 1900.

It is my understanding that the only difference between 2.69 and 2.70 was that 2.69 had the incorrect telemetry values. I could not get 2.69 to work with TM but have been flying 2.70 with no problems.

Have you updated the PPM Encoder – maybe that’s the problem?




Hi Bharat

Thanks for info. I was able to run make px4 command successfully, but before that have to compile px4fmu manually from Firmware directory. Is this fine? Next Do I have to compile px4IO separately and upload it?

I also get this error and many other signs of problems. 

What should I do?

Has anyone had success in using the Do-Digicam-Control with Version 2.70?

Kurt, we're working on that right now. The documentation needs to be updated for sure, and there may be some other tweaks we need to add. Stay tuned. 


The APM's main processor uses PPM. One single signal with all the channels in it. If you use full PWM cabling, that does not get anywhere near where the main CPU will see it. Rather, it goes through the PPM encoder (an auxiliary CPU) and then as PPM to the main CPU. Therefore the encoder is relevant for you as an error source.

PS: I suggest not to use it is possible.



I will have my new airplane ready in a week or two. Is there any new firmware due out soon? I don’t want to spend time tuning if 2.71 will be available soon.


Andrew, you may or may not be aware, but the do_mount_configure and control commands do not work when inserted in the flight planner between waypoints. I can change the mount configure in the standrd parameters tab, but i get an unsupported command whentrying to write the waypoints with that command in line.

Theres a report of the problem here

Whats the chance of gettingbthis fixed?

Reply to Discussion


© 2020   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service