There are a lot of changes in this release, the main focus was on performance improvements! 

Some of the highlights are:

• new APM_Control attitude controllers.
• new TECS speed/height controller from Paul Riseborough.
• two new flight modes, ACRO and CRUISE
• new camera trigger by distance system, for better aerial mapping
• dozens of small fixes and improvements from two months of development
• lots more documentation, including tuning guides for all the new parameters

New Attitude Controllers

The new "APM_Control" attitude controllers have been in development for a long time. Originally developed by Jon Challinger last year, they were extended by Paul Riseborough and made compatible with the existing parameter names. The key advantage of these new controllers is their improved handling of noise, and much better ability to tune for your aircraft. There is a new tuning guide in the wiki which gives detailed instructions on how to make the most of the new capabilities.

One of the big effects you will see with the new attitude controllers is better handling of pitch compensation in turns. The new PTCH2SRV_RLL parameter makes tuning for flat turns much easier, which has been a major source of frustration in the past.

The new controllers also handle sensor noise much better, especially if you use any D term in your roll or pitch controllers.

New Speed/Height Controller

The new TECS speed/height controller is the second major controller change in this release, and will make a world of difference for aircraft with an airspeed sensor. After a lot of testing I decided to make TECS the default in this release, although you can switch back to the old controllers using the ALT_CTRL_ALG parameter if need be. If for some reason you find you do need these old controllers then please let me know, as I am planning on removing the old controllers in the next release.

The previous airspeed controller for speed/height suffered from a major problem that it gave absolute priority to airspeed. If the aircraft could not achieve the target airspeed you had set then it would dive to gain speed, even to the point of diving into the ground. This made it quite fragile, and you had to be very sure of your airspeed configuration.

The new controller operates over a range of airspeed values, set using the ARSPD_FBW_MIN and ARSPD_FBW_MAXparameters. That controller will try to meet both the airspeed and altitude demands of the mission, but if it can't reach the target speed it will happily fly a bit slower, as long as it doesn't get below ARSPD_FBW_MIN. You can control the relative priorities of speed versus height using the TECS_SPDWEIGHT parameter. See the full tuning guide for details.

New ACRO flight mode

After a suggestion from Thomas in the 2.73 release thread, we have added a new ACRO flight mode.

This modes brings rate controlled stabilization to APM:Plane, and should help give you an "on rails" manual flight experience. It is a lot of fun to fly, but it is not for beginners!

We're planning on expanding the ACRO mode in future releases. Right now it is great for "locked in" flying, and also good for loops and handles inverted flight very nicely. It doesn't yet handle knife-edge or prop-hanging.

New CRUISE flight mode

After a suggestion from Hein, we now have a new CRUISE flight mode. This mode is ideal for longer distance flying without a pre-programmed mission. It is like FBWB, but also does ground track heading hold, with heading update via aileron or rudder.

I've been testing CRUISE at my local flying field, and it is the easiest mode to fly in APM. Just steer the plane around the sky, and when you stop steering it locks onto a ground track and holds it. It isn't a good mode for takeoff and landing, but once you are in the air it is great.

New camera trigger system

When using APM for aerial mapping where you want photos taken at regular distances, the previous system was to setup a grid mission with a "camera trigger" mission item at regular intervals within the mission. That worked, but led to overly large and complex missions. You can now just set a single parameter CAM_TRIGG_DIST to the number of meters of flight between photos, and the APM will take care of when to trigger the camera. This makes for much simpler missions, and also works in other flight modes, including FBWB and CRUISE.

More details can be found here

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!

New version of arduplane has been released!

The big news in this release is the addition of the new L1 navigation controller. The work on the L1 controller library was started by Brandon Jones, and his initial github pull request is a great please to look to understand the new code. As is so often the case with ArduPlane, the documentation still hasn't caught up with the code (though I hope it soon will!)

From DIYdrones

After Brandon’s initial work Paul Riseborough did a lot of work to add more robustness to the algorithm. The base L1 algorithm suffered from from instability in "path capture", which is how it handles navigation when you are a long way off course (for example, when you enter auto after having flown manually). Paul made some fantastic improvements which have been extensively flight tested by Brandon, Paul, Jon and myself.

