ArduPlane 2.30 released!

The ArduPilot development team is delighted to announce the release of ArduPlane 2.30. This release replaces the current stable release (version 2.28) and is a recommended upgrade for all ArduPlane users.

DCM updates

The main focus of this release is increased stability in the AHRS system. Using simulations and flight logs the dev team found a number of ways to improve the DCM code at the core of ArduPlane to make it much more resistant to sensor noise and to improve its accuracy during tight turns. The most important result is the noise resistance, with simulations showing that the new AHRS code can resist noise levels several times higher than the previous code.

The new code also copes better with linear acceleration. Several ArduPlane users had noted the tendency of ArduPlane to pitch its nose down immediately after a hand launch. While there are several possible reasons why this can happen, one common one was that the linear acceleration of the launch was being interpreted by the attitude code as an upward pitch, which led to ArduPlane compensating incorrectly by pitching down the nose. The same thing would happen in any manoeuvre which involved significant linear acceleration. Simulations show that the new system produces much better pitch accuracy as a result.

The new DCM code is also a lot faster, which means we now have more CPU free for additional features in future releases.

EEPROM Config update

This release is the first to include the new 'AP_Param' configuration system, which replaces AP_Var for saving parameters to EEPROM. The new system uses a lot less memory than the old one (saving about 2.2k of RAM out of a total of 8k on the board). That extra memory will give us the opportunity to expand the feature set of ArduPlane in future releases.

The new system also makes it easier to expose some previously hidden internal parameters to users setting parameters via MAVLink. In particular, it is now possible to set the compass offsets over MAVLink, a feature which is discussed more below.

Compass setup

This release includes a lot more control on how the compass is used in flight. It is now possible to use the APM Mission Planner to find good compass offsets based on a telemetry flight log and then to lock in those offsets for future flights, disabling the automatic offset updating system by setting COMPASS_LEARN to 0. The planner will update the new COMPASS_OFS_X, COMPASS_OFS_Y and COMPASS_OFS_Z parameters to ones chosen based on optimising the offsets against a flight log.

By using the new COMPASS_USE parameter it is also possible to setup ArduPlane to log compass data while not using the compass for yaw control (instead using the GPS). This is useful for gathering good initial data for compass calibration. You can also use COMPASS_USE to enable/disable the use of the compass for heading correction while in a flight, which allows much easier testing of GPS vs compass based navigation.

Hold course on landing

The auto landing code has been updated to avoid a problem where the course hold in the final stages of the landing could produce a significant roll due to cross-track errors. The previous code locked the heading onto the cross-track heading, whereas the new code locks the heading onto the current heading in the final meters of the landing. The two headings are usually close, but in a cross wind there can be enough discrepancy for the old code to tip a wing into the runway.

Rudder in elevon mode

Thanks to a patch from Phil Cole, ArduPlane now supports use of a rudder on an elevon based plane. All the usual rudder controls are possible, which will allow elevon planes with rudders to improve their flight considerably.

Saving airspeed in mission

A minor change was made in the handling of airspeed/groundspeed changes during missions. Previously if you used a mission command to change the target airspeed then this would be saved to EEPROM and would be used for all flight modes, necessitating a reset of that parameter before the next flight if the changed airspeed target was only appropriate for that mission. The value is now only set in memory and not to EEPROM.

compass enable/disable in flight

It is now possible to disable the compass while in flight. Previously if you disabled the compass while flying the DCM code would continue to use the compass heading as a yaw reference, but that heading would not be updated, so navigation would be impossible. ArduPlane can now change to using the GPS. This is useful for longer flights if the operator suspects a problem with the compass.

logging of DCM and HWSTATUS

The MAVLink telemetry logs have been updated with additional messages giving a lot more information about the internal behaviour of the DCM AHRS system and the hardware. The DCM messages make it much easier to diagnose tricky problems such as gyro drift, while the HMSTATUS messages allow the operator to monitor I2C bus errors and the board voltage.

CLI on a 1280

