I have finally written up an article on our successful Outback Challenge 2016 entry

The members of CanberraUAV are home from the Outback Challenge and life is starting to return to normal after an extremely hectic (and fun!) time preparing our aircraft for this years challenge. It is time to write up our usual debrief acticle to give those of you who weren't able to be there some idea of what happened.

For reference here are the articles from the 2012 and 2014 challenges:

http://diydrones.com/profiles/blogs/canberrauav-outback-challenge-2012-debrief
http://diydrones.com/profiles/blogs/canberrauav-outback-challenge-2014-debrief

Medical Express

The Outback Challenge is held every two years in Queensland, Australia. As the challenge was completed by multiple teams in 2014 the organisers needed to come up with a new challenge. The new challenge for 2016 was called "Medical Express" and the challenge was to retrieve a blood sample from Joe at a remote landing site.

outback-joe.jpg762x562 217 KB

The back-story is that poor Outback Joe is trapped behind flood waters on his remote property in Queensland. Unfortunately he is ill, and doctors at a nearby hospital need a blood sample to diagnose his illness. A UAV is called in to fly a 23km path to a place where Joe is waiting. We only know Joes approximate position (within 100 meters) so
first off the UAV needs to find Joe using an on-board camera. After finding Joe the aircraft needs to find a good landing site in an area littered with obstacles. The landing site needs to be more than 30 meters from Joe (to meet CASA safety requirements) but less than 80 meters (so Joe doesn't have to walk too far).

The aircraft then needs to perform an automatic landing, and then wait for Joe to load the blood sample into an easily accessible carrier. Joe then presses a button to indicate he is done loading the blood sample. The aircraft needs to wait for one minute for Joe to get clear, and then perform an automatic takeoff and flight back to the home location to deliver the blood sample to waiting hospital staff.

That story hides a lot of very challenging detail. For example, the UAV must maintain continuous telemetry contact with the operators back at the base. That needs to be done despite not knowing exactly where the landing site will be until the day before the challenge starts.

Also, the landing area has trees around it and no landing strip, so a normal fixed wing landing and takeoff is very problematic. The organisers wanted teams to come up with a VTOL solution and in this
they were very successful, kickstarting a huge effort to develop the VTOL capabilities of multiple open source autopilot systems.

The organisers also had provided a strict flight path that the teams have to follow to reach the search area where Joe is located. The winding path over the rural terrain of Dalby is strictly enforced, with any aircraft breaching the geofence required to immediately and automatically terminate by crashing into the ground.

The organisers also gave quite a wide range of flight distance and weather conditions that the teams had to be able to cope with. The distance to the search area could be up to 30km, meaning a round trip distance of 60km without taking into account all the time spent above the search area trying to find Joe. The teams had to be able to fly in up to 25 knots average wind on the ground, which could mean well over 30 knots in the air.

The mission also needed to be completed in one hour, including the time for spent loading the blood sample and circling above Joe.

The ArduPilot development team is proud to announce the release of version 3.7.0 of APM:Plane. This is a major update so please read the notes carefully.

The biggest changes in this release are:

• more reliable recovery from inverted flight
• automatic IC engine support
• Q_ASSIST_ANGLE for stall recovery on quadplanes
• Pixhawk2 IMU heater support
• PH2SLIM support
• AP_Module support
• Parrot Disco support
• major VRBrain support merge
• much faster boot time on Pixhawk

I'll give a bit of detail on each of these changes before giving the more detailed list of changes.

More reliable recovery from inverted flight

Marc Merlin discovered that on some types of gliders that ArduPilot would not reliably recover from inverted flight. The problem turned out to be the use of the elevator at high bank angles preventing the ailerons from fully recovering attitude. The fix in this release prevent excessive elevator use when the aircraft is beyond LIM_ROLL_CD. This should help a lot for people using ArduPilot as a recovery system for manual FPV flight.

Automatic IC engine support

ArduPilot has supported internal combustion engines for a long time, but until now the pilot has had to control the ignition and starter manually using transmitter pass throughs. A new "ICE" module in ArduPilot now allows for fully automatic internal combustion engine support.

Coupled with an RPM sensor you can setup your aircraft to automatically control the ignition and starter motor, allowing for one touch start of the motor on the ground and automatic restart of the motor in flight if needed.

The IC engine support is also integrated into the quadplane code, allowing for automatic engine start at a specified altitude above the ground. This is useful for tractor engine quadplanes where the propeller could strike the ground on takeoff. The engine can also be automatically stopped in the final stage of a quadplane landing.

Q_ASSIST_ANGLE for stall recovery

Another new quadplane feature is automatic recovery from fixed wing stall. Previously the VTOL motors would only provide assistance in fixed wing modes when the aircraft airspeed dropped below Q_ASSIST_SPEED. Some stalls can occur with higher airspeed however, and this can result in the aircraft losing attitude control without triggering a Q_ASSIST_SPEED recovery. A new parameter Q_ASSIST_ANGLE allows for automatic assistance when attitude control is lost, triggering when the attitude goes outside the defined roll and pitch limits and is more than Q_ASSIST_ANGLE degrees from the desired attitude. Many thanks to Iskess for the suggestion and good discussion around this feature.

Pixhawk2 heated IMU support

This release adds support for the IMU heater in the upcoming Pixhawk2, allowing for more stable IMU temperatures. The Pixhawk2 is automatically detected and the heater enabled at boot, with the target IMU temperature controllable via BRD_IMU_TARGTEMP.

Using an IMU heater should improve IMU stability in environments with significant temperature changes.

PH2SLIM Support

This release adds support for the PH2SLIM variant of the Pixhawk2, which is a Pixhawk2 cube without the isolated sensor top board. This makes for a very compact autopilot for small aircraft. To enable PH2SLIM support set the BRD_TYPE parameter to 6 using a GCS connected on USB.

AP_Module Support

This is the first release of ArduPilot with loadable module support for Linux based boards. The AP_Module system allows for externally compiled modules to access sensor data from ArduPilot controlled sensors. The initial AP_Module support is aimed at vendors integrating high-rate digital image stabilisation using IMU data, but it is expected this will be expanded to other use cases in future releases.

Parrot Disco Support

This release adds support for the Parrot C.H.U.C.K autopilot in the new Disco airframe. The Disco is a very lightweight flying wing with a nicely integrated Linux based autopilot. The Disco flies very nicely with ArduPilot, bringing the full set of mission capabilities of ArduPilot to this airframe.

Major VRBrain Support Update

This release includes a major merge of support for the VRBrain family of autopilots. Many thanks to the great work by Luke Mike in putting together this merge!

Much Faster Boot Time

Boot times on Pixhawk are now much faster due to a restructuring of the driver startup code, with slow starting drivers not started unless they are enabled with the appropriate parameters. The restructuring also allows for support of a wide variety of board types, including the PH2SLIM above.

This release includes many other updates right across the flight stack, including several new features. Some of the changes include:

• improved quadplane auto-landing
• limit roll and pitch by Q_ANGLE_MAX in Q modes
• improved ADSB avoidance and MAVLink streaming
• smoother throttle control on fixed-wing to VTOL transition
• removed "demo servos" movement on boot
• fixed a problem with spurious throttle output during boot (thanks
• to Marco for finding this)
• support MAVLink SET_ATTITUDE_TARGET message
• log all rally points on startup
• fixed use of stick mixing for rudder with STICK_MIXING=0
• fixed incorrect tuning warnings when vtol not active
• support MAVLink based external GPS device
• support LED_CONTROL MAVLink message
• prevent baro update while disarmed for large height change
• support PLAY_TUNE MAVLink message
• added AP_Button support for remote button input reporting
• support Ping2020 ADSB transceiver
• fixed disarm by rudder in quadplanes
• support 16 channel SERVO_OUTPUT_RAW in MAVLink2
• added automatic internal combustion engine support
• support DO_ENGINE_CONTROL MAVLink message
• added ground throttle suppression for quadplanes
• added MAVLink reporting of logging subsystem health
• prevent motor startup on reboot in quadplanes
• added quadplane support for Advanced Failsafe
• added support for a 2nd throttle channel
• fixed bug in crash detection during auto-land flare
• lowered is_flying groundspeed threshold to 1.5m/s
• added support for new FrSky telemetry protocol varient
• added support for fence auto-enable on takeoff in quadplanes
• added Q_ASSIST_ANGLE for using quadplane to catch stalls in fixed wing flight
• added BRD_SAFETY_MASK to allow for channel movement for selected channels with safety on
• numerous improvements to multicopter stability control for quadplanes
• support X-Plane10 as SITL backend
• lots of HAL_Linux improvements to bus and thread handling
• fixed problem with elevator use at high roll angles that could
• prevent attitude recovery from inverted flight
• improved yaw handling in EKF2 near ground
• added IMU heater support on Pixhawk2
• allow for faster accel bias learning in EKF2
• fixed in-flight yaw reset bug in EKF2
• added AP_Module support for loadable modules
• support Disco airframe from Parrot
• use full throttle in initial takeoff in TECS
• added NTF_LED_OVERRIDE support
• added terrain based simulation in SITL
• merged support for wide range of VRBrain boards
• added support for PH2SLIM and PHMINI boards with BRD_TYPE
• greatly reduced boot time on Pixhawk and similar boards
• fixed magic check for signing key in MAVLink2
• fixed averaging of gyros for EKF2 gyro bias estimate

Many thanks to the many people who have contributed to this release, and happy flying!

ArduPilot has been able to use X-Plane as a HIL (hardware in the loop) backend for quite some time, but it never worked particularly well as the limitations of the USB interface to the hardware prevented good sensor timings.

We have recently added the ability to use X-Plane 10 as a SITL backend, which works much better. The SITL (software in the loop) system runs ArduPilot natively on your desktop machine, and talks to X-Plane directly using UDP packets.

The above video demonstrates flying a Boeing 747-400 in X-Plane 10 using ArduPilot SITL. It flies nicely, and does an automatic takeoff and landing quite well. You can use almost any of the fixed wing aircraft in X-Plane with ArduPilot SITL, which opens up a whole world of simulation to explore. Many people create models of their own aircraft in order to test out how they will fly or to test them in conditions (such as very high wind) that may be dangerous to test with a real model.

I have written up some documentation on how to use X-Plane 10 with SITL to help people get started. Right now it only works with X-Plane 10 although I may add support for X-Plane 9 in the future.

Michael Oborne has added nice support for using X-Plane with SITL in the latest beta of MissionPlanner, and does nightly builds of the SITL binary for Windows. That avoids the need to build ArduPilot yourself if you just want to fly the standard code and not modify it yourself.

Limitations

There are some limitations to the X-Plane SITL backend. First off, X-Plane has quite slow network support. On my machine I typically get a sensor data rate of around 27Hz, which is far below the 1200 Hz we normally use for simulation. To overcome this the ArduPilot SITL code does sensor extrapolation to bring the rate up to around 900Hz, which is plenty for SITL to run. That extrapolation introduces small errors which can make the ArduPilot EKF state estimator unhappy. To avoid that problem we run with "EKF type 10" which is a fake AHRS interface that gets all state information directly from the simulator. That means you can't use the X-Plane SITL backend to test EKF settings.

The next limitation is that the simulation fidelity depends somewhat on the CPU load on your machine. That is an unfortunate consequence of X-Plane not supporting lock-step scheduling. So you may notice that simulated aircraft on your machine may not fly identically to the same aircraft on someone elses machine. You can reduce this effect by lowering the graphics settings in X-Plane.

We can currently only get joystick input from X-Plane for aileron, elevator, rudder and throttle. It would be nice to support flight mode switches, flaps and other controls that are normally used with ArduPilot. That is probably possible, but isn't implemented yet. So if you want a full controller then you can instead connect a joystick to SITL directly instead of via X-Plane (for example using the MissionPlanner joystick module or the mavproxy joystick module).

Finally, we only support fixed wing aircraft in X-Plane at the moment. I have been able to fly a helicopter, but I needed to give manual collective control from a joystick as we don't yet have a way to provide collective pitch input over the X-Plane data interface.

Manned AIrcraft and ArduPilot

Please don't assume that because ArduPilot can fly full sized aircraft in a simulator that you should use ArduPilot to fly real manned aircraft. ArduPilot is not suitable for manned applications and the development team would appreciate it if you did not try to use it for manned aircraft.

Happy Flying

I hope you enjoy flying X-Plane 10 with ArduPilot SITL!

The ArduPilot development team is proud to announce the release of version 3.6.0 of APM:Plane. This is a major update so please read the notes carefully.

The biggest changes in this release are:

• major update to PX4Firmware code
• major update to QuadPlane code
• addition of MAVLink2 support

Updated PX4Firmware

The updated PX4Firmware tree greatly improves support for the new Pixracer boards as well as improving scheduling performance and UAVCAN support. It also adds OneShot support for multirotor motors in QuadPlanes.

QuadPlane Updates

The QuadPlane changes are very extensive in this release. A lot of new features have been added, including:

• improved automatic weathervaning
• greatly improved support for mixed fixed wing and VTOL missions
• automatic RTL with VTOL land
• VTOL GUIDED mode support
• greatly improved transition code
• new tuning system for VTOL motors
• extensive upgrade to logging system for much better flight analysis

 
The new QuadPlane features are documented at:

http://ardupilot.org/plane/docs/quadplane-support.html

Please read the documentation carefully if you are flying a QuadPlane!

Tiltrotors and Tiltwings

This release has initial support for a variety of tiltrotors and tiltwing configurations. So far testing of these types of aircraft has been limited to simulations and it should be considered very experimental.

MAVLink2 Support

The new MAVLink2 support will allow for greatly expanded MAVLink protocol features in the future, and includes support for signing of MAVLink connections for the first time, making them secure against malicious attacks. I will do a separate blog post on upgrading to MAVLink2 soon. MAVLink1 is still the default for this release, but you can enable MAVLink2 on a per port basis by setting SERIALn_PROTOCOL=2.

Credits

Many thanks to everyone who has contributed to this release. Tom and I have been delighted at the number and quality of contributions across the community, and to the extensive testing and flight logs that have been provided.

We would also like to give a special thanks to UAV Solutions for sponsoring the development of many of the new QuadPlane features in this release and Airphrame for development of the improvements to the landing code. We'd also like to thanks aAVIonix for providing hardware for testing of ADSB features.

Special thanks also for the great contributions by many long term contributors to the project. Major contributions to this release have been made by:

• Peter Barker
• Lucas De Marchi
• Gustavo Jose de Sousa
• Leonard Hall
• Paul Riseborough
• Francisco Ferreira
• Michael du Breuil
• Grant Morphett
• Michael Oborne
• The PX4 development team

among many others. Tom and I really appreciate the effort!

Some of you may also have noticed that Tom Pittenger from Airphrame is now co-lead with me on the fixed wing support for ArduPilot. Tom has been a major contributor for a long time and the dev team was delighted to appoint him as co-lead.

Other Changes
Detailed changes in this release include:

• added motortest for all quad motors in sequence
• merge upstream PX4Firmware changes
• new AC_AttitudeControl library from copter for quadplane
• modified default gains for quadplanes
• new velocity controller for initial quadplane landing
• smooth out final descent for VTOL landing
• changed default loop rate for quadplanes to 300Hz
• support up to 16 output channels (two via SBUS output only)
• fixed bug with landing flare for high values of LAND_FLARE_SEC
• improved crash detection logic
• added in-flight transmitter tuning
• fix handling of SET_HOME_POSITION
• added Q_VFWD_GAIN for forward motor in VTOL modes
• added Q_WVANE_GAIN for active weathervaning
• log the number of lost log messages
• move position update to 50hz loop rather then the 10hz
• Suppress throttle when parachute release initiated, not after release.
• support Y6 frame class in quadplane
• log L1 xtrack error integrator and remove extra yaw logging
• limit roll before calculating load factor
• simplify landing flare logic
• smooth-out the end of takeoff pitch by reducing takeoff pitch min via TKOFF_PLIM_SEC
• added support for DO_VTOL_TRANSITION as a mission item
• fixed is_flying() for VTOL flight
• added Q_ENABLE=2 for starting AUTO in VTOL
• reload airspeed after VTOL landing
• lower default VTOL ANGLE_MAX to 30 degrees
• Change mode to RTL on end of mission rather then staying in auto
• implemented QRTL for quadplane RTL
• added Q_RTL_MODE parameter for QRTL after RTL approach
• reduced the rate of EKF and attitude logging to 25Hz
• added CHUTE_DELAY_MS parameter
• allow remapping of any input channel to any output channel
• numerous waf build improvements
• support fast timer capture for camera trigger feedback
• numerous improvements for Pixracer support
• added more general tiltrotor support to SITL
• only save learned compass offsets when disarmed
• support MISSION_ITEM_INT for more accurate waypoint positions
• change parachute deployment altitude to above ground not home
• added AP_Tuning system for QuadPlane tuning
• added initial support for tiltrotors and tiltwings
• added LOG_REPLAY and LOG_DISARMED parameters
• added Q_GUIDED_MODE parameter
• major update to QuadPlane documentation
• added MAVLink2 support
• fixed origin vs home altitude discrepancy
• improved Lidar based landing glide slope
• fixed throttle failsafe with THR_PASS_STAB=1
• prevent EKF blocking during baro and airspeed cal
• allow for ground testing of parachutes with CHUTE_MINALT=0
• fixed elevator stick mixing for above 50% input
• added QuadPlane ESC calibration

Happy flying!

As mentioned on the 3.5.2 release discussion we have decided to do a 3.5.3 release to fix a couple of important bugs found by users in 3.5.2.

The main motivation for the release is a problem with flying without a compass enabled. If you fly 3.5.2 with MAG_ENABLE=0 or no compass attached then there is a risk that the EKF2 attitude estimator may become unstable before takeoff. This can cause the aircraft to crash.

The other changes in the 3.5.2 release are more minor:

• fixed loiter radius for counter-clockwise loiter
• fixed the loiter radius when doing a RTL at the end of a mission
• provide reasons to the GCS when a uBlox GPS fails to properly configure
• support a wider variety of NMEA GPS receivers
• use EKF1 by default if no compass is enabled

For those of you feeling a bit more adventurous you might like to try the 3.6.0beta1 release. There is still a fair bit more to do before 3.6.0 is out, but it already has a lot of new features and I have been flying it for a while now.

The biggest single change in 3.6.0beta1 is the update of PX4Firmware. This brings with it a lot of changes, including much better support for the Pixracer flight board.

There has also been a lot more work on QuadPlane support, which a new QRTL flight mode, plus support for using the forward motor in VTOL flight and active weathervaning support. If you are flying a QuadPlane you'll find the names of the copter rate control parameters have changed (just like they have in copter). You should be able to find the new parameters OK, but if not then please ask. I'll provide more detailed documentation with the final 3.6.0 release.

Detailed changes in 3.6.0beta1 include:

• merge upstream PX4Firmware changes
• new AC_AttitudeControl library from copter for quadplane
• modified default gains for quadplanes
• new velocity controller for initial quadplane landing
• smooth out final descent for VTOL landing
• changed default loop rate for quadplanes to 300Hz
• support up to 16 output channels (two via SBUS output only)
• fixed bug with landing flare for high values of LAND_FLARE_SEC
• improved crash detection logic
• added in-flight transmitter tuning
• fix handling of SET_HOME_POSITION
• added Q_VFWD_GAIN for forward motor in VTOL modes
• added Q_WVANE_GAIN for active weathervaning
• log the number of lost log messages
• Move position update to 50hz loop rather then the 10hz
• Suppress throttle when parachute release initiated, not after release.
• support Y6 frame class in quadplane
• log L1 xtrack error integrator and remove extra yaw logging
• limit roll before calculating load factor
• simplify landing flare logic
• smooth-out the end of takeoff pitch by reducing takeoff pitch min via TKOFF_PLIM_SEC
• added support for DO_VTOL_TRANSITION as a mission item
• fixed is_flying() for VTOL flight
• added Q_ENABLE=2 for starting AUTO in VTOL
• reload airspeed after VTOL landing
• lower default VTOL ANGLE_MAX to 30 degrees
• Change mode to RTL on end of mission rather then staying in auto
• implemented QRTL for quadplane RTL
• added Q_RTL_MODE parameter for QRTL after RTL approach
• reduced the rate of EKF and attitude logging to 25Hz
• added CHUTE_DELAY_MS parameter
• allow remapping of any input channel to any output channel
• numerous waf build improvements
• support fast timer capture for camera trigger feedback
• numerous improvements for Pixracer support
• added more general tiltrotor support to SITL

I flew both 3.5.3 and 3.6.0beta1 today and both are really flying nicely. I hope you all enjoy flying it as much as the dev team enjoy working on it!

Happy flying!

The ArduPilot development team is proud to announce the release of version 3.5.2 of APM:Plane. This is a minor release with small changes.

The main reason for this release over the recent 3.5.1 release is a fix for a bug where the px4io co-processor on a Pixhawk can run out of memory while booting. This causes the board to be unresponsive on boot. It only happens if you have a more complex servo setup and is caused by too much memory used by the IO failsafe mixer.

The second motivation for this release is to fix an issue where during a geofence altitude failsafe that happens at low speed an aircraft may dive much further than it should to gain speed. This only happened if the thrust line of the aircraft combined with low pitch integrator gain led to the aircraft not compensating sufficiently with elevator at full throttle in a TECS underspeed state. To fix this two changes have been made:

• a minimum level of integrator in the pitch controller has been added. This level has a sufficiently small time constant to avoid the problem with the TECS controller in an underspeed state.
• the underspeed state in TECS has been modified so that underspeed can end before the full target altitude has been reached, as long as the airspeed has risen sufficiently past the minimum airspeed for a sufficient period of time (by 15% above minimum airspeed for 3 seconds).

Many thanks to Marc Merlin for reporting this bug!

The default P gains for both roll and pitch have also been raised from 0.4 to 0.6. This is to help for users that fly with the default parameters. A value of 0.6 is safe for all aircraft that I have analysed logs for.

The default gains and filter frequencies of the QuadPlane code have also been adjusted to better reflect the types of aircraft users have been building.

Other changes include:

• improved QuadPlane logging for better analysis and tuning (adding RATE and QTUN messages)
• fixed a bug introduced in 3.5.1 in rangefinder landing
• added TECS logging of speed_weight and flags
• improvements to the lsm303d driver for Linux
• improvements to the waf build system

Happy flying!

If you have visited ardupilot.com recently you may have noticed you are redirected to our new documentation system on ardupilot.org. This is part of our on-going transformation of the ardupilot project that we announced in a previous post.

The new documentation system is based on sphinx and was designed by Hamish Willee. I think Hamish has done a fantastic job with the new site, creating something that will be easier to manage and update, while using less server resources which should make it more responsive for users.

Updates to the documentation will now be done via github pull requests, using the new ardupilot_wiki repository. That git will also host documentation issues, and includes all the issues from the old tracking repository imported to the new repository.

Many thanks to everyone who has helped with this conversion, including Hamish, Buzz, Jani and Peter.

We have endeavoured to make as many existing URLs auto-redirect to the correct URL on the new site, but there are bound to be some errors for which we apologise. If you find issues with the new site please either respond here or open an issue on the repository.

Happy flying!

The ArduPilot development team is proud to announce the release of version 3.5.1 of APM:Plane. This is a minor release with primarily small changes.

The changes in this release are:

• update uavcan to new protocol
• always exit loiter in AUTO towards next waypoint
• support more multicopter types in quadplane
• added support for reverse thrust landings
• added LAND_THR_SLEW parameter
• added LAND_THEN_NEUTRL parameter
• fixed reporting of armed state with safety switch
• added optional arming check for minimum voltage
• support motor test for quadplanes
• added QLAND flight mode (quadplane land mode)
• added TECS_LAND_SRC (land sink rate change)
• use throttle slew in quadplane transition
• added PID tuning for quadplane
• improved text message queueing to ground stations
• added LAND_THR_SLEW parameter
• re-organisation of HAL_Linux bus API
• improved NMEA parsing in GPS driver
• changed TECS_LAND_SPDWGT default to -1
• improved autoconfig of uBlox GPS driver
• support a wider range of Lightware serial Lidars
• improved non-GPS performance of EKF2
• allow for indoor flight of quadplanes
• improved compass fusion in EKF2
• improved support for Pixracer board
• improved NavIO2 support
• added BATT_WATT_MAX parameter

The reverse thrust landing is particularly exciting as that adds a whole new range of possibilities for landing in restricted areas. Many thanks to Tom for the great work on getting this done.

The uavcan change to the new protocol has been a long time coming, and I'd like to thank Holger for both his great work on this and his patience given how long it has taken to be in a release. This adds support for automatic canbus node assignment which makes setup much easier, and also supports the latest versions of the Zubax canbus GPS.

My apologies if your favourite feature didn't make it into this release! There are a lot more changes pending but we needed to call a halt for the release eventually. This release has had a lot of flight testing and I'm confident it will be a great release.

Happy flying!

After the unfortunate crash of our last QuadPlane build with a failed ESC CanberraUAV wanted to build a new version with more redundancy in the VTOL part of the build. The result is the above OctaQuadPlane which we successfully flew for the first time yesterday.

When we were first designing a large QuadPlane we did consider an octa design, but rejected it due to what we thought would be a high degree of complexity and unnecessary weight. Needing wiring for both 8 vertical lift motors plus 4 controls for fixed wing flight, and extra controls for ignition cut and auxiliary functions like remote engine start, choke and payload control we worked out we'd need 15 PWM outputs. The Pixhawk only has 14 outputs.

After the failed ESC on the previous plane lost us the aircraft we looked again at an octa design and found that it would not only be possible, but could potentially be simpler for wiring than our last aircraft and be lighter as well, while having more lift.

To start with we looked for motors with a better power to weight ratio than the NTM Prop Drive 50-60 motors we used on the last build. We found them in the t-motor 3520-11 400kV motors. These very well regarded motors have a considerably better power to weight ratio, and back-to-back mounting of them was extremely simple and light with the above clamping arrangement.

To manage the complexity of the wiring we added support in ArduPilot for high speed SBUS output, and used one of these SBUS to PWM adapters embedded in each wing:

http://www.hobbyking.com/hobbyking/store/__24482__SBD4_4_Channel_S_BUS_Decoder.html

that allowed us to have a single wire from a Y-lead on the SBUS output port of the Pixhawk going to each wing. We modified the BRD_SBUS_OUT parameter in ArduPilot to allow setting of the SBUS frame rate, with up to 300Hz SBUS output. For a large QuadPlane 300Hz is plenty for multi-rotor control.

The arm mounting system we used was the same as for the previous plane, with two 20x20x800 CF square section tubes per wing, mounted on a 300x100x1 CF flat plate. The flat plate is glued to the wing with silicon sealant, and the CF tubes are glued to that plate with epoxy.

For ESCs we used the HobbyWing 40A, which has a burst rating of 60A. That is well above our expected hover current of 15A per motor. Combined with the redundancy of the OctaQuad and the better reputation of HobbyWing ESCs we were confident we wouldn't have a repeat of our previous crash.

For batteries we switched to 6S, using one 5Ah battery per wing. That gives us over 4 minutes of hover flying time while keeping the weight well below our last build (thanks largely to the lighter motors and ESCs).

For this initial test flight we had the fuel tank mounted horizontally unlike the previous vertical arrangement. This was OK as we only filled it a small amount for these test flights. We will be converting to a vertical arrangement again for future fights to reduce the impact of fuel slosh causing CoG oscillations. We may also fill it with fuel anti-slosh foam as we have done on some other aircraft (particularly the helicopters).

Overall the build came out about 1.5kg lighter than the previous build, coming in at 12.5kg dry weight. With a full load of fuel we'd expect to be about 13.5kg.

We did three test flights yesterday. The first was just a quick hover test to confirm everything was working as expected. After that we did the first transition test under manual control, which worked very nicely.

The copter part of the tuning could definitely do with some work, but we thought it was stable enough to do a full auto mission.

It was a short mission, with just two full circuits before landing, but it nicely demonstrated autonomous VTOL takeoff, transition to fixed wing flight, transition back to hover and auto landing. The landing came in within a meter of the desired landing point.

We had set the distance between the transition point and landing point a bit short, and we hadn't included a mission item for the plane to slow down before it transitioned which led to a more abrupt transition than is really good for the airframe. Going from 100km/hr to zero over a distance of 77 meters really puts a lot of stress on the wings. We'll fix that for future missions. It is nice to know it can handle it though.

The transition to hover also caused it to climb a fair bit which meant it spent more time in VTOL landing than we would have liked, chewing through the battery. That was caused by it having to pitch up to slow down enough to achieve the stopping point in the mission which caused it to climb as it still had a lot of lift from the wings, combined with a high angle of attack. It didn't help that we had a slow slew rate on the petrol motor, reducing the motor from full throttle to zero over a 3 second period. We chose a slow slew rate to reduce the chance of the engine cutting due to fast throttle changes. We can fix that with a bit of engine tuning and a longer transition distance - probably 130 meters would work better for this aircraft.

The climb on transition also took the aircraft into the sun from the pilots point of view, which isn't ideal but did result in a quite picturesque video of the plane silhouetted against the sun.

The full flight log is available here if anyone wants to see it. The new features (new SBUS output support and OctaQuad support for quadplanes) will be in the 3.5.1 plane release.

We're not done yet with QuadPlanes. Jack is building another one based on the Valiant, which you can see here next to the Porter:

Combined with the GX9 tradheli build that Greg has put together:

we are all set for lots of VTOL fun!

Many thanks to everyone who helped with the build and as always to CMAC for providing a great flying field!

The ArduPilot core development team is starting on a new phase in the project's development. We’ve been having a lot of discussions lately about how to become better organised and better meet the needs of both our great user community and the increasing number of organisations using ArduPilot professionally. The dev team is passionate about making the best autopilot software we can and we are putting the structures in place to make that happen.

Those of you who have been following the developments over the years know that ArduPilot has enjoyed a very close relationship with 3DRobotics for a long time, including a lot of direct funding of ArduPilot developers by 3DR. As 3DR changes its focus that relationship has changed, and the relationship now is not one of financial support for developers but instead 3DR will be one of many companies contributing to open source development both in ArduPilot and the wider DroneCode community. The reduction in direct funding by 3DR is not really too surprising as the level of financial support in the past was quite unusual by open source project standards.

Meanwhile the number of other individuals and companies directly supporting ArduPilot development has been increasing a lot recently, with over 130 separate people contributing to the code in the last year alone, and the range of companies making autopilot hardware and airframes aimed at ArduPilot users has also grown enormously.

We’re really delighted with how the developer community is working together, and we’re very confident that ArduPilot has a very bright future

Creation of ArduPilot non-profit

The ArduPilot dev team is creating a non-profit entity to act as a focal point for ArduPilot development. It will take a while to get this setup, but the aim is to have a governance body that aims to guide the direction the project takes and ensure the project meets the needs of the very diverse user community. Once the organisation is in place we will make another announcement, but you can expect it to be modelled on the many successful open source non-profits that exist across the free software community.

The non-profit organisation will oversee the management of the documentation, the auto-build and test servers and will help set priorities for future development.

We’re working with 3DR now to organise the transfer of the ardupilot.com domain to the development team leads, and will transfer it to the non-profit once that is established. The dev team has always led the administration of that site, so this is mostly a formality, but we are also planning on a re-work of the documentation to create an improved experience for the community and to make it easier to maintain.

Expansion of ArduPilot consulting businesses

In addition to the non-profit, we think there is a need for more consulting services around ArduPilot and DroneCode. We’ve recognised this need for a while as the developers have often received requests for commercial support and consulting services. That is why we created this commercial support list on the website last year:

http://planner.ardupilot.com/wiki/common-commercial-support/

It is time to take that to the next level by promoting a wider range of consulting services for ArduPilot. As part of that a group of the ArduPilot developers are in the process of creating a company that will provide a broad range of consulting services around ArduPilot. You will see some more announcements about this soon and we think this will really help ArduPIlot expand into places that are hard to get to now. We are delighted at this development, and hope these  companies listed on the website will provide a vibrant commercial support ecosystem for the benefit of the entire ArduPilot community.

Best of both worlds

We think that having a non-profit to steer the project while having consulting businesses to support those who need commercial support provides the best of both worlds. The non-profit ArduPilot project and the consulting businesses will be separate entities, but the close personal and professional relationships that have built up in the family of ArduPilot developers will help both to support each other.

Note that ArduPilot is committed to open source and free software principles, and there will be no reduction in features or attempt to limit the open source project. ArduPilot is free and always will be. We care just as much about the hobbyist users as we do about supporting commercial use. We just want to make a great autopilot while providing good service to all users, whether commercial or hobbyist.

Thank you!

We’d also like to say a huge thank you to all the ArduPilot users and developers that have allowed ArduPilot to develop so much in recent years. We’ve come a very long way and we’re really proud of what we have built.

Finally we’d also like to thank all the hardware makers that support ArduPilot. The huge range of hardware available to our users from so many companies is fantastic, and we want to make it easier for our users to find the right hardware for their needs. We will continue working to improve the documentation to make that easier.

Happy flying!

The ArduPilot Dev Team

Not all of the adventures that CanberraUAV have with experimental aircraft go as well as we might hope. This is the story of our recent build of a large QuadPlane and how the flight ended in a crash.

As part of our efforts in developing aircraft for the Outback Challenge 2016 competition CanberraUAV has been building both large helicopters and large QuadPlanes. The competition calls for a fast, long range VTOL aircraft, and those two airframe types are the obvious contenders.

This particular QuadPlane was the first that we've built that is of the size and endurance that we thought it would easily handle the OBC mission. We based it on the aircraft we used to win the OBC'2014 competition, a 2.7m wingspan VQ Porter with a 35cc DLE35 petrol engine. This is the type of aircraft you commonly see at RC flying clubs for people who want to fly larger scale civilian aircraft. It flies well and the fuselage and is easy to work on with plenty of room for additional payloads.

VQ Porter QuadPlane Build

The base airframe has a typical takeoff weight of a bit over 7kg. In the configuration we used in the 2014 competition it weighed over 11kg as we had a lot of extra equipment onboard like long range radios, the bottle drop system and onboard computers, plus lots of fuel. When rebuilt as a QuadPlane it weighed around 15kg, which is really stretching the base airframe to close to its limits.

To convert the porter to a QuadPlane we started by glueing 300x100 1mm thick carbon fibre sheets to the under-surface of the wings, and added 800x20x20 square section carbon fibre tubes as motor arms. This basic design was inspired by what Sander did for his QuadRanger build.

in the above image you can see the CF sheet and the CF tubes being glued to the wing. We used silicon sealant between the sheet and the wing, and epoxy for gluing the two 800mm tubes together and attaching them to the wing. This worked really well and we will be using it again.

For the batteries of the quad part of the plane we initially thought we'd put them in the fuselage as that is the easiest way to do the build, but after some further thought we ended up putting them out on the wings:

They are held on using velcro and cup-hooks epoxied to the CF sheet and spars, with rubber bands for securing them. That works really well and we will also be using it again.

The reason for the change to wing mounted batteries is twofold. The first is concerns of induction on the long wires needed in such a big plane leading to the ESCs being damaged (see for example http://www.rcgroups.com/forums/showthread.php?t=952523&highlight=engin+wire). The second is that we think the weight being out on the wings will reduce the stress on the wing root when doing turns in fixed wing mode.

We used 4S 5Ah 65C batteries in a 2S 2P arrangement, giving us 10Ah of 8S in total to the ESCs. We didn't cross-couple the batteries between left and right side, although we may do so in future builds.

For quad motors we used NTM Prop Drive 50-60 motors at 380kV. That is overkill really, but we wanted this plane to stay steady while hovering 25 knot winds, and for that you need a pretty high power to weight ratio to overcome the wind on the big wings. It certainly worked, flying this 15kg QuadPlane did not feel cumbersome at all. The plane responded very quickly to the sticks despite its size.

We wired it with 10AWG wire, which helped keep the voltage drop down, and tried to keep the battery cables short. Soldering lots of 10AWG connectors is a pain, but worth it. We mostly used 4mm bullets, with some HXT-4mm for the battery connectors. The Y connections needed to split the 8S across two ESCs was done with direct spliced solder connections.

For the ESCs we used RotorStar 120A HV. It seemed a good choice as it had plenty of headroom over the expected 30A hover current per motor, and 75A full throttle current. This ESC was our only major regret in the build, for reasons which will become clear later.

For props we used APC 18x5.5 propellers, largely because they are quite cheap and are big enough to be efficient, while not being too unwieldy in the build.

For fixed wing flight we didn't change anything over the setup we used for OBC'2014, apart from losing the ability to use the flaps due to the position of the quad arms. A VTOL aircraft doesn't really need flaps though, so it was no big loss. We expected the 35cc petrol engine would pull the plane along fine with our usual 20x10 prop.

We did reduce the maximum bank angle allowed in fixed wing flight, down from 55 degrees to 45 degrees. The aim was to keep the wing loading in reasonable limits in turns given we were pushing the airframe well beyond the normal flying weight. This worked out really well, with no signs of stress during fixed wing flight.

Test flights

The first test flight went fine. It was just a short hover test, with a nervous pilot (me!) at the sticks. I hadn't flown such a big quadcopter before (it is 15kg takeoff weight) and I muffed up the landing when I realised I should try and land off the runway to keep out of the way of other aircraft using the strip. I tried to reposition a few feet while landing and it landed heavier than it should have. No damage to anything except my pride.

The logs showed it was flying perfectly. Our initial guess of 0.5 for roll and pitch gains worked great, with the desired and achieved attitude matching far better than I ever expected to see in an aircraft of this type. The feel on the sticks was great too - it really responded well. That is what comes from having 10kW of power in an aircraft.

The build was meant to have a sustained hover time of around 4 minutes (using ecalc), and the battery we actually used for the flight showed we were doing a fair bit better than we predicted. A QuadPlane doesn't need much hover time.  For a one hour mission for OBC'2016 we reckon we need less than 2 minutes of VTOL flight, so 4 minutes is lots of safety margin.

Unfortunately the second test flight didn't go so well. It started off perfectly, with a great vertical takeoff, and a perfect transition to forward flight as the petrol engine engaged.

The plane was then flown for a bit in FBWA mode, and it responded beautifully. After that we switched to full auto and it flew the mission without any problems. It did run the throttle on the petrol engine at almost full throttle the entire time, as we were aiming for 28m/s and it was struggling a bit with the drag of the quad motors and the extra weight, but the tuning was great and we were already celebrating as we started the landing run.

The transition back to hover mode also went really well, with none of the issues we thought we might have had. Then during the descent for landing the rear left motor stopped, and we once again proved that a quadcopter doesn't fly well on 3 motors.

Unfortunately there wasn't time to switch back to fixed wing flight and the plane came down hard nose first. Rather a sad moment for the CanberraUAV team as this was the aircraft that had won the OBC for us in 2014. It was hard to see it in so many pieces.

We looked at the logs to try to see what had happened and Peter immediately noticed the tell tale sign of motor failure (one PWM channel going to maximum and staying there). We then looked carefully at the motors and ESCs, and after initially suspecting a cabling issue we found the cause was a burnt out ESC:

The middle FET is dead and shows burn marks. Tests later showed the FETs on either side in the same row were also dead. This was a surprise to us as the ESC was so over spec for our setup. We did discover one possible contributing cause:

that red quality control sticker is placed over the FET on the other side of the board from the dead one, and the design of the ESC is such that the heat from the dead FET has to travel via that covered FET to the heatsink. The sticker was between the FET and the heatsink, preventing heat from getting out.

All we can say for certain is the ESC failed though, so of course we started to think about motor redundancy. We're building two more large QuadPlanes now, one of them based on an OctaQuad design, in an X8 configuration with the same base airframe (a spare VQ Porter 2.7m that we had built for OBC'2014). The ArduPilot QuadPlane code already supports octa configs (along with hexa and several others). For this build we're using T-Motor MT3520-11 400kV motors, and will probably use t-motor ESCs. We will also still use the 18x5.5 props, just more of them!

Strangely enough, the better power to weight ratio of the t-motor motors means the new octa X8 build will be a bit lighter than the quad build. We're hoping it will come in at around 13.7kg, which will help reduce the load on the forward motor for fixed wing flight.

Many thanks to everyone involved in building this plane, and especially to Grant Morphett for all his building work and Jack Pittar for lots of good advice.

Building and flying a large QuadPlane has been a lot of fun, and we've learnt a lot. I hope to do a blog post of a more successful flight of our next QuadPlane creation soon!

The ArduPilot development team is proud to announce the release of the 3.5.0 version of APM:Plane. There have only been a few small changes since the 3.5.0beta1 release 3 weeks ago.

The key changes since 3.5.0beta1 are:

• addition of better camera trigger logging
• fixes to override handling (for users of the OVERRIDE_CHAN) parameter
• fixed a pulse glitch on startup on PX4

See the full notes below for details on the camera trigger changes.

For completeness, here are the full release notes. Note that this is mostly the same as the 3.5.0beta1 release notes, with a few small changes noted above.

The biggest changes in this release are:

• switch to new EKF2 kalman filter for attitude and position estimation
• added support for parachutes
• added support for QuadPlanes
• support for 4 new flight boards, the QualComm Flight, the BHAT, the PXFmini and the Pixracer
• support for arming on moving platforms
• support for better camera trigger logging

New Kalman Filter

The 3.4 release series was the first where APM:Plane used a Kalman Filter by default for attitude and position estimation. It works very well, but Paul Riseborough has been working hard recently on a new EKF variant which fixes many issues seen with the old estimator. The key improvements are:

• support for separate filters on each IMU for multi-IMU boards (such as the Pixhawk), giving a high degree of redundancy
• much better handling of gyro drift estimation, especially on startup
• much faster recovery from attitude estimation errors

After extensive testing of the new EKF code we decided to make it the default for this release. You can still use the old EKF if you want to by setting AHRS_EKF_TYPE to 1, although it is recommended that the new EKF be used for all aircraft.

Parachute Support

This is the first release with support for parachute landings on plane. The configuration and use of a parachute is the same as the existing copter parachute support. See http://copter.ardupilot.com/wiki/parachute/

Note that parachute support is considered experimental in planes.

QuadPlane Support

This release includes support for hybrid plane/multi-rotors called QuadPlanes. More details are available in this blog post: http://diydrones.com/profiles/blogs/quadplane-support-in-apm-plane-...

Support for 4 new Flight Boards

The porting of ArduPilot to more flight boards continues, with support for 4 new flight boards in this release. They are:

• the BHAT board
• the PXFmini
• the Qualcomm Flight
• the Pixracer (the first of the FMUv4 series of boards in the Pixhawk line)

More information about the list of supported boards is available here: http://dev.ardupilot.com/wiki/supported-autopilot-controller-boards/

I think the Pixracer is a particularly interesting board as it is so small, and will allow for some very small planes to fitted with an ArduPilot based Autopilot. It is really aimed at racing quads, but works well on small planes as well as long as you don't need more than 6 servos. Many thanks to AUAV for providing development Pixracer boards for testing.

Startup on a moving platform

One of the benefits of the new EKF2 estimator is that it allows for rapid estimation of gyro offset without doing a gyro calibration on startup. This makes it possible to startup and arm on a moving platform by setting the INS_GYR_CAL parameter to zero (to disable gyro calibration on boot). This should be a big help when flying off boats.

Improved Camera Trigger Logging

This release adds new CAM_FEEDBACK_PIN and CAM_FEEDBACK_POL parameters. These add support for separate CAM and TRIG log messages, where TRIG is logged when the camera is triggered and the CAM message is logged when an external pin indicates the camera has actually fired. This pin is typically based on the flash hotshoe of a camera and provides a way to log the exact time of camera triggering more accurately. Many thanks to Dario Andres and Jaime Machuca for their work on this feature.

Lots more!

That is just a taste of all of the improvements in this release. In total the release includes over 1500 patches. Some of the other more significant changes include:

• RPM logging
• new waf build system
• new async accel calibrator
• SITL support for quadplanes
• improved land approach logic
• better rangefinder power control
• ADSB adapter support
• dataflash over mavlink support
• settable main loop rate
• hideable parameters
• improved crash detection logic
• added optional smooth speed weighting for landing
• improved logging for dual-GPS setups
• improvements to multiple RTK GPS drivers
• numerous HAL_Linux improvements
• improved logging of CAM messages
• added support for IMU heaters in HAL_Linux
• support for RCInput over UDP in HAL_Linux
• improved EKF startup checks for GPS accuracy
• added raw IMU logging for all platforms
• added BRD_CAN_ENABLE parameter
• support FlightGear visualisation in SITL
• configurable RGB LED brightness
• improvements to the OVERRIDE_CHAN handling, fixing a race condition
• added OVERRIDE_SAFETY parameter

Many thanks to everyone who contributed to this release! The development team is growing at a fast pace, with 57 people contributing changes over this release cycle.

I'd like to make special mention of Tom Pittenger and Michael du Breuil who have been doing extensive testing of the plane development code, and also contributing a great deal of their own improvements. Thanks!

The ArduPilot development team is proud to announce the release of the first beta version of the 3.5.0 release of APM:Plane. We think this is going to be a great release and we'd love some feedback before we do the final version.

The biggest changes in this release are:

• switch to new EKF2 kalman filter for attitude and position estimation
• added support for parachutes
• added support for QuadPlanes
• support for 3 new flight boards, the QualComm Flight, the BHAT and the PXFmini
• support for arming on moving platforms

New Kalman Filter

The 3.4 release series was the first where APM:Plane used a Kalman Filter by default for attitude and position estimation. It works very well, but Paul Riseborough has been working hard recently on a new EKF variant which fixes many issues seen with the old estimator. The key improvements are:

• support for separate filters on each IMU for multi-IMU boards (such as the Pixhawk), giving a high degree of redundency
• much better handling of gyro drift estimation, especially on startup
• much faster recovery from attitude estimation errors

After extensive testing of the new EKF code we decided to make it the default for this release. You can still use the old EKF if you want to by setting AHRS_EKF_TYPE to 1, although it is recommended that the new EKF be used for all aircraft.

Parachute Support

This is the first release with support for parachute landings on plane. The configuration and use of a parachute is the same as the existing copter parachute support. See http://copter.ardupilot.com/wiki/parachute/

Note that parachute support is considered experimental in planes.

QuadPlane Support

This release includes support for hybrid plane/multi-rotors called QuadPlanes. More details are available in this blog post: http://diydrones.com/profiles/blogs/quadplane-support-in-apm-plane-3-5-0

Support for 3 new Flight Boards

The porting of ArduPilot to more flight boards continues, with support for 3 new flight boards in this release. They are:

• the BHAT board
• the PXFmini
• the Qualcomm Flight

More information about the list of supported boards is available here: http://dev.ardupilot.com/wiki/supported-autopilot-controller-boards/

Startup on a moving platform

One of the benefits of the new EKF2 estimator is that it allows for rapid estimation of gyro offset without doing a gyro calibration on startup. This makes it possible to startup and arm on a moving platform by setting the INS_GYR_CAL parameter to zero (to disable gyro calibration on boot). This should be a big help when flying off boats.

That is just a taste of all of the improvements in this release. In total the release includes over 1500 patches. Some of the other more significant changes include:

• RPM logging
• new waf build system
• new async accel calibrator
• SITL support for quadplanes
• improved land approach logic
• better rangefinder power control
• ADSB adapter support
• dataflash over mavlink support
• settable main loop rate
• hideable parameters
• improved crash detection logic
• added optional smooth speed weighting for landing
• improved logging for dual-GPS setups
• improvements to multiple RTK GPS drivers
• numerous HAL_Linux improvements
• improved logging of CAM messages
• added support for IMU heaters in HAL_Linux
• support for RCInput over UDP in HAL_Linux
• improved EKF startup checks for GPS accuracy
• added raw IMU logging for all platforms
• added BRD_CAN_ENABLE parameter
• support FlightGear visualisation in SITL
• configurable RGB LED brightness

Many thanks to everyone who contributed to this release! The development team is growing at a fast pace, with 57 people contributing changes over this release cycle.

I'd like to make special mention of Tom Pittenger and Michael du Breuil who have been doing extensive testing of the plane development code, and also contributing a great deal of their own improvements. Thanks!

The upcoming 3.5.0 release of APM:Plane includes support for QuadPlane - a hybrid plane/multi-rotor that allows for high speed long distance flight with vertical takeoff and landing.

The above video shows a converted HobbyKing Firstar 2000 doing a fully autonomous mission, with VTOL takeoff, followed by automatic transition to fixed wing flight and then a VTOL landing. The planes builder, Jack Pittar from CanberraUAV, is shown with the plane below.

The plane itself was fairly easy to build, with the simple additional of rectangular section aluminium arms on the Firstar wings and 4 quad motors.

One issue we found is that the battery we are using (a 3S 4Ah 65C) doesn't handle the 65A needed for vertical takeoff well, with the voltage dropping to 10V on takeoff. After takeoff completes and it transitions to fixed wing flight it quickly recovers. We will be changing the battery setup for future flights.

A second issue is that the wings tend to twist a bit in flight, especially when yaw is commanded. That greatly reduces yaw authority when hovering. We are still thinking about the best ways to prevent wing twist.

The new QuadPlane support is documented at http://plane.ardupilot.com/wiki/quadplane-support and is included in the 3.5.0beta1 release (I will do a separate blog post on that release shortly).

In the near future we expect to add support for other hybrid frame types, including tilt-rotors and fixed wing aircraft with other types of multi-rotor frames attached.

This QuadPlane follows on from our earlier Senior Telemaster QuadPlane which used two Pixhawk flight controllers.

We built the Firstar QuadPlane to test the new code where a single flight controller board running APM:Plane is used, which makes for much simpler operation. We plan on now building a much larger version, with a 50cc petrol motor for fixed wing flight.

The ArduPilot development team is proud to announce the release of version 3.4.0 of APM:Plane. This is a major release with a lot of changes so please read the notes carefully!

First release with EKF by default

This is the also the first release that enables the EKF (Extended Kalman Filter) for attitude and position estimation by default. This has been in development for a long time, and significantly improves flight performance. You can still disable the EKF if you want to using the AHRS_EKF_USE parameter, but it is strongly recommended that you use the EKF. Note that if an issue is discovered with the EKF in flight it will automatically be disabled and the older DCM system will be used instead. That should be very rare.

In order to use the EKF we need to be a bit more careful about the setup of the aircraft. That is why in the last release we enabled arming and pre-arm checks by default. Please don't disable the arming checks, they are there for very good reasons.

Last release with APM1/APM2 support

This will be the last major release that supports the old APM1/APM2 AVR based boards. We have finally run out of flash space and memory. In the last few releases we spent quite a bit of time trying to squeeze more and more into the small flash space of the APM1/APM2, but it had to end someday if ArduPilot is to continue to develop. I am open to the idea of someone else volunteering to keep doing development of APM1/APM2 so if you have the skills and inclination do please get in touch. Otherwise I will only do small point release changes for major bugs.

Even to get this release onto the APM1/APM2 we had to make sacrifices in terms of functionality. The APM1/APM2 release is missing quite a few features that are on the Pixhawk and other boards. For example:

• no rangefinder support for landing
• no terrain following
• no EKF support
• no camera control
• no CLI support
• no advanced failsafe support
• no HIL support (sorry!)
• support for far fewer GPS types

that is just the most obvious major features that are missing on APM1/APM2. There are also numerous other smaller things where we need to take shortcuts on the APM1/APM2. Some of these features were
available on older APM1/APM2 releases but needed to be removed to allow us to squeeze the new release onto the board. So if you are happy with a previous release on your APM2 and want a feature that is in that older release and not in this one then perhaps you shouldn't upgrade.

PID Tuning

While most people are happy with autotune to tune the PIDs for their planes, it is nice also to be able to do fine tuning by hand. This release includes new dataflash and mavlink messages to help with that
tuning. You can now see the individual contributions of the P, I and D components of each PID in the logs, allowing you to get a much better picture of the performance.

A simple application of this new tuning is you can easily see if your trim is off. If the Pitch I term is constantly contributing a signifcant positive factor then you know that ArduPilot is having to
constantly apply up elevator, which means your plane is nose heavy. The same goes for roll, and can also be used to help tune your ground steering.

Vibration Logging

This release includes a lot more options for diagnosing vibration issues. You will notice new VIBRATION messages in MAVLink and VIBE messages in the dataflash logs. Those give you a good idea of your
(unfiltered) vibration levels. For really detailed analysis you can setup your LOG_BITMASK to include raw logging, which gives you every accel and gyro sample on your Pixhawk. You can then do a FFT on the
result and plot the distribution of vibration level with frequency. That is great for finding the cause of vibration issues. Note that you need a very fast microSD card for that to work!

Rudder Disarm

This is the first release that allows you to disarm using the rudder if you want to. It isn't enabled by default (due to the slight risk of accidentially disarming while doing aerobatics). You can enable it
with the ARMING_RUDDER parameter by setting it to 2. It will only allow you to disarm if the autopilot thinks you are not flying at the time (thanks to the "is_flying" heuristics from Tom Pittenger).

More Sensors

This release includes support for a bunch more sensors. It now supports 3 different interfaces for the LightWare range of Lidars (serial, I2C and analog), and also supports the very nice Septentrio RTK
dual-frequency GPS (the first dual-frequency GPS we have support for). It also supports the new "blue label" Lidar from Pulsed Light (both on I2C and PWM).

For the uBlox GPS, we now have a lot more configurability of the driver, with the ability to set the GNSS mode for different constellations. Also in the uBlox driver we support logging of the raw carrier phase and pseudo range data, which allows for post-flight RTK analysis with raw-capable receivers for really accurate photo missions.

Better Linux support

This release includes a lot of improvements to the Linux based autopilot boards, including the NavIO+, the PXF and ERLE boards and the BBBMini and the new RasPilot board. If you like the idea of flying
with Linux then please try it out!

On-board compass calibrator

We also have a new on-board compass calibrator, which also adds calibration for soft iron effects, allowing for much more accurate compass calibration. Support for starting the compass calibration in the
various ground stations is still under development, but it looks like this will be a big improvement to compass calibration.

Lots of other changes!

The above list is just a taste of the changes that have gone into this release. Thousands of small changes have gone into this release with dozens of people contributing. Many thanks to everyone who helped!

Other key changes include:

• fixed return point on geofence breach
• enable messages for MAVLink gimbal support
• use 64 bit timestamps in dataflash logs
• added realtime PID tuning messages and PID logging
• fixed a failure case for the px4 failsafe mixer
• added DSM binding support on Pixhawk
• added ALTITUDE_WAIT mission command
• added vibration level logging
• ignore low voltage failsafe while disarmed
• added delta velocity and delta angle logging
• fix LOITER_TO_ALT to verify headings towards waypoints within the loiter radius
• allow rudder disarm based on ARMING_RUDDER parameter
• fix default behaviour of flaps
• prevent mode switch changes changing WP tracking
• make TRAINING mode obey stall prevention roll limits
• disable TRIM_RC_AT_START by default
• fixed parameter documentation spelling errors
• send MISSION_ITEM_REACHED messages on waypoint completion
• fixed airspeed handling in SITL simulators
• enable EKF by default on plane
• Improve gyro bias learning rate for plane and rover
• Allow switching primary GPS instance with 1 sat difference
• added NSH over MAVLink support
• added support for mpu9250 on pixhawk and pixhawk2
• Add support for logging ublox RXM-RAWX messages
• lots of updates to improve support for Linux based boards
• added ORGN message in dataflash
• added support for new "blue label" Lidar
• switched to real hdop in uBlox driver
• improved auto-config of uBlox
• raise accel discrepancy arming threshold to 0.75
• improved support for tcp and udp connections on Linux
• switched to delta-velocity and delta-angles in DCM
• improved detection of which accel to use in EKF
• improved auto-detections of flow control on pixhawk UARTs
• Failsafe actions are not executed if already on final approach or land.
• Option to trigger GCS failsafe only in AUTO mode.
• added climb/descend parameter to CONTINUE_AND_CHANGE_ALT
• added HDOP to uavcan GPS driver
• improved sending of autopilot version
• prevent motor startup with bad throttle trim on reboot
• log zero rangefinder distance when unhealthy
• added PRU firmware files for BeagleBoneBlack port
• fix for recent STORM32 gimbal support
• changed sending of STATUSTEXT severity to use correct values
• added new RSSI library with PWM input support
• fixed MAVLink heading report for UAVCAN GPS
• support LightWare I2C rangefinder on Linux
• improved staging of parameters and formats on startup to dataflash
• added new on-board compass calibrator
• improved RCOutput code for NavIO port
• added support for Septentrio GPS receiver
• support DO_MOUNT_CONTROl via command-long interface
• added CAM_RELAY_ON parameter
• moved SKIP_GYRO_CAL functionality to INS_GYR_CAL
• added detection of bad lidar settings for landing

Note that the documentation hasn't yet caught up with all the changes in this release. We are still working on that, but meanwhile if you see a feature that interests you and it isn't documented yet then please ask.

Anyone who has been involved in aeromodelling for a while dreams of having one of those days when everything works right. It doesn't happen often, but when it does it sure is nice!

CanberraUAV had one of those days yesterday. It was a wonderful sunny winters day at our local flying field and we were test flying our latest creations.

First up was the "Vampire Mark 2", a combined plane quadcopter built by Jack Pittar. It consists of a senior telemaster with a 15cc petrol engine, but with the addition of 4 quadcopter motors. It was the maiden flight yesterday, and it was setup with a Pixhawk controlling the quad engines and the rest controlled manually as a normal RC model. We flew with two pilots (Justin Galbraith and Jack Pittar). The takeoff was vertical as a quadcopter, and it then transitioned to fixed wing flight using the extremely simple method of advancing the throttle on the plane while lowering the throttle on the telemaster. Transition was very easy and the plane reached 31m/s in forward flight at full throttle. The landing transition was equally easy. Jack lowered the throttle on the plane while Justin raised the throttle on the quadcopter. No problems!

Given this was the first flight of a highly experimental aircraft we were pretty pleased with the result! Jack is thinking of building an even bigger version soon that will be able to complete the 2016 OBC mission with plenty of room for equipment.

Next up was our JS90 helicopter, originally built by Ryan Pope and adapted for autonomous flight.

This is the flybar version of the JS90-v2 heli from Hobbyking, with a OS GT15HZ petrol engine fitted, along with a Pixhawk2 and a new "Blue Label" Lidar from pulsedlight. We've been flying (and crashing!) this heli for a while now, but yesterday was finally the day when we got to try high speed autonomous flight.

apart from a small gap where we lost telemetry in the north west corner you can see the tracking in the auto mission was great. Once we learned how to tune a flybar heli (which turns out to be extremely simple!) it flies really well. We did have some issues getting it to fly as fast as we want. Above about 17m/s it occasionally pulled back and stopped for a second before continuing. We knew it could do more as it happily flew at over 27m/s in ALT_HOLD mode. With some help from Randy and a small code change to help with tuning we think we've tracked down the cause of that issue and expect to be doing 27m/s AUTO missions next weekend.

Next up was another quad plane, this one quite different from the big telemaster build!

We had been trying to track down a problem with loiter on the Parrot Bebop when running ArduPilot. We suspected there may have been a GPS lag issue, so we wanted to get some flight data that would allow us to compare the performance of a uBlox GPS with the GPS in the Bebop for dynamic flight. We thought a good way to do that would be to strap the Bebop to a plane and take it for a fly. The results were very interesting! For this flight we saw a lag on the Bebop GPS of over 5 seconds, which must be some sort of buffering issue. We'll chat to Julien from Parrot to see if we can track down the issue.

Next we thought it would be fun to see if something else could lift the tiny Bebop. Peter had his Solo there, so we strapped the Bebop to it and went for a fast fly in drift mode. Great fun!

Overall it was a fantastic day! Next week we're really looking forward to trying the Trex700 petrol conversion that Greg has built which you can see in the background in this photo of our build day on Saturday. The build looks really good and we expect it to perform even better than the JS90, as Greg has managed to fit a Pixhawk while still being able to install the canopy. That should reduce drag quite a lot.

The switch of focus for CanberraUAV to VTOL aircraft has been a lot of work, but the results are really paying off and we're having a lot of fun in the process. We hope that we'll have a lot more weekends like this one in the future.

APM:Plane 3.3.0 released

The ardupilot development team is proud to announce the release of version 3.3.0 of APM:Plane. This is a major release with a lot of changes. Please read the release notes carefully!

The last stable release was 3 months ago, and since that time we have applied over 1200 changes to the code. It has been a period of very rapid development for ArduPilot. Explaining all of the changes that have been made would take far too long, so I've chosen some key changes to explain in detail, and listed the most important secondary changes in a short form. Please ask for details if there is a change you see listed that you want some more information on.

Arming Changes

This is the first release of APM:Plane where ARMING_CHECK and ARMING_REQUIRE both default to enabled. That means when you upgrade if you didn't previously have arming enabled you will need to learn about arming your plane.

Please see this page for more information on arming:

http://plane.ardupilot.com/wiki/arming-your-plane/

I know many users will be tempted to disable the arming checks, but please don't do that without careful thought. The arming checks are an important part of ensuring the aircraft is ready to fly, and a common cause of flight problems is to takeoff before ArduPilot is ready.

Re-do Accelerometer Calibration

Due to a change in the maximum accelerometer range on the Pixhawk all users must re-do their accelerometer calibration for this release. If you don't then your plane will fail to arm with a message saying that you have not calibrated the accelerometers.

Only 3D accel calibration

The old "1D" accelerometer calibration method has now been removed, so you must use the 3D accelerometer calibration method. The old method was removed because a significant number of users had poor flights due to scaling and offset errors on their accelerometers when they used the 1D method. My apologies for people with very large aircraft who find the 3D method difficult.

Note that you can do the accelerometer calibration with the autopilot outside the aircraft which can make things easier for large aircraft.

Auto-disarm

After an auto-landing the autopilot will now by default disarm after LAND_DISARMDELAY seconds (with a default of 20 seconds). This feature is to prevent the motor from spinning up unexpectedly on the ground
after a landing.

HIL_MODE parameter

It is now possible to configure your autopilot for hardware in the loop simulation without loading a special firmware. Just set the parameter HIL_MODE to 1 and this will enable HIL for any autopilot. This is designed to make it easier for users to try HIL without having to find a HIL firmware.

SITL on Windows

The SITL software in the loop simulation system has been completely rewritten for this release. A major change is to make it possible to run SITL on native windows without needing a Linux virtual machine. There should be a release of MissionPlanner for Windows soon which will make it easy to launch a SITL instance.

The SITL changes also include new backends, including the CRRCSim flight simulator. This gives us a much wider range of aircraft we can use for SITL. See http://dev.ardupilot.com/wiki/simulation-2/ for more information.

Throttle control on takeoff

A number of users had problems with pitch control on auto-takeoff, and with the aircraft exceeding its target speed during takeoff. The auto-takeoff code has now been changed to use the normal TECS throttle control which should solve this problem.

Rudder only support

There is a new RUDDER_ONLY parameter for aircraft without ailerons, where roll is controlled by the rudder. Please see the documentation for more information on flying with a rudder only aircraft:

http://plane.ardupilot.com/wiki/ardupla ... udder_only

APM1/APM2 Support

We have managed to keep support for the APM1 and APM2 in this release, but in order to fit it in the limited flash space we had to disable some more features when building for those boards. For this release the AP_Mount code for controlling camera mounts is disabled on APM1/APM2.

At some point soon it will become impractical to keep supporting the APM1/APM2 for planes. Please consider moving to a 32 bit autopilot soon if you are still using an APM1 or APM2.

New INS code

There have been a lot of changes to the gyro and accelerometer handling for this release. The accelerometer range on the Pixhawk has been changed to 16g from 8g to prevent clipping on high vibration aircraft, and the sampling rate on the lsm303d has been increased to 1600Hz.

An important bug has also been fixed which caused aliasing in the sampling process from the accelerometers. That bug could cause attitude errors in high vibration environments.

Numerous Landing Changes

Once again there have been a lot of improvements to the automatic landing support. Perhaps most important is the introduction of a smooth transition from landing approach to the flare, which reduces the tendency to pitch up too much on flare.

There is also a new parameter TECS_LAND_PMAX which controls the maximum pitch during landing. This defaults to 10 degrees, but for many aircraft a smaller value may be appropriate. Reduce it to 5 degrees if you find you still get too much pitch up during the flare.

Other secondary changes in this release include:

• a new SerialManager library which gives much more flexible management of serial port assignment
• changed the default FS_LONG_TIMEOUT to 5 seconds
• raised default IMAX for roll/pitch to 3000
• lowered default L1 navigation period to 20
• new BRD_SBUS_OUT parameter to enable SBUS output on Pixhawk
• large improvements to the internals of PX4Firmware/PX4NuttX for better performance
• auto-formatting of microSD cards if they can't be mounted on boot (PX4/Pixhawk only)
• a new PWM based driver for the PulsedLight Lidar to avoid issues with the I2C interface
• fixed throttle forcing to zero when disarmed
• only reset mission on disarm if not in AUTO mode
• much better handling of steep landings
• added smooth transition in landing flare
• added HIL_MODE parameter for HIL without a special firmware
• lowered default FS_LONG_TIMEOUT to 5 seconds
• mark old ELEVON_MIXING mode as deprecated
• fixed 50Hz MAVLink support
• support DO_SET_HOME MAVLink command
• fixed larger values of TKOFF_THR_DELAY
• allow PulsedLight Lidar to be disabled at a given height
• fixed bungee launch (long throttle delay)
• fixed a bug handling entering AUTO mode before we have GPS lock
• added CLI_ENABLED parameter
• removed 1D accel calibration
• added EKF_STATUS_REPORT MAVLink message
• added INITIAL_MODE parameter
• added TRIM_RC_AT_START parameter
• added auto-disarm after landing (LAND_DISARMDELAY)
• added LOCAL_POSITION_NED MAVLink message
• avoid triggering a fence breach in final stage of landing
• rebuild glide slope if we are above it and climbing
• use TECS to control throttle on takeoff
• added RUDDER_ONLY parameter to better support planes with no ailerons
• updated Piksi RTK GPS driver
• improved support for GPS data injection (for Piksi RTK GPS)
• added NAV_LOITER_TO_ALT mission item
• fixed landing approach without an airspeed sensor
• support RTL_AUTOLAND=2 for landing without coming to home first
• disabled camera mount support on APM1/APM2
• added support for SToRM32 and Alexmos camera gimbals
• added support for Jaimes mavlink enabled gimbal
• improved EKF default tuning for planes
• updated support for NavIO and NavIO+ boards
• updated support for VRBrain boards
• fixes for realtime threads on Linux
• added simulated sensor lag for baro and mag in SITL
• made it possible to build SITL for native Windows
• switched to faster accel sampling on Pixhawk
• added coning corrections on Pixhawk
• set ARMING_CHECK to 1 by default
• disable NMEA and SiRF GPS on APM1/APM2
• support MPU9255 IMU on Linux
• updates to BBBMINI port for Linux
• added TECS_LAND_PMAX parameter
• switched to synthetic clock in SITL
• support CRRCSim FDM backend in SITL
• new general purpose replay parsing code
• switched to 16g accel range in Pixhawk
• added FENCE_AUTOENABLE=2 for disabling just fence floor
• added POS dataflash log message
• changed GUIDED behaviour to match copter
• added support for a 4th MAVLink channel
• support setting AHRS_TRIM in preflight calibration
• fixed a PX4 mixer out of range error

Many thanks to everyone who contributed to this release. We have a lot of new developers contributing which is really great to see! Also, apologies for those who have contributed a pull request but not yet had it incorporated (or had feedback on the change). We will be trying to get to as many PRs as we can soon.

Best wishes to all APM:Plane users from the dev team, and happy flying!