I did a final test flight of it this morning in a Bixler2, and it flew very nicely. I found a setting of NAVL1_PERIOD=20 suited the Bixler2 very well. It produced great path tracking, and very nice circles in loiter, despite high wind.

Paul is not finished yet though! He's been working on re-working the APM_Control library started by Jon Challinger, and is getting fantastic results with roll and pitch control, greatly reducing the altitude loss in turns. That isn't in the 2.72 release though as I want to do a bit more testing and tweaking of the code, but I expect to get Paul’s new controllers in the next release.

Before I go into detail on how to tune the new L1 controller, I better list some of the other changes in this release:

• avoid doing auto radio trim if the resulting trim leaves less than 20% of travel between the trim value and the MAX and MIN for the aileron, elevator or rudder. This prevents auto-trim leaving you with very bad trim if you do it while your transmitter is off
• removed HIL_MODE_ATTITUDE, we always now use SENSORS HIL, which is much more accurate, and is needed for correct operation of the L1 controller
• added new LEVEL_ROLL_LIMIT parameter. This replaces both the TKOFF_HEAD_HOLD and RUDDER_STEER options, and instead allows you to specify a roll limit in degrees for auto land and takeoff. The default is 5 degrees, which should be small enough to prevent wings scraping on the runway in most planes.
• Removed the AHRS_BARO_USE option, as it caused trouble for too many users
• allow the WP_LOITER_RAD loiter radius to be set negative to mean that a counter clockwise loiter should be performed by default
• fixed the handling of the LOITER_TURNS and LOITER_TIME commands
• added new dataflash logging system, with self-describing logging format. See notes below for more info.
• on auto-takeoff, if we have an airspeed sensor then keep throttle suppressed until we have both 5m/s ground speed and 5m/s airspeed
• added support for 12 output PWM channels on PX4
• enable relay in camera library for all APM boards (thanks to SSzilard)
• cleanup use of const in libraries (thanks to Tobias)
• lowered default AHRS roll-pitch correction gains from 0.4 to 0.3
• changed AHRS to lower roll-pitch gains by another 50% when a high X acceleration is detected for a catapult launch, to prevent nose down on fast launch due to GPS velocity lag
• fixed RC throttle failsafe handling on PX4
• fixed a bug in returning airspeed estimate from DCM if an airspeed sensor is available (thanks to Jon Challinger for finding this important bug)

As you can see, the dev team has been busy!

A few special notes about the DataFlash logging changes. This is the first release to support 'dataflash' logging on the PX4, and it implements it by writing binary log files to the SD card in an APM/logs sub-directory. Those log files are self-describing, which means the format of the logs is contained in the headers of the log. This makes it possible to add new log messages without having to change MissionPlanner. It also means you can now get logs into MissionPlanner by pulling the SD card out of the PX4 and plugging them into your PC, which is much faster than using the CLI. The new log format is also used for APM1 and APM2, which will mean we no longer have to align the version of MissionPlanner with the ArduPlane log version when analyzing dataflash logs.

Now on to the main thing in this release - the new L1 navigation controller.

The new controller makes a huge difference to navigation in ArduPlane in the following ways:

• tuning is now much simpler - the only navigation parameter you really have to change is NAVL1_PERIOD
• much better path tracking, even in high wind
• loiter now produces a very nice circle even in high wind
• much less servo flapping! If you tried to tune the old controller for very good path tracking it would end up changing servo position very rapidly, wearing out the servos and drawing more current than it should. The new controller has much smoother servo movement.

The default NAVL1_PERIOD is 25, which should give quite gentle navigation on most airframes. A smaller number means more aggressive navigation (tighter turns). Adjust it by around 5 at a time until you are happy with the performance. Most small RC planes will need a value of between 15 and 20. I need a value of 15 on my Phoenix Tiger60 low wing nitro sports plane, and 20 for my Bixler2. The default is 25 to ensure that we get gentle navigation by default - if the value is too small the plane can snake rapidly, and roll too rapidly, possibly leading to a stall if the aircraft is heavily loaded.