The command line configuration and testing interface is now available again on older 1280 based APM1 boards. This had been previously disabled due to flash space issues but has been re-enabled due to space savings that resulted from the new AP_Param code. This means the only feature disabled by default on older 1280 based boards for this release is the on-board dataflash logging.

Thanks to all the contributors!

Many thanks to everyone who has contributed to this release! This release encompasses over 700 patches to our git repository from 25 developers. I hope everyone enjoys flying it as much as the dev team enjoyed developing it!

You need to be a member of diydrones to add comments!

Join diydrones

Email me when people reply –


  • Gábor Zoltán - how did you get both air & groundspeed ? and both barometric and GPS altitude ?

    I am using MinimOSD 1.9 firmware and miss those options

  • Hi Gabor ! I have see your video. It seems the similar problem. 

  • There seems a serous bug in Arduplane 2.33. 
    Please see the video;  
    See that I changed the mode to Stabilized, then flew the plane slightly away then switched the mode to Auto, and see the model crashed.  
    APM Dev. team, this is for your analysis. 
  • OLD: 

    MP connection stops every time after uploading with Arduino to the APM 2.0 board without errors and starting Mission Planner. When mission Planner connects to APM 2.0 board it stops halfway. Now it stops at: got param RC4_DZ

    It times out and can't connect. Get this error message:  Time out read - GET PARAMETER List 94-176

    I have the latest FTDI drivers and made sure the libraries are all there. I am pretty sure it's not the 2.30 code, as I similarly was not able upload with 2.28, but at least this time Mission Planner actually recognized the board and started loading off of it.  Again, if  upload with Mission Planner instead of Arduino, all works fine.


    Well...when APM 2 tries to connect to MP and gets stuck halfway, I press the hard reset button on the board and it completes the rest of the loading. However,  even it seems connected, nothing works.

    I tried to remove any other voltage cables except the USB, also tried it with the battery and USB at same time.

    The only thing I do not have set because it does not give me the option is the "set RTS close" under the USB port. I do not have that option under my USB port, may be it was the FTDI USB port option previously.

    It's frustrating that I am stuck with the stock code and can't modify. I tried it on another PC using Win XP, same problem with the Arduino environment.

  • My question is; Could the new version case my barometric pressure sensor go crazy?

    If it is not. What could? 


    I already posted it here:


  • That's great, the new compass calibration has resolve all my navigation problems, now my maja flies over to the teoric road.

  •  load the APM version 2.30 in my 2560, do one test flight and has the absolute heighterrors, sometimes it works well, sometimes not. seems that the navigation alsodeteriorated and the indication of the magnetic compass seems to be crazy. is mypreimera aprecicacion. attached file

    2012-03-18 04-35-33.tlog

  • This may not be related to this version of the code, but when I compile the 2.30 code (unchanged) in Arduino 022-relaxed and upload it to APM 2.0, it stops about halfway every time at this line:  got param RC3_Trim

    What may be the issue?

    Otherwise, if I let Mission Planner upload 2.30 it works every time.

  • Developer

    Release 2.30 has a great amount of brilliant investigative debug work and system wide enhancements with lots of flight testing!

    Maybe the best baseline release to date. With more community test flights and good feedback (with logs), and using various RC setups/aircraft, it will become very reliable, and less drones will fail from software issues. 

    DevTeam is taking a more methodical and consensus based approach to new enhancements, required bug fixes and public and test only releases. In an attempt to insure no unintentional simple typo errors or bugs are introduced by these fast and sometimes extensive code changes.

    All changes have some potential for minor bugs, so community test flights are required to complete the software verification cycle and allow for safest DIY drone operations in the NAS.

    Please contribute your ideas and  flight test logs so release 2.4 is our most safe and reliable ever! 

    Congratulations to whole community for your ideas and efforts ... Lets keep innovating the DIYDrone hobby to the next level.

    Congratulations to all..!

  • Do I start from scratch with my parameters, or can I just save them to disk & reload them after the firmware upgrade?

    In my case I'm using APM 1 w/2560.

This reply was deleted.


David Hori liked Isabella Domi's profile
Jan 12