I hope you all enjoy flying this release as much as I do. Happy flying!

We're delighted to announce the new APM 2.5+, which is the same APM 2.5 board you know and love but surrounded by lots of new goodness!  Now, for a new lower price!  It comes with all this, right out of the box:

• The new APM 2.5+ enclosure, available in both top pin (above) and side pin (right) styles. It's designed to keep your electronics safe while looking great at the same time! The enclosure is made of black translucent ABS plastic so you can see the board's LEDs. It protects your electronics while allowing access to all pins and connectors. The inside of the enclosure is lined with ESD safe open cell foam to ensure the barometric pressure sensor is surrounded by static air and prevent unwanted readings due to airflow over the sensor. And the screws that secure the enclosure have been moved to the top for ease of use. It's also available as a stand-alone product.
• The new APM Power Module, available with either XT60 (shown) or Deans connectors. It's a simple way of providing your APM 2.5 with clean power from a LiPo battery as well as monitoring current consumption and battery voltage measurements, all through a 6-pos cable that plugs in neatly. The board is also shrink-wrapped to protect it (the bare board is shown here so you can see the innards). Been wondering what that "mystery connector" was on APM 2.5? Now you know! This will ensure that you have no brown-outs due to insufficient BEC power from your ESCs, and makes current and voltage monitoring easy!
• Our new Version 2 of the Mediatek GPS module. This takes all the learning we've had with the Mediatek over the past two years and wraps it up in one vastly improved product. New big ground plane antenna to improve reception! On-board battery for fast lock! New firmware for better performance and datalogging! Also available as a stand-alone product for $37.95.

ArduPlane 2.61 is now released, which has a lot of small bug fixes from 2.60.

Changes since the 2.60 release include:

• fixed wheeled takeoff to work with the APM_CONTROL controllers
• support setting the plane into MANUAL or FBWA via MAVLink
• added XTRK_USE_WIND parameter. When set to true (which is the default) the wind estimate from AHRS is used in the navigation code to help with navigation crosstrack
• added support for using the airspeed estimate from wind + groundspeed when no airspeed sensor is installed to do surface speed scaling
• added reporting of estimated airspeed over MAVLink if a real airspeed sensor is not available
• fixed a bug with the throttle suppression code that prevents takeoff in auto when near home. The suppression code could get a false positive if a large gust of wind hit. We now no longer use airspeed for throttle suppression decisions
• removed the reset_I() calls and instead auto-reset integrators in the PID library if the PID has not be used for 1 second
• fixed a bug with DO_JUMP mission elements introduced in the last release
• added ALT_CTRL_ALG option. When enabled, this allows you to select the non-airspeed altitude control code with airspeed enabled. This makes it possible to use airspeed for speed scaling and wind estimation, but use the non-airspeed control for throttle and pitch
• improvements to the APM_OBC failsafe module
• added new TELEM_DELAY option to delay telemetry on startup to prevent Xbee bricking
• fix for HIL simulation in ATTITUDE mode
• changed FBWA to obey both lower and upper pitch limits
• added magnetometer accumulation in main loop. This gives us much better mag averaging, reducing compass noise a lot
• added XTRK_MIN_DIST option, allowing a minimum waypoint distance for crosstrack navigation.
• added support for the DO_SET_SERVO MAVLink command
• added RUDDER_STEER option. When enabled, only rudder will be used for steering on takeoff and landing
• fixed mount control code to allow multiple channels to be set to the same function. In particular this fixes having multiple manual output channels.
• fixed throttle nudging to not depend on the RC3_TRIM value
• added THROTTLE_NUDGE option for enabling/disabling throttle nuding

The main new features in this release are:

• wind estimation
• long term dead reckoning support
• wheeled takeoff and landing support
• optional new roll/pitch/yaw controllers from Jon Challinger

For a description of the first 3 new features have a look at the previous post. All of these features have been test flown on my PulseXT 40 and have performed very well.

The new roll/pitch/yaw controllers from Jon can be enabled by building with

 #define APM_CONTROL ENABLED

in your APM_Config.h. If you enable the new controllers then I strongly suggest you read Jons blog post about the new controllers and how to tune them. These controllers are still experimental, but if we get good feedback on them from users we will quite likely adopt them as the standard controllers in a future release.

Other changes in 2.60 include:

• a new RECEIVER_RSSI_PIN compile time option, to allow you to display receiver RSSI via MAVLink. This should be useful for FPV flying.
• an important fix from Jason Short for an erase bug in the dataflash. If you use dataflash logs then please erase them after loading this release to ensure the pages are properly initialised.
• support for the new features in the new MTK GPS firmware
• updates to the configuration parameters for the Mount code. If you use the mount code, then please check your parameters carefully, as some things have changed.
• a fix to the JUMP command in missions, which solved a problem where the wrong command could sometimes be run
• a fix to the initial yaw from AHRS when using a compass
• new FENCE_ACTION_REPORT value for FENCE_ACTION
• new "OBC" failsafe code as a compile time option
• new RST_MISSION_CH option
• new STICK_MIXING option
• support for dual stabilisation mounts (eg. one camera and one antenna)
• removed old CLI switch and dip switch support
• fixed a derivative filter bug that could have a small affect on AHRS attitude
• fixed LOITER_TIME to match MAVLink spec (time is in seconds)
• added FBWB_ELEV_REV option

Happy flying!

This release has a lot of advances to some of the core ArduPlane code, and should be a big improvement for many people.

Perhaps the most important change in this release is the new DCM code that does acceleration correction based on the GPS. This improvement is based on work by Bill Premerlani which really advances the state of the art for attitude estimation on small microcontroller based autopilots. The improvement in attitude estimation is very noticable in flight, resulting in significantly more accurate control. Many thanks to Bill for his patience in working with Jon Challinger and myself to bring this improvement to ArduPlane.


Other significant improvements include:

• updates to the barometer driver to sample the pressure and temperature much more rapidly, leading to better altitude estimation
• updates to the AP_AnalogSource driver to be interrupt driven, allowing us to sample all analog sources much more rapidly. For ArduPlane this improves the airspeed sensor on the APM2 a lot.
• updates to the waypoint completion logic, to use a "finish line" algorithm. This prevents the problem of circling around a waypoint when we miss it by more than the waypoint radius. The waypoint is now considered complete when we pass a line that is perpendicular to the track, and passing through the target waypoint.
• improvements to the AP_Mount code, allowing for control of roll/pitch/yaw stabilisation via EEPROM variables that can be set over MAVLink. This allows you to setup the mount once, and it will resume operation as soon as you boot. These changes also fix a number of bugs in the AP_Mount code, so it AP_Mount hasn't worked for you, please try again. Many thanks to Greg Fletcher and Amilcar Lucus for the AP_Mount improvements.
• Lots of improvements to the ArduPlane parameter documentation.  This documentation should be the first place you look when trying to understand ArduPlane configuration parameters. Many thanks to Andreas Antonopoulos for his great work on generating these wiki docs based on the source code markup.
• New LAND_PITCH_CD parameter to control the landing pitch when not under airspeed control. Thanks to Jeff Taylor for fixing this!
• New SCALING_SPEED parameter that allows you to set the base speed for scaling PIDs. Previously we assumed a standard speed of 15 m/s, which is too low for fast aircraft. By adjusting SCALING_SPEED you can have the same set of PIDs for both airspeed and non-airspeed flight control.

There is one change in this release which may require some re-tuning. We were using the wrong value for time delta when using the PID controller for navigation roll. This has been fixed by making the PID library calculate the delta time internally, but it means that existing HDG2RLL_I and HDG2RLL_D values  will be incorrect. I have fixed the defaults, but if you have your own settings for these, you will need to drop HDG2RLL_I by a factor of 5, and raise HDG2RLL_D by a factor of 5 to get the same result as for the previous release.

Thanks to everyone who has contributed to this release!

For the next release the plan is to concentrate on improved stabilisation and navigation controllers, based on the great work being done by Jon Challinger.

Happy flying!

ArduPlane 2.40 has now been released. Many thanks to everyone who gave flight test feedback on the beta release!

Note that ArduPlane now uses MAVLink 1.0, so you'll need to update your Mission Planner to the newer version, which supports that. You'll find it in the same directory as your current Mission Planner, in a file called ArduPilotMegaPlanner10.exe


For a list of feature changes

• switch to MAVLink 1.0 for telemetry. This has been pending for quite some time, and it is nice to finally get it done. The reason it took so long is we needed some coordination between the various bits of code that deal with MAVLink in APM (the ground stations, autotest, ArduPlane itself etc). The various pieces finally came together and we can now support MAVLink 1.0 properly. This doesn't change the features of APM significantly, but it does prepare us for telemetry improvements in the future. 

• auto-configuration of UBlox GPSes. It should now be possible to attach a UBlox GPS in just about any state and the APM GPS code will re-configure it appropriately. The configuration isn't saved, so if you power cycle the GPS it will revert to what was set before, but it should now be possible for the APM to use a UBlox in factory default config. It's still a good idea to setup your UBlox correctly (38400 baud in UBX binary mode) as that will make the detection faster on startup, but it should work regardless.
• updated Camera and Mount control code from Amilcar Lucus and Greg Fletcher. These are not enabled by default, and I have not tested them myself, so I'm hoping Amilcar and Greg will be able to answer any questions that come up. Many thanks to Amilcar and Greg for all their work on this!
• sped up eeprom erase using chip erase
• Added ARSPD_USE parameter. This is useful when first setting up an airspeed sensor. The existing ARSPD_ENABLE parameter only allowed you to enable/disable airspeed and if enabled then it would be used for flight control. With ARSPD_USE you can now enable the airspeed sensor but not ask APM to use it for flight control (by setting ARSPD_ENABLE to 1 and ARSPD_USE to 0). That allows you to log your airspeed data without using it for flight control, which means you can validate the airspeed sensor is working correctly without risking your airframe if it is badly calibrated.
• fixed an ELEVON_REVERSE bug. The ELEVON_REVERSE parameter was being applied to only one channel, whereas it should be applied to both channels. If you use elevons then please be careful to carefully test your setup before your next flight!

Happy flying!

This release includes one very important update for APM2 users, and a few other minor updates.

The main reason for the release is to fix a bug in the scaling of the MPU6000 accelerometers. We discovered that the MPU6000 on the most recently shipped APM2 boards had different accelerometer scaling than earlier boards. This resulted in bad attitude calculations which would get worse during flight (as the DCM code interpreted the conflicting information between the gyroscope and accelerometers as gyro drift). We now query the product ID of the MPU6000 on startup, and fix the scaling according to whether it is a RevC or RevD version of the chip.

If you use an APM2 with ArduPlane then it is strongly recommended that you update to the 2.34 release.
Other less critical changes in this release include:

• fixes for building ArduPlane with the MAVLink 1.0 protocol (we currently use the 0.9 protocol). In a future release this will be the default once all other components are ready
• expose a new parameter AHRS_YAW_P to control how fast the compass controls the heading. The default is 0.2, which should be good for most users (this was mostly added for ArduCopter users)
• fixed the reporting of the raw servo output value in the MAVLink logs. Previously if you uses a mission element to set a servo value (for example, for a bottle drop) the log would not reflect the servo change. The logged value is now obtained directly from the servo library so will always be accurate
• changed the default I terms for navigation roll and pitch to 0.1. It is very common to need a small I value for navigation, so a 0.1 default is better than 0
• make it possible to use UART2 for Telemetry. The APM2 has a otherwise unused UART2 port, which you can connect to the telemetry connector via a solder bridge. This adds a TELEMETRY_UART2 build option to configure the code to use this port. This is mostly useful if you have an onboard computer connecting to the APM2 via USB at the same time as you connect a radio to the telemetry port, and you want both telemetry streams active

Happy flying!