The ArduPilot development team has a special treat for fixed wing users today - a double release!

• A new stable 3.2.3 release with 3 fixes for 3.2.2
• A new 3.3.0beta1 release with a lot more changes for wider testing

The 3.2.3 release is a minor update to 3.2.2 with 3 fixes:

• A fixed to relative altitude drift when on the ground before takeoff
• fixed TKOFF_THR_DELAY to be able to be up to 127 (for 12.7 seconds)
• fixed INS_PRODUCT_ID (it was being reported as zero)

The most important fix is for the altitude drift, which could cause a poor altitude reference if your GPS altitude drifted while disarmed. The bug showed up as a significant drift in the reported relative altitude on the ground station when the aircraft was disarmed with the EKF enabled. The root cause of the bug was a disconnect between the EKF origin and the planes origin for relative altitudes. It only happened when the GPS altitude varied significantly while disarmed.

Start of 3.3.0 beta releases

The 3.3.0beta1 release has a lot more changes in it. The largest of the changes are internal, such as performance improvements in the NuttX operating system on Pixhawk, but given the size of the changes we want as many test users as possible.

Changes in 3.3.0beta1 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

I'm expecting a lot more changes will go into the 3.3.0 release as we still have a lot of pending pull requests. I will be doing regular beta updates as new patches go in (once they are flight tested).

Happy flying!

The ardupilot development team is proud to announce the release of version 3.2.1 of APM:Plane. This is primarily intended as a bugfix release, but does have some new features.

The major changes in this release are:

• fixed a mission handling bug that could cause a crash if jump commands form an infinite loop (thanks to Dellarb for reporting this bug)
• improved support for in-kernel SPI handling on Linux (thanks to John Williams)
• support UAVCAN based ESCs and GPS modules on Pixhawk (thanks to Pavel, Holger and and PX4 dev team)
• Multiple updates for the NavIO+ cape on RaspberryPi (thanks to Emlid)
• multiple automatic landing fixes, including improvements in flare detection, glide slope calculation and lag handling
• fixed a bug that could cause a change altitude MAVLink command from causing a sudden descent
• re-enable CLI on non-APM1/APM2 boards
• Lots of EKF changes, including reducing impact of ground magnetic interference, reducing the impact of a GPS outage and integrating optical flow support
• added initial support for the PX4 optical flow sensor. Just logging for this release.
• added support for MAVLink packet routing
• added detection and recovery from faulty gyro and accel sensors
• improved arming checks code to detect a lot more error conditions, and change the ARMING_CHECK default value to check all error conditions.
• added support for BBBMini Linux port
• increased number of AVR input channels from 8 to 11
• auto-set system clock based on GPS in Linux ports
• added SBUS FrSky telemetry support (thanks to Mathias)

IMU Failure detection

Perhaps the most important change for this release is the improvement to the detection and recovery of bad IMUs. We have had a number of reports of bad IMU data in flight from both the mpu6000 and lsm303d. Where possible the drivers how try to detect the failing sensor and reset it. Sometimes it can't be reset, in which case it will be locked out and the other IMU will be used, unless it is the last available IMU, in which case it will still be used. In either case the user is notified of the failure via the GCS so they can land.

UAVCAN support

The main new feature in this release is support for UAVCAN ESCs, GPS modules, compasses and barometers. Note that while support is in for UAVCAN ESCs and I have been flying with a UAVCAN ESC on my test plane for a few weeks very successfully, support for configuring the ESC is still fairly basic. You will need a debug cable to connect to the ESC to configure it as per the http://uavcan.org website. We hope to add MAVLink enabled configuration soon.

Many thanks to everyone who contributed so much to this release with bug reports, patches and suggestions. My apologies that we didn't get everything done that we wanted to get done. We have pushed some things out to the next release to prevent the release date sliding back any further.

Happy flying!

There are only a few days left to submit a paper for the Embedded Linux Conference in San Jose in March. This is the first conference with a Drone specific track organised under DroneCode.org.

Lorenz Meier and myself will both be presenting at the conference, and it will be a great opportunity for technical discussions within the DroneCode community. I'm really looking forward to meeting other members of the ArduPilot and DroneCode community and hearing about their work.

Call for Papers

The CE Workgroup of the Linux Foundation would like to invite you to make a presentation at our upcoming Embedded Linux Conference.  The conference will be held March 23 - 25 in San Jose, California.  The theme for this year is "Drones, Things and Automobiles", and we're excited to discuss some new areas where embedded Linux is really taking
off! (pun intended)

For general information about the conference, See http://events.linuxfoundation.org/events/embedded-linux-conference/

For information about the call for participation, see http://events.linuxfoundation.org/events/embedded-linux-conference/cfp

Please note the guidelines on the CFP page.  It's usually pretty obvious when we're reviewing the abstracts, as a program committee, who has read the guidelines and who hasn't.

ELC is the premier vendor-neutral technical conference for embedded Linux developers. The conference is open to the public.

Guidelines

Presentations should be of a technical nature, covering topics related to use of Linux in embedded systems.  Topics related to consumer electronics are particularly encouraged, but any proposals about Linux that are of general relevance to most embedded developers are welcome.

Presentations that are commercial advertisements or sales pitches are not appropriate for this conference.

Especially encouraged this year are talks in the following areas:

• Linux in Automotive
• Drones and Robots
• Linux in the Internet of Things

And we'd also love to hear your proposals in the following topic areas as well:

• Audio, Video, Streaming Media, and Graphics
• Security
• System size, Boot speed, and Real-Time Performance
• Flash Memory Devices and Filesystems
• Build Systems, Embedded Distributions, and Development tools
• Mobile Phones, DVRs, TVs, Cameras, etc.
• Practical Experiences and War Stories
• Standards

Most presentation slots will be 50 minutes long, including time for questions.

Tutorials, demos, and Birds-of-a-Feather sessions may also be proposed.

The deadline for submissions is midnight January 9, 2015 PDT.

To repeat, for additional info and details for making a proposal, see http://events.linuxfoundation.org/events/embedded-linux-conference/cfp

We've now had a few days to get back into a normal routine after the excitement of the Outback Challenge last week, so I thought this is a good time to write up a report on how things went for team I was part of, CanberraUAV. There have been plenty of posts already about the competition results, so I will concentrate on the technical details of our OBC entry, what went right and what went badly wrong.

For comparison, you might like to have a look at the debrief I wrote two years ago for the 2012 OBC. In 2012 there were far fewer teams, and nobody won the grand prize, although CanberraUAV went quite close. This year there were more than 3 times as many teams and 4 teams completed the criterion for the challenge, with the winner coming down to points. That means the Outback Challenge is well and truly "done", which reflects the huge advances in amateur UAV technology over the last few years.

The drama for CanberraUAV really started several weeks before the challenge. Our primary competition aircraft was the "Bushmaster", a custom built tail dragger with 50cc petrol motor designed by our chief pilot, Jack Pittar. Jack had designed the aircraft to have both plenty of room inside for whatever payload the rest of the team came up with, and to easily fit in the back of a station wagon. To achieve this he had designed it with a novel folding fuselage. Jack (along with several other team members) had put hundreds of hours into building the Bushmaster and had done a great job. It was beautifully laid out inside, and really was a purpose built Outback Challenge aircraft.

Just a couple of days after our D3 deliverable was sent in we had an unfortunate accident. A member of our local flying club was flying his CAP232 aerobatic plane at the same time we we were doing a test mission, and he misjudged a loop. The CAP232 loop went right through the rear of the Bushmaster fuselage, slicing it off. The Bushmaster hit the ground at 180 km/h, with predictable results.

Jack and Greg set to work on a huge effort to build a new Bushmaster, but we didn't manage to get it done in time. Luckily the OBC organisers allowed us to switch to our backup aircraft, a VQ Porter 2.7m RTF with some customisations. We had included the Porter in our D2 deliverable just in case it was needed, and already had plenty of autonomous hours up on it as we had been using it as a test aircraft for all our systems. It was the same basic style as the Bushmaster (a petrol powered tail dragger), but was a bit more cramped inside for fitting our equipment and used a bit smaller engine (a DLE35).

Strategy

Our basic strategy this year was the same as in 2012. We would search at a relatively low altitude (100m AGL this year, compared to 90m AGL in 2012), with a interleaved "mow the lawn" pattern. This year we setup the search with 60% overlap compared with 50% last year, and we had a longer turn around area at the end of each search leg to ensure the aircraft got back on track fully before it entered the search area. With that search pattern and a target airspeed of 28m/s we expected to cover the whole search area in 20 minutes, then we would cover it again in the reverse direction (with a 50m offset) if we didn't find Joe on the first pass.

As with 2012 we used an on-board computer to autonomously find Joe. This year we used an Odroid-XU, which is a quad core system running at 1.6GHz. That gave us a lot more CPU power than in 2012 (when we used a pandaboard), which allowed us to use more CPU intensive image recognition code. We did the first level histogram scanning at the full camera resolution this year (1280x960), whereas in 2012 we had run the first level scan at 640x480 to save CPU. That is why we were happy to fly a bit higher this year.

While the basic approach to image recognition was the same, we had improved the details of the implementation a lot in the last two years, with hundreds of small changes to the image scoring, communications and user interface. Using our 2012 image data as a guide (along with numerous test flights at our local flying field) we had refined the cuav code to provide much better object discrimination, and also to cope better with communication failures. We were pretty confident it could find Joe very reliably.

The takeoff

When the running order was drawn from a hat we were the 2nd last team on the list, so we ended up flying on the Friday. We'd been up early each morning anyway in case the order was changed (which does happen sometimes), and we'd actually been called out to the airfield on the Thursday afternoon, but didn't end up flying then due to high wind.

Our time to takeoff finally came just before 8am Friday morning. As with 2012 we did an auto takeoff, using the new tail-dragger takeoff coded added to APM:Plane just a couple of months before.

Unfortunately the takeoff did not go as planned. In fact, we were darn lucky the plane got into the air at all! As soon as Jack flicked the switch on the transmitter to put the plane into AUTO it started veering left on the runway, and nearly scraped a wing as it limped it's way into the air. A couple of seconds later it came quite close to the tents where the OBC organisers and our GCS was located.

It did get off the ground though, and missed the tents while it climbed, finally switching to normal navigation to the 2nd waypoint once it got to an altitude of 40m. Jack had his finger on the switch on the transmitter which would have taken manual control and very nearly aborted the takeoff. This would have to go down as one of the worst takeoffs in OBC history.

So why did it go so badly wrong? My initial analysis when I looked at the logs later was that the wind had pushed the plane sideways. After examining the logs more carefully though I discovered that while the wind did play a part, the biggest issue was the compass. For some reason the compass offsets we had loaded were quite different from the ones we had been testing with in all our flights in Canberra. I still don't know why the offsets changed, although the fact that we had compass learning enabled almost certainly played a part. We'd done dozens of auto takeoffs in Canberra with no issues, with the plane tracking beautifully down the center line of the runway. To have it go so badly wrong for the flight that matters was a disappointment.

I've decided that the best way to fix the issue for future flights is to make the auto takeoff code completely independent of the compass. Normally the compass is needed to get an initial yaw for the aircraft while it is not moving (as our hobby-grade GPS sensors can't give yaw when not moving), and that initial yaw is used to set the ground heading for the takeoff. That means that with the current code, any compass error at the time you change into AUTO will directly impact the takeoff.

Because takeoff is quite a short process (usually 20s or less), we can take an alternative approach. The gyros won't drift much in 20s, so what we can do is just keep a constant gyro heading until the aircraft is moving fast enough to guarantee a good GPS ground track. At that point we can add whatever gyro based yaw error has built up to the GPS ground course and use that as our navigation heading for the rest of the takeoff. That should make us completely independent of compass for takeoff, which should solve the problem for everyone, rather than just fixing it for our aircraft. I'm working on a set of patches to implement this, and expect it to be in the next release.

Note that once the initial takeoff is complete the compass plays almost no role in the flight of a fixed wing plane if you have the EKF enabled, unless you lose GPS lock. The EKF rejected our compass as being inconsistent, and happily got correct yaw from the fusion of GPS velocity and other sensors for the rest of the flight.

The search

After the takeoff things went much more smoothly. The plane headed off to the search area as planned, and tracked the mission extremely well. It is interesting to compare the navigation accuracy of this years mission compared to the 2012 mission. In 2012 we were using a simple vector field navigation algorithm, whereas we now use the L1 navigation code. This year we also used Paul's EKF for attitude and position estimation, and the TECS controller for speed/height control. The differences are really remarkable. We were quite pleased with how our Mugin flew in 2012, but this year it was massively better. The tracking along each leg of the search was right down the line, despite the 15 knot winds.

Another big difference from 2012 is that we were using the new terrain following capability that we had added this year. In 2012 we used a python script to generate our waypoints and that script automatically added intermediate waypoints to follow the terrain of the search area. This year we just set all waypoints as 100 meters AGL and let the autopilot do its job. That made things a lot simpler and also resulted in better geo-referencing and search area coverage.

On our GCS imaging display we had 4 main windows up. One is a "live" view from the camera. That is setup to only update if there is plenty of spare bandwidth on our radio links, and is really just there to give us something to watch while the imaging code does its job, plus to give us some situational awareness of what the aircraft is tracking over.
The second window is the map, which shows the mission flight path, the geo-fence, two plane icons (AHRS position estimate and GPS position estimate) plus overlays of thumbnails from the image recognition system of any "interesting" objects the Odroid has found.

The 3rd window is the "Mosaic" window. That shows a grid of thumbnails from the image recognition system, and has menus and hot-keys to allow us to control the image recognition process and sort the thumbnails in various ways. We expected Joe to have a image score of over 1000, but we set the threshold for thumbnails to display in the mosaic as 500. Setting a lower threshold means we get shown a lot of not very interesting thumbnails (things like oddly shaped tree stumps and patches of dirt that are a bit out of the ordinary), but at least it means we can see the system is working, and it stops the search being quite so boring.

The final window is a still image window. That is filled with a full resolution image of whatever image we have selected for download from the aircraft, allowing us to get some context around a thumbnail if we want it. Often it is much easier to work out what an object is if you can see the surroundings.

On top of those imaging windows we also have the usual set of flight control windows. We had 3 laptops setup in our GCS tent, along with a 40" LCD TV for one of the laptops (my thinkpad). Stephen ran the flight monitoring on his laptop, and Matt helped with the imaging and the antenna tracker from his laptop. Splitting the task up in this way helped prevent overload of any one person, which made the whole experience more manageable.

On Stephens laptop he had the main MAVProxy console showing the status of the key parts of the autopilot, plus graphs showing the consistency of the various subsystems. The ardupilot code on Pixhawk has a lot of redundancy at both the sensor level and at the higher level algorithm level, and it is useful to plot graphs showing if we get any significant discrepancies, giving us a warning of a potential failure. For this flight everything went smoothly (apart from the takeoff) but it is nice to have enough screens to show this sort of information anyway. It also makes the whole setup look a bit more professional to have a few fancy graphs going :-)

About 20 minutes after takeoff the imaging system spotted Joe lying in his favourite position in a peanut field. We had covered nearly all of the first pass across the search area so we were glad to finally spot him. The images were very clear, so we didn't need to spend any time discussing if it really was Joe or not.

We clicked the "Show Position" menu item we'd added to the MAVProxy map, which pops up a window giving the position in various coordinate systems. Greg passed this to the judges who quickly confirmed it was within the required 100 meters of Joe.

The bottle drop

That initial position was only a rough estimate though. To refine the position we used a new trick we'd added to MAVProxy. The "wp movemulti" command allowed us to move and rotate a pre-defined confirmation flight pattern over the top of Joe. That setup the plane to fly a butterfly pattern over Joe at an altitude of 80 meters, passing over him with wings level. That gives an optimal set of images for our image recognition system to work with, and the tight turns allow the wind estimation algorithm in ardupilot to get an accurate idea of wind direction and speed.

In the weeks leading up to the competition we had spent a lot of time refining our bottle drop system. We realised the key to a good drop is timing consistency and accurate wind drift estimation.

To improve the timing consistency we had changed our bottle release mechanism to be in two stages. The bottle was held to the bottom of the Porter by two servos. One servo held the main weight of the bottle inside a plywood harness, while the second servo was attached to the top of the parachute by a wire, using a glider release mechanism.

The idea is that when approaching Joe for the drop the main servo releases first, which leaves the bottle hanging beneath the plane held by the glider release servo with the parachute unfurled. The wind drags the bottle at an angle behind the plane for 2 seconds before the 2nd servo is released. The result is much more consistent timing of the release, as there is no uncertainty in how long the bottle tumbles before the chute unfolds.

The second part of the bottle drop problem is good wind drift estimation. We had decided to use a small parachute as we were not certain the bottle would withstand the impact with the ground without a chute. That meant significant wind drift, which meant we really had to know the wind direction and speed quite accurately, and also needed some data on how fast the bottle would drift in the wind.

In the weeks before the competition we did a lot of bottle drops, but the really key one was a drop just a week before we left for Kingaroy. That was the first drop in completely still conditions, which meant it finally gave us a "zero wind" data point, which was important in calculating the wind drift. Combining that drop with some previous drop results we came up with a very simple formula giving the wind drift distance for a drop from 80 meters as 5 times the wind speed in meters/second, as long as we dropped directly into the wind.

We had added a new feature to APM:Plane to allow an exact "acceptance radius" for an individual waypoint to be set, overriding the global WP_RADIUS parameter. So once we had the wind speed and direction it was just a matter of asking MAVProxy to rotate the drop mission waypoints to match the wind (which was coming from -121 degrees) and to set the acceptance radius for the drop to 35 meters (70 meters for zero wind, minus 7 times 5 for the 7m/s wind the EKF had estimated).

The plane then slowed to 20m/s for the drop, and did a 350m approach to ensure the wings were nice and level at the drop point. As the drop happened we could see the parachute unfurl in the camera view from the aircraft, which was a nice confirmation that the bottle had been successfully dropped.

The mission was setup for the aircraft to go back to the butterfly confirmation pattern after the drop. We had done that to allow us to see where the bottle had actually landed relative to Joe, in case we wanted to do a 2nd drop. We had 3 bottles ready (one on the plane, two back at the airfield), and were ready to fit a new bottle and adjust the drop point if we'd been too far off.

As soon as we did the confirmation pass it became clear we didn't need to drop a 2nd bottle. We measured the distance of the bottle to Joe as under 3 meters using the imaging system (the judges measured it officially as 2.6m), so we asked the plane to come back and land.

The landing

This year we used a laser rangefinder (a SF/02 from LightWare) to help with the landing. Using a rangefinder really helps ensure the flare is at the right altitude and produces much more consistent landings.

The only real drama we had with the landing was that we came in a bit fast, and ballooned more than it should have on the flare. The issue was that we hadn't used a shallow enough approach. Combined with the quite strong (14 knot) cross-wind it was an "interesting" landing.

We also should have set the landing point a bit closer to the end of the runway. We had put it quite a way along the runway as we weren't sure if the laser rangefinder would pick up anything strange as it crossed over the road and airport boundary fence, but in hindsight we'd put the touchdown point a bit too close to the geofence. Full size glider operations running at the same time meant only part of the runway was available for OBC teams to use.

The landing was entirely successful, and was probably better than a manual landing would have been by me in the same wind conditions (I'm only a mediocre pilot, and landings are my weakest point), but we certainly can do better. Paul Riseborough is already looking at ways to improve the autoland to hopefully produce something that produces a round of applause from spectators in future landings.

Radio performance

Another part of the mission that is worth looking at is the radio performance. We had two radio links to the aircraft - one was a RFD900 900MHz radio, and that performed absolutely flawlessly as usual. We had around 40 dB of fade margin at a range of over 6km, which is absolutely huge. Every team that flew in the OBC this year used a RFD900, which is a great credit to Seppo and the team at RFDesign.

The 2nd radio was a Ubiquity Rocket M5, which is a 5.8GHz ethernet bridge. We used an active antenna tracker this year for the 5.8GHz link, with a 28dBi MIMO antenna on the ground, and a 10dBi MIMO omni antenna in the aircraft (the protrusion from the top of the fuselage is for the antenna). The 5.8GHz link gave us lots of bandwidth for the images, but was not nearly as reliable as the RFD900 link. It dropped out 6 times over the course of the mission, with the longest dropout lasting just over a minute. The dropouts were primarily caused by magnetometer calibration on the antenna tracker - during the mission we had to add some manual trim to the tracker to improve the alignment. That worked, but really we should have used a ground antenna with a bit less gain (maybe around 24dBi) to give us a wider beam width.

Another alternative would have been to use a lower frequency. The 5.8GHz Rocket gives fantastic bandwidth, but we don't really need that much bandwidth for our system. The Robota team used 2.4GHz Ubiquity radios and much simpler antennas and ended up with a much better link than we had. The difference in path loss between 2.4GHz and 5.8GHz is quite significant.

The reason we didn't use the 2.4GHz gear is that we do most of our testing at a local MAAA flying club, and we know that if someone crashes their expensive model while we have a powerful 2.4GHz radio running then there will always be the thought that our radio may have caused interference with their 2.4GHz RC link.

So we're now looking into the possibility of using a 900MHz ethernet bridge. The Ubiquity M900 looks like a real possibility. It doesn't offer nearly as much bandwidth as the 5.8GHz or 2.4GHz radios as Australia only has 13MHz of spectrum available in the 900MHz band for ISM use, but that should still be enough for our application. We have heard that the spread spectrum M900 doesn't significantly interfere with the RFD900 in the same band (as the RFD900 is a TDM frequency hopping radio), but we have yet to test that theory.

Alternatively we may use two RFD900s in the same aircraft, with different numbers of hopping channels and different air data rates to minimise interference. One would be dedicated to telemetry and the other to image data. A RFD900 at 128kbps should be plenty for our cuav imaging system as long as the "live camera view" window is set to quite a low resolution and update rate.

Team cooperation

One of the most notable things about this years competition was just how friendly the discussions between the teams were. The competition has a great spirit of cooperation and it really is a fantastic experience to work closely with so many UAV developers from all over the world.

I don't really have time to go through all the teams that attended, but I do want to mention some of the highlights for me. Top of the list would have to be meeting Ben and Daniel Dyer from team SFWA. They put in an absolutely incredible effort to build their own autopilot from scratch. Their build log at http://au.tono.my/log/index.html is incredible to read, and shows just what can be achieved in a short time with enough talent. It was fantastic that they completed the challenge (the first team to ever do so) and I look forward to seeing how they take their system forward.

I'd also like to offer a tip of the hat to Team Swiss Fang. They used the PX4 native stack on a Pixhawk and it was fantastic to see how far they pushed that autopilot stack in the lead up to the competition. That is one of the things that competitions like the OBC can do for an autopilot - push it to much higher levels.

Team OpenUAS also deserves a mention, and I was especially pleased to meet Christophe who is one of the key people behind the Paparrazzi autopilot. Paparrazzi is a real pioneer in the field of amateur autopilots. Many of the posts we make on "ardupilot has just achieved X" on diydrones could reasonably be responded to by saying "Paparrazzi did that 3 years ago". The OpenUAS team had bad luck in both the 2012 competition and again this year. This time round it was an airspeed sensor failure which led to a crash soon after takeoff which is really tragic given the effort they have put in and the pedigree of their autopilot stack.

The Robota team also did very well, coming in second behind our team. Particularly impressive was the performance of the Goose autopilot on a quite small foam plane in the wind over Kingaroy. The automatic landing was fantastic. The Robota team used a much simpler approach, just using a 2.4GHz Ubiquity link to send a digital video stream to 3 video monitors and having 3 people staring at those screens to find Joe. Extremely simple, but it worked. They were let down a bit by the drop accuracy in the wind, but a great effort done with style.

I was absolutely delighted when Team Thunder, who were also running APM:Plane, completed the challenge, coming in 4th place. They built their system partly on the image recognition code we had released, which is exactly what we hoped would happen. We want to see UAV developers building on each others work to make better and better systems, so having Team Thunder complete the mission was great.

Overall ardupilot really shone in the competition. Over half the teams that flew in the competition were running ardupilot. Our community has shown that we can put together systems that compete with the best in the world. We've come a long way in the last few years and I'm sure there is a bright future for more developments in the UAV S&R space that will see ardupilot saving lives on a regular basis.

Thank you

On behalf of CanberraUAV I'd like to offer a huge thank you to the OBC organisers for the massive effort they have put in over so many years to run the competition. Back in 2007 when the competition started it took real insight for Rod Walker and Jon Roberts to see that a competition of this nature could push amateur UAV technology ahead so much, and it took a massive amount of perseverance to keep it going to the point that teams were able to finally complete the competition. The OBC has had a huge impact on amateur UAV technology.

We'd also like to thank our sponsors, 3DRobotics, who have been a huge help for CanberraUAV. We really couldn't have done it without you. Working with 3DR on this sort of technology is a great pleasure.

Next steps

Completing the Outback Challenge isn't the end for CanberraUAV and we are already starting discussions on what we want to do next. I've posted some ideas on our mailing list and we would welcome suggestions from anyone who wants to take part. We've come a long way, but we're not yet at the point where putting together an effective S&R aircraft is easy.

The ardupilot development team is proud to announce the release of version 3.1.1 of APM:Plane. This is primarily a bugfix release with a small number of new features.

The main bug fixed in this release is a bug that could affect saving parameters and mission items in the FRAM/eeprom storage of PX4v1/Pixhawk/VRBrain. The bug has been in the code since January 2013 and did not cause problems very often (which is why it hasn't been noticed till now), but when it does happen it causes changes to parameters or mission items not to be saved on a reboot.

Other changes in this release:

• support for using a Lidar for landing for terrain altitude (see the RNGFND_LANDING parameter)
• improvements in the landing approach code, especially the glide slope calculation
• added LAND_FLAP_PERCENT and TKOFF_FLAP_PCNT parameters, to control the amount of flaps to use on takeoff and landing

• the default WP_RADIUS has been raised from 30 to 90. Note that the L1 controller may choose to turn after the WP_RADIUS is reached. The WP_RADIUS only controls the earliest point at which the turn can happen, so a larger WP_RADIUS usually leads to better flight paths, especially for faster aircraft.
• send gyro and accel status separately to the GCS (thanks to Randy)
• support setting the acceptance radius in mission waypoints (in parameter 2), which allows for better control of waypoints where actions such as servo release will happen
• fixed GPS time offset in HIL
• added RELAY_DEFAULT parameter, allowing control of relay state on boot
• fixed sdcard logging on PX4v1
• added GPS_SBAS_MODE and GPS_MIN_ELEV parameters for better control of the use of SBAS and the GPS elevation mask for advanced users

Happy flying!

Over the last couple of days I have been testing the Lidar based auto-landing code that will be in the upcoming 3.1.1 release of APM:Plane. I'm delighted to say that it has gone very well!

Testing has been done on two planes - one is a Meridian sports plane with a OS46 Nitro motor. That is a tricycle undercarriage, so has very easy ground steering. The tests today were with the larger VQ Porter 2.7m tail-dragger with a DLE-35 petrol motor. That has a lot of equipment on board for the CanberraUAV OBC entry, so it weighs 14kg at takeoff making it a much more difficult plane to land well.

The Lidar is a SF/02 from LightWare, a really nice laser rangefinder that works nicely with Pixhawk. It has a 40m range, which is great for landing, allowing the plane plenty of time to lock onto the glide slope in the landing approach.

APM:Plane has supported these Lidars and other rangefinders for a while, but until now has not been able to use them for landing. Instead they were just being logged to the microSD card, but not actively used. After some very useful discussions with Paul Riseborough we now have the Lidar properly integrated into the landing code.

The test flights today were an auto-takeoff (with automatic ground steering), a quick auto-circuit then an automatic landing. The first landing went long as I'd forgotten to drop THR_MIN down to zero (I normally have it at 20% to ensure the engine stays at a reasonable level during auto flight). After fixing that we got a series of good auto flights.

The flight was flown with a 4 second flare time, which is probably a bit long as it allowed the plane to lose too much speed on the final part of the flare. That is why it bounces a bit as it starts losing height. I'll try with a bit shorter flare time tomorrow.

Here is the video of one of the Meridian flights yesterday. Sorry for missing part of the flight, the video was shot with a cell phone by a friend at the field.

Here is another video of the Porter flying today, but taken from the north of the runway

I'd like to thank Charles Wannop from Flying Finish Productions for the video of the Porter today with help from Darrell Burkey.

The ardupilot development team is proud to announce the release of version 2.46 of APM:Rover. This is a major release with a lot of new features and bug fixes.

This release is based on a lot of development and testing that happened prior to the AVC competition where APM based vehicles performed very well.

Full changes list for this release:

• added support for higher baudrates on telemetry ports, to make it easier to use high rate telemetry to companion boards. Rates of up to 1.5MBit are now supported to companion boards.
• new Rangefinder code with support for a wider range of rangefinder types including a range of Lidars (thanks to Allyson Kreft)
• added logging of power status on Pixhawk
• added PIVOT_TURN_ANGLE parameter for pivot based turns on skid steering rovers
• lots of improvements to the EKF support for Rover, thanks to Paul Riseborough and testing from Tom Coyle. Using the EKF can greatly improve navigation accuracy for fast rovers. Enable with AHRS_EKF_USE=1.
• improved support for dual GPS on Pixhawk. Using a 2nd GPS can greatly improve performance when in an area with an obstructed view of the sky
• support for up to 14 RC channels on Pihxawk
• added BRAKING_PERCENT and BRAKING_SPEEDERR parameters for better breaking support when cornering
• added support for FrSky telemetry via SERIAL2_PROTOCOL parameter (thanks to Matthias Badaire)
• added support for Linux based autopilots, initially with the PXF BeagleBoneBlack cape and the Erle robotics board. Support for more boards is expected in future releases. Thanks to Victor, Sid and Anuj for their great work on the Linux port.
• added StorageManager library, which expands available FRAM storage on Pixhawk to 16 kByte. This allows for 724 waypoints on Pixhawk.
• improved reporting of magnetometer and barometer errors to the GCS
• fixed a bug in automatic flow control detection for serial ports in Pixhawk
• fixed use of FMU servo pins as digital inputs on Pixhawk
• imported latest updates for VRBrain boards (thanks to Emile Castelnuovo and Luca Micheletti)
• updates to the Piksi GPS support (thanks to Niels Joubert)
• improved gyro estimate in DCM (thanks to Jon Challinger)
• improved position projection in DCM in wind (thanks to Przemek Lekston)
• several updates to AP_NavEKF for more robust handling of errors (thanks to Paul Riseborough)
• lots of small code cleanups thanks to Daniel Frenzel
• initial support for NavIO board from Mikhail Avkhimenia
• fixed logging of RCOU for up to 12 channels (thanks to Emile Castelnuovo)
• code cleanups from Silvia Nunezrivero
• improved parameter download speed on radio links with no flow control

Many thanks to everyone who contributed to this release, especially Tom Coyle and Linus Penzlien for their excellent testing and feedback.

Happy driving!

The ardupilot development team is proud to announce the release of version 3.1.0 of APM:Plane. This is a major release with a lot of new features and bug fixes.

The biggest change in this release is the addition of automatic terrain following. Terrain following allows the autopilot to guide the aircraft over varying terrain at a constant height above the ground using an on-board terrain database. Uses include safer RTL, more accurate and easier photo mapping and much easier mission planning in hilly areas.

There have also been a lot of updates to auto takeoff, especially for tail dragger aircraft. It is now much easier to get the steering right for a tail dragger on takeoff.

Another big change is the support of Linux based autopilots, starting with the PXF cape for the BeagleBoneBlack and the Erle robotics autopilot.

Full list of changes in this release

• added terrain following support. See http://plane.ardupilot.com/wiki/common- ... following/
• added support for higher baudrates on telemetry ports, to make it easier to use high rate telemetry to companion boards. Rates of up to 1.5MBit are now supported to companion boards.

• added new takeoff code, including new parameters TKOFF_TDRAG_ELEV, TKOFF_TDRAG_SPD1, TKOFF_ROTATE_SPD, TKOFF_THR_SLEW and TKOFF_THR_MAX. This gives fine grained control of auto takeoff for tail dragger aircraft.
• overhauled glide slope code to fix glide slope handling in many situations. This makes transitions between different altitudes much smoother.
• prevent early waypoint completion for straight ahead waypoints. This makes for more accurate servo release at specific locations, for applications such as dropping water bottles.
• added MAV_CMD_DO_INVERTED_FLIGHT command in missions, to change from normal to inverted flight in AUTO (thanks to Philip Rowse for testing of this feature).
• new Rangefinder code with support for a wider range of rangefinder types including a range of Lidars (thanks to Allyson Kreft)
• added support for FrSky telemetry via SERIAL2_PROTOCOL parameter (thanks to Matthias Badaire)
  added new STAB_PITCH_DOWN parameter to improve low throttle behaviour in FBWA mode, making a stall less likely in FBWA mode (thanks to Jack Pittar for the idea).
• added GLIDE_SLOPE_MIN parameter for better handling of small altitude deviations in AUTO. This makes for more accurate altitude tracking in AUTO.
• added support for Linux based autopilots, initially with the PXF BeagleBoneBlack cape and the Erle robotics board. Support for more boards is expected in future releases. Thanks to Victor, Sid and Anuj for their great work on the Linux port. See http://diydrones.com/profiles/blogs/fir ... t-on-linux for details.
• prevent cross-tracking on some waypoint types, such as when initially entering AUTO or when the user commands a change of target waypoint.
• fixed servo demo on startup (thanks to Klrill-ka)
• added AFS (Advanced Failsafe) support on 32 bit boards by default. See http://plane.ardupilot.com/wiki/advance ... iguration/
• added support for monitoring voltage of a 2nd battery via BATTERY2 MAVLink message
• added airspeed sensor support in HIL
• fixed HIL on APM2. HIL should now work again on all boards.
• added StorageManager library, which expands available FRAM storage on Pixhawk to 16 kByte. This allows for 724 waypoints, 50 rally points and 84 fence points on Pixhawk.
• improved steering on landing, so the plane is actively steered right through the landing.
• improved reporting of magnetometer and barometer errors to the GCS
• added FBWA_TDRAG_CHAN parameter, for easier FBWA takeoffs of tail draggers, and better testing of steering tuning for auto takeoff.
• fixed failsafe pass through with no RC input (thanks to Klrill-ka)
• fixed a bug in automatic flow control detection for serial ports in Pixhawk
• fixed use of FMU servo pins as digital inputs on Pixhawk
• imported latest updates for VRBrain boards (thanks to Emile Castelnuovo and Luca Micheletti)
• updates to the Piksi GPS support (thanks to Niels Joubert)
• improved gyro estimate in DCM (thanks to Jon Challinger)
• improved position projection in DCM in wind (thanks to Przemek Lekston)
• several updates to AP_NavEKF for more robust handling of errors (thanks to Paul Riseborough)
• improved simulation of rangefinders in SITL
• lots of small code cleanups thanks to Daniel Frenzel
• initial support for NavIO board from Mikhail Avkhimenia
• fixed logging of RCOU for up to 12 channels (thanks to Emile Castelnuovo)
• code cleanups from Silvia Nunezrivero
• improved parameter download speed on radio links with no flow control

Many thanks to everyone who contributed to this release, especially our beta testers Marco, Paul, Philip and Iam.

Happy flying!

I'm delighted to announce that the effort to port ArduPilot to Linux reached an important milestone yesterday with the first flight of a fixed wing aircraft on a Linux based autopilot running ArduPilot.

As I mentioned in a previous blog post, we've been working on porting ArduPilot to Linux for a while now. There are lots of reasons for wanting to do this port, not least of which is that it is an interesting challenge!

For the test flight yesterday I used a PXF cape which is an add-on to a BeagleBoneBlack board which was designed by Philip Rowse from 3DRobotics. The PXF cape was designed as a development test platform for Linux based autopilots, and includes a rich array of sensors. It has 3 IMUs (a MPU6000, a MPU9250 and a LSM9DSO), plus two barometers (MS5611 on SPI and I2C), 3 I2C connectors for things like magnetometers and airspeed sensors plus a pile of UARTs, analog ports etc.

All of this sits on top of a BeagleBoneBlack, which is a widely used embedded Linux board with 512M ram, a 1GHz ARM CPU and 2 GByte of EMMC for storage. We're running the Debian Linux distribution on the BeagleBoneBlack, with a 3.8.13-PREEMPT kernel. The BBB also has a two nice co-processors called PRUs (programmable realtime units) which are ideal for timing critical tasks. In the flight yesterday we used one PRU for capturing PPM-SUM input from a R/C receiver, and the other PRU for PWM output to the aircrafts servos.

Summer of code project

The effort to port ArduPilot to Linux got a big boost a few months ago when we teamed up with Victor, Sid and Anuj from the BeaglePilot project as part of a Google Summer of Code project. Victor was sponsored by GSoC, while Sid and Anuj were sponsored as summer students in 3DRobotics. Together they have put a huge amount of effort in over the last few months, which culminated in the flight yesterday. The timing was perfect, as yesterday was also the day that student evaluations were due for the GSoc!

PXF on a SkyWalker

For the flight yesterday I used a 3DR SkyWalker, with the BBB+PXF replacing the usual Pixhawk. Because the port of ArduPilot to Linux used the AP_HAL hardware abstraction layer all of the hardware specific code is abstracted below the flight code, which meant I was able to fly the SkyWalker with exactly the same parameters loaded as I have previously used with the Pixhawk on the same plane.

For this flight we didn't use all of the sensors on the PXF however. Some issues with the build of the initial test boards meant that only the MPU9250 was fully functional, but that was quite sufficient. Future revisions of the PXF will fix up the other two IMUs, allowing us to gain the advantages of multiple IMUs (specifically it gains considerable robustness to accelerometer aliasing).

I also had a digital airspeed sensor (on I2C) and an external GPS/Compass combo to give the full set of sensors needed for good fixed wing flight.

Debugging at the field

As with any experimental hardware you have to expect some issues, and the PXF indeed showed up a problem when I arrived at the flying field. At home I don't get GPS lock due to my metal roof so I hadn't done much testing of the GPS and when I was doing pre-flight ground testing yesterday I found that I frequently lost the GPS. With a bit of work using valgrind and gdb I found the bug, and the GPS started to work correctly. It was an interesting bug in the UART layer in AP_HAL_Linux which also may affect the AP_HAL_PX4 code used on a Pixhawk (although with much more subtle effect), so it was an important fix, and really shows the development benefit of testing on multiple platforms.

After that issue was fixed the SkyWalker was launched, and as expected it flew perfectly, exactly as it would fly with any other ArduPilot based autopilot. There was quite a strong wind (about 15 knots, gusting to 20) which was a challenge for such a small foam plane, but it handled it nicely.

Lots more photos of the first flight are available here. Thanks to Darrell Burkey for braving a cold Canberra morning to come out and take some photos!

Next Steps

Now that we have ArduPilot on PXF flying nicely the next step is a test flight with a multi-copter (I'll probably use an Iris). I'm also looking forward to hearing about first flight reports from other groups working on porting ArduPilot to other Linux based boards, such as the NavIO.

This projects follows in the footsteps of quite a few existing autopilots that run on Linux, both open source and proprietary, including such well known projects as Paparrazi, the AR-Drone and many research autopilots at universities around the world. Having the abiity to run ArduPilot on Linux opens up some interesting possibilities for the ArduPilot project, including things like ROS integration, tightly integrated SLAM and lots of computationally intensive vision algorithms. I'm really looking forward to ArduPilot on Linux being widely available for everyone to try.

All of the code needed to fly ArduPilot on Linux is in the standard ArduPilot git repository.

Thanks

Many thanks to 3DRobotics for sponsoring the development of the PXF cape, and to Victor, Sid and Anuj for their efforts over the last few months! Special thanks to Philip Rowse for designing the board, and for putting up with lots of questions as we worked on the port, and to Craig Elder and Jeff Wurzbach for providing engineering support from the 3DR US offices.

In preparation for the upcoming APM:Plane 3.1.0 release I thought it would be useful to showcase some of the new features that have been added.

The biggest new feature in this release is automatic terrain following. That is something I have wanted to add for a long time, and it is now finally done, prompted by the need for better terrain following for the upcoming Outback Challenge 2014 competition.

How it works

Terrain following works by maintaining a terrain database on the microSD card on the autopilot which gives the terrain height in meters above sea level for a grid of geographic locations. On the Pixhawk this database is stored in the APM\TERRAIN directory on the microSD card. Unfortunately code side limitations and the lack of a microSD card mean terrain following is not available for the APM1 or APM2.

The terrain database is populated automatically by the autopilot requesting terrain data from the ground station over a MAVLink telemetry link. This can happen either during flight planning when the autopilot is connected over USB, or during flight when connected over a radio link. Once the terrain data is sent from the GCS to the autopilot it is stored on the microSD card so that it is available even when the GCS is not connected. This makes it possible for the autopilot to use terrain data to perform a terrain following RTL (Return To Launch) even when it is not able to talk to the ground station.

During flight the ardupilot code automatically reads in the needed terrain data from the microSD card into memory as the aircraft approaches a new area. It maintains an area of about 7km by 8km in memory if the default terrain grid spacing is used.

In addition to any terrain data for the immediate vicinity of the aircraft, ardupilot also asks the ground station for terrain data for any mission waypoints which are loaded, and for any rally points which are loaded. This ensures that terrain data is available on the microSD card for a whole mission even if the GCS becomes unavailable.

Terrain Following Flight Modes

In APM:Plane terrain following is available in the following flight modes:

• RTL – Return to launch
• LOITER – circle a point
• CRUISE – long distance cruising
• FBWB – speed/height maintenance
• GUIDED – “fly to” waypoints
• AUTO – fully autonomous missions

Use of terrain following in RTL, LOITER, CRUISE, FBWB and GUIDED modes is controlled by the TERRAIN_FOLLOW parameter. That parameter defaults to off, so no terrain following will be used in those modes by default. Set TERRAIN_FOLLOW to 1 to enable terrain following in those modes.

Use of terrain following in AUTO missions is controlled on a waypoint by waypoint basis using the reference frame of the waypoint. Normal (non terrain following) waypoints have a “Relative” reference frame, and altitudes are specified relative to the home location. Terrain following waypoints have a “Terrain” reference frame, and altitudes are relative to the ground level given in the terrain database.

Terrain Following in CRUISE mode

CRUISE mode is a flight mode which is designed for long distance flying, especially for things like FPV. When you enable terrain following with the TERRAIN_FOLLOW=1 parameter CRUISE mode will hold an altitude above the terrain rather than a barometric altitude. This allows easier flying at a set AGL altitude which makes terrain avoidance easier, and also makes it easier to stay within regulatory altitude limits.

Terrain Following in RTL mode

When you engage RTL (either as a flight mode or as a failsafe) the plane flies back to either the home location or the closest rally point. If you have TERRAIN_FOLLOW=1 then the plane will follow the contours of the terrain on the way to the RTL location, which makes RTL much safer in hilly areas.

Uses of Terrain Following

Terrain following is very useful when flying ardupilot in areas where the terrain may vary significantly. Key uses are:

• Safe RTL. Being able to come over a hill rather than trying to fly through it when you enter RTL in a hilly area is very useful!
• Aerial Photography. It is useful to be able to maintain a constant altitude over the ground when taking a sequence of aerial photos
• FPV flying. When flying FPV in CRUISE mode it is useful to maintain constant height above the ground so you can spend more time enjoying the scenery and less time avoiding hills

Sources of terrain data

The ground station is responsible for providing the raw terrain data which is sent to the aircraft via MAVLink. Right now only MissionPlanner (beta version as of 6th August 2014) and MAVProxy support the required TERRAIN_DATA and TERRAIN_REQUEST messages needed for terrain following support. If you are using a different ground station then to load terrain data you will need to connect using one of the two supported ground stations to allow ardupilot to load terrain data onto your board. It typically takes around 2 minutes to load all the terrain data for a mission. Once it is loaded it is saved permanently on the microSD card.

Both MissionPlanner and MAVProxy support the global SRTM database for terrain data. That database has a global grid spacing of 3 arc-seconds (around 100 meters), but has a smaller grid spacing in some parts of the world (around 30 meters in the US). Support for other terrain databases can be added by extending the ground station code without changes to the ardupilot code.

Terrain Spacing

The ardupilot terrain code has a user settable parameter called TERRAIN_SPACING which controls the grid spacing which is used for requests for terrain data from the aircraft to the ground station. The default TERRAIN_SPACING is 100 meters, but users may set a different grid spacing for specialist applications. When ardupilot uses the terrain data it interpolates between grid points.

The amount of terrain data kept in memory is directly related to the grid spacing. If you decrease the TERRAIN_SPACING by a factor of 2 then the amount of terrain area kept in memory is reduced by a factor of 4. It is recommended that you use a TERRAIN_SPACING of at least 30 meters to prevent the aircraft running off the side of a grid in flight and not having data available.

If the ground station does not have terrain data available at the resolution requested by the aircraft then the ground station will interpolate as necessary to provide the requested grid size.

Terrain Accuracy

The accuracy of the SRTM database varies over the surface of the earth. Typical accuracy is around 10 to 20 meters, although some areas are worse. This makes terrain following suitable for aircraft that are flying at altitudes of 60 meters or more. Using terrain data for low flights is not recommended.

Setting up for terrain following

To setup your fixed wing aircraft for terrain following follow these steps

• make sure you have APM:Plane 3.1.0 or later loaded
• make sure you have the latest MissionPlanner installed (latest beta version as of August 2014)
• set TERRAIN_ENABLE to 1 and TERRAIN_FOLLOW to 1
• connect to your vehicle over USB when you have GPS lock
• check the FlightData->Status page in MissionPlanner and look for the terrain status data:

When the autopilot has finished loading terrain data you should see “ter_pend” goes to zero and the current terrain altitude in meters showing up in “ter_alt”. The “ter_pend” value is the number of terrain blocks that the autopilot is waiting to load from the ground station.

Terrain Lookahead

The terrain following code “looks ahead” of the current position along the flight path to try to ensure that the aircraft climbs soon enough to avoid upcoming terrain. The amount of lookahead is controlled by the TERRAIN_LOOKAHD parameter, which defaults to 2000 meters. The lookahead is also limited by the distance to the next waypoint in AUTO mode, so you need to ensure that you don’t have any legs of your mission which include climb rates your aircraft cannot achieve.

The climb rate used in the terrain look ahead is based on the TECS_MAX_CLIMB parameter, combined with your current ground speed.

Give it a try!

If you like the sound of terrain following then please give it a try! I've just released a 3.1.0-beta1 release that you can try now. Please let me know how it goes!

Please report bugs on the ardupilot forum

• fixed a glide slope calculation error when very close to waypoints
• fixed a bug when swithing to another auto-throttle mode during auto takeoff (thanks to Marco for finding this bug!)
• added MIS_AUTORESET parameter (thanks to Andrew Chapman)
• support compassmot calibration by supplying current measurments to the compass driver (thanks to Jon Challinger)
• fixed a GPS driver bug that could cause GPS lag in case of lost GPS samples (thanks to Jon Challinger)
• fixed a LOITER_TURNS bug in missions for counter-clockwise loiter (thanks to Iskess for finding this bug)
• added support for OBC termination requirements to PX4IO
• added support for pressure altitude termination to OBC module
• fixed EKF wind estimation with no airspeed sensor (thanks to Paul Riseborough)
• improved tuning of EKF for fixed wing aircraft (thanks to Paul Riseborough)
• Converted rally point code to library AP_Rally (thanks to Andrew Chapman
• added SITL checking for numerical errors

Hi Paul,

I don't know if you know me. I'm a lead developer for the ardupilot project. You know, the project that you just accused of not being open source in an interview on http://thecrashcast.com/. I write about half the code for the project, so maybe you've heard of me.

If you've been following my work for the last 4 years on ardupilot then you would know that I'm generally a pretty mild mannered person. I try to keep my posts polite and helpful, to generally raise the tone of diydrones and open source projects in general.

Well, you better don your asbestos suit now, because I also have a rarely seen darker side. Just occasionally someone does something that pisses me off so much that I get really really annoyed. Your recent actions have done that, so here comes a flaming.

Some background

A real flaming doesn't generally come with a background introduction, but hey, I still have a mild side too (despite the fact that I am seething with anger at you right now), so why not.

I'm a long time open source developer. I started contributing to open source in the late 80s. There is a good chance that when you read this letter the bits are getting to you via computers running open source code that I've contributed to. On the wall behind me is a Free Software Foundation award for the advancement of free software. I teach a masters course on how to build and contribute to open source projects. I'm not an open source newbie. Perhaps you should have checked before making outlandish claims about ardupilot, a project that I've put my heart and sole into for so long?

I've been working on ardupilot for 3 and a half years now. In that time I've contributed over 5000 patches to the project. Given your amazing statements on the crashcast podcast and on your website about you being a defender of open source I expected to see your name in the contribution list. Strangely enough, it's not there. Did you use a pseudonym in all the contributions you have made or did you just accuse a project that you have no association with of not being open source?

How Open Source Works

As I describe in my course, open source is different for different people. Me, I'm a free software radical. I like everything I do to be FOSS (free and open source software). If I can't do something with FOSS then I see if I can write a FOSS tool to do it, then distribute it to the world. As a result I've started about 30 FOSS projects over the years and contributed to dozens more. I'm such a radical that many people in the FOSS world (including Linus Torvalds) have accused me of being too radical, and pushing the "free software or death" line too hard.

One of the big misunderstandings about open source is the insane and self-serving idea you have been pushing that the ardupilot project is somehow required, because of open source principles that you somehow fail to explain, to provide your company with binaries of our software that work on your board. That is utter and complete drivel and rubbish. You're wrapping yourself up in the open source flag while not even having the faintest idea of how open source works.

Open source project leaders can choose which hardware they support. As a lead developer of the ardupilot project I have chosen to try to make the code work on as many boards as possible. So in fact the firmware.diydrones.com site (which I maintain) does provide firmware that will probably work on your RTFHawk boards. I've also worked with people who want to port ardupilot to completely new hardware platforms. Did you notice I merged in support for Flymaple boards a few months back? Did you notice I merged in support for the VRBrain too? Did you notice the work I've been doing on porting ardupilot to the BeagleBone?

I'm guessing you didn't notice any of that or you wouldn't be making such grandiose and idiotic claims about ardupilot not being an open project.

So here's the deal. Open source project leaders get to choose what code they accept, what code they write and how the projects get managed. Really basic stuff really. I have chosen to make ardupilot widely portable and flexible, but I didn't have to. It would still be open source if I wrote the code to only work on one brand of board.

Michael Oborne is the project leader of the MissionPlanner project. He has done an awesome job building up MissionPlanner from scratch, and making it a GCS that people love to use. As the project leader for MissionPlanner he gets to set the policy. If he wants it to only load firmware to only blue boards with pink edging that have butterflies embossed on the PCB then that would be his right. I might give him some odd looks if he did that, but I'd defend his right to do it.

Because MissionPlanner is an open source project you can make it do something different if you like. If you don't like what it does then why not try something really radical like talking to him (you _did_ talk to him before accusing him of heinous crimes against the open source world? right? yes?). Hey, you could even send him a patch! Now there is a radical idea. If that fails then you could fork MissionPlanner and make it do what you want it to do. That is the fundamental succinct definition of open source after all - the right to fork. You have that right, even if perhaps you don't deserve it after all you've said in recent days.

Why do we work closely with 3DR?

If I were to believe the crap you said on that podcast then it would seem that I'm held hostage by 3DRobotics. Help, I'm an open source developer being supported by a hardware company that uses my software. Oh no!! Help me get out!!

The fact is the ardupilot developers work closely with 3DRobotics because it benefits the project. Think about that. We choose to work with them because working with them advances the aim of producing the most awesome free software autopilot that we can.

I regularly get asked by Craig Elder from 3DRobotics if there is anything he can send me to help me with my work on ardupilot. If I say "well, I fried my last Pixhawk while testing the power handling to its limits" then he pops a couple of new ones in a fedex pouch and sends it down to me in Australia. It's great!

They even pay me! I get 100% copyright on all the work I do, I get complete discretion on what code I put in and I get paid to do it. Yep, open source developers can get paid!

In fact, most large open source projects have lots of paid developers. Ever heard of the Linux kernel? Last I heard about 80% of the code is written by people who work for hardware companies that benefit from the project. This is normal. I've been paid to develop open source software by numerous companies for 20 years.

The main difference with 3DRobotics is that they are one of very few companies who have been enlightened enough to pay the ardupilot core developers. In the case of Linux there are hundreds of companies that have understood open source enough to pay the core developers. Chris Anderson from 3DRobotics saw that pitching in money to pay the people who have been working on ardupilot for so long is a good thing both for the ardupilot project and for 3DRobotics, so he did it. Now you throw that back at him and try to use it to accuse him and 3DRobotics of being some evil company perverting open source. What sort of insane logic does that stem from?

I looked in my letter box today and I didn't see any hardware from you. I bet if I talk to all the other ardupilot devs they would tell me you didn't send any hardware to them either. I haven't seen any code from you. Yet you get up on your high horse and try to claim that we owe you something? Please just crawl back into the hole you came from.

That OTP thing

The thing you have built your edifice of open source outrage on is the way that MissionPlanner checks the OTP area of Pixhawk boards and doesn't load firmware unless they match a particular public key. I have stated publicly that I don't like that behaviour. I have also made it clear that it is Michael's decision as project leader for MissionPlanner.
I have been working with other developers to try to come up with a better solution. That is how things are done in the open source world. Contributors to projects tell the project leader if they don't like something the project does and the project leader takes their ideas into consideration. Ultimately the project leader (Michael in this case) gets to choose.

So we agree?

You might think that because I also don't like the current OTP mechanism that we are in agreement. We are not. I wouldn't be flaming you in such a long winded fashion if I agreed with you.

You are taking advantage of the OTP behaviour for your own ends, and those ends have absolutely nothing to do with protecting open source.

Let's have a quick look at your actual behaviour with regards to open source and your RTFHawk project. Given your rabid defence of open source I presume you've read the license of the projects you are criticising so loudly? It's the GNU GPLv3. I happened to be on a committee that helped develop that license, so maybe you don't know it quite as well as I do. Here is a refresher. When you distribute binaries that are built from source code that is under the GPLv3 you need to (among other things) do the following:

• make the recipients of the binaries aware of their rights under the GPL. Have a look at firmware.diydrones.com for how we do that
• offer the source code to anyone who asks for it (which is why making them aware of this is so important)

So, let's see. On your website you have a binary copy of MissionPlanner modified to upload firmware to your board. Do you tell people who go there that it's GPLv3 software? Do you link to the source code? Do you offer the patches you've done? Nope, nope and nope.

What is more, you are wrapping yourself in an open source flag and trying to use that flag to sell your clone boards. You do this by criticising 3DRobtotics, a company that has done more for open source autopilots than any other company I know of. You are doing this as a company that has, as far as I am aware, done absolutely zero to benefit the ardupilot project or MissionPlanner that you are criticising.

So what now?

First off, go read up on open source. Read some of ESRs essays. Read the FSF site.

Then go away. One of the things a open source project can do is ignore people who really piss them off. You have really pissed me off. I would not accept a patch from you in future, even if you ever could be bothered to get off your ass and make a real contribution.

I will accept patches from other hardware vendors, and I look forward to working with other hardware vendors who make boards that run ardupilot, just like I have done ever since I got involved in this project. I love working with any hardware vendors who make great autopilots and who want to work with the project. I will do it regardless of whether they contribute money or hardware, because I love to see the platform grow. I won't however work with you because you have decided to start off the relationship between your company and the ardupilot project by insulting it and using those insults to further your own aims. So congratulations, you are the first company that I have banned from working with the ardupilot project, or at least working with me on it. Maybe you'd like to put that on your website?

Time to get some sleep.

The ardupilot development team is proud to announce the release of version 3.0.0 of APM:Plane. This is a major release with a lot of new features.

For each release I try to highlight the two or 3 key new features that have gone in since the last release. That is a more difficult task this time around because there are just so many new things. Still, I think the most important ones are the new Extended Kalman Filter (EKF) for attitude/position estimation, the extensive dual sensors support and the new AP_Mission library.

We have also managed to still keep support for the APM1 and APM2, although quite a few of the new features are not available on those boards. We don't yet know for how long we'll be able to keep going on supporting these old boards, so if you are thinking of getting a new board then you should get a Pixhawk, and if you want the best performance from the APM:Plane code then you should swap to a Pixhawk now. It really is a big improvement.

New Extended Kalman Filter

The biggest change for the 3.0.0 release (and in fact the major reason why we are calling it 3.0.0) is the new Extended Kalman Filter from Paul Riseborough. Using an EKF for attitude and position estimation was never an option on the APM2 as it didn't have the CPU power or memory to handle it. The Pixhawk does have plenty of floating point performance, and Paul has done a fantastic job of taking full advantage of the faster board.

As this is the first stable release with the EKF code we have decided to not enable it by default. It does however run all the time in parallel with the existing DCM code, and both attitude/position solutions are logged both to the on-board SD card and over MAVLink. You can enable the EKF code using the parameter AHRS_EKF_USE=1, which can be set and unset while flying, allowing you to experiment with using the EKF either by examining your logs with the EKF disabled to see how it would have done or by enabling it while flying.

The main thing you will notice with the EKF enabled is more accurate attitude estimation and better handling of sensor glitches. A Kalman filter has an internal estimate of the reliability of each of its sensor inputs, and is able to weight them accordingly. This means that if your accelerometers start giving data that is inconsistent with your other sensors then it can cope in a much more graceful way than our old DCM code.

The result is more accurate flying, particularly in turns. It also makes it possible to use higher tuning gains, as the increased accuracy of the attitude estimation means that you can push the airframe harder without it becoming unstable. You may find you can use a smaller value for NAVL1_PERIOD, giving tighter turns, and higher gains on your roll and pitch attitude controllers.

Paul has written up a more technical description of the new EKF code here:

http://plane.ardupilot.com/wiki/common-apm-navigation-extended-kalman-filter-overview/

Dual Sensors

The second really big change for this release is support for dual-sensors. We now take full advantage of the dual accelerometers and dual gyros in the Pixhawk, and can use dual-GPS for GPS failover. We already had dual compass support, so the only main sensors we don't support two of now are the barometer and the airspeed sensor. I fully expect we will support dual baro and dual airspeed in a future release.

You might wonder why dual sensors is useful, so let me give you an example. I fly a lot of nitro and petrol planes, and one of my planes (a BigStik 60) had a strange problem where it would be flying perfectly in AUTO mode, then when the throttle reached a very specific level the pitch solution would go crazy (sometimes off by 90 degrees). I managed to recover in MANUAL each time, but it certainly was exciting!

A careful analysis of the logs showed that the culprit was accelerometer aliasing. At a very specific throttle level the Z
accelerometer got a DC offset of 11 m/s/s. So when the plane was flying along nice and level the Z accelerometer would change from -10 m/s/s to +1 m/s/s. That resulted in massive errors in the attitude solution.

This sort of error happens because of the way the accelerometer is sampled. In the APM code the MPU6000 (used on both the APM2 and Pixhawk) samples the acceleration at 1kHz. So if you have a strong vibrational mode that is right on 1kHz then you are sampling the "top of the sine wave", and get a DC offset.

The normal way to fix this issue is to improve the physical anti-vibration mounting in the aircraft, but I don't like to fix
problems like this by making changes to my aircraft, as if I fix my aircraft it does nothing for the thousands of other people running the same code. As the lead APM developer I instead like to fix things in software, so that everyone benefits.

The solution was to take advantage of the fact that the Pixhawk has two accelerometers, one is a MPU6000, and the 2nd is a LSM303D. The LSM303D is sampled at 800Hz, whereas the MPU6000 is sampled at 1kHz. It would be extremely unusual to have a vibration mode with aliasing at both frequencies at once, which means that all we needed
to do was work out which accelerometer is accurate at any point in time. For the DCM code that involved matching each accelerometer at each time step to the combination of the GPS velocity vector and current attitude, and for the EKF it was a matter of producing a weighting for the two accelerometers based on the covariance matrix.

The result is that the plane flew perfectly with the new dual accelerometer code, automatically switching between accelerometers as aliasing occurred.

Since adding that code I have been on the lookout for signs of aliasing in other logs that people send me, and it looks like it is more common than we expected. It is rarely so dramatic as seen on my BigStik, but often results in some pitch error in turns. I am hopeful that with a Pixhawk and the 3.0 release of APM:Plane that these types of problems will now be greatly reduced.

For the dual gyro support we went with a much simpler solution and just average the two gyros when both are healthy. That reduces noise, and works well, but doesn't produce the dramatic improvements that the dual accelerometer code resulted in.

Dual GPS was also quite a large development effort. We now support connecting a 2nd GPS to the serial4/5 port on the Pixhawk. This allows you to protect against GPS glitches, and has also allowed us to get a lot of logs showing that even with two identical GPS modules it is quite common for one of the GPS modules to get a significant error
during a flight. The new code currently switches between the two GPS modules based on the lock status and number of satellites, but we are working on a more sophisticated switching mechanism.

Supporting dual GPS has also made it easier to test new GPS modules. This has enabled us to do more direct comparisons between the Lea6 and the Neo7 for example, and found the Neo7 performs very well. It also helps with developing completely new GPS drivers, such as the Piksi driver (see notes below).

New AP_Mission library

Many months ago Brandon Jones re-worked our mission handling code to be a library, making it much cleaner and fixing a number of long term annoyances with the behaviour. For this release Randy built upon the work that Brandon did and created the new AP_Mission library.

The main feature of this library from the point of view of the developers is that it has a much cleaner interface, but it also has some new user-visible features. The one that many users will be glad to hear is that it no longer needs a "dummy waypoint" after a jump. That was always an annoyance when creating complex missions.

The real advantage of AP_Mission will come in future releases though, as it has the ability to look ahead in the mission to see what is coming, allowing for more sophisticated navigation. The copter code already takes advantage of this with the new spline waypoint feature, and we expect to take similar advantage of this in APM:Plane in future releases.

New Piksi GPS driver

One of the most exciting things to happen in the world of GPS modules in the last couple of years is the announcement by SwiftNav that they would be producing a RTK capable GPS module called the Piksi at a price that (while certainly expensive!) is within reach of more dedicated hobbyists. It offers the possibility of decimeter and possibly even centimetre level relative positioning, which has a lot of potential for small aircraft, particularly for landing control and more precise aerial mapping.

This release of APM:Plane has the first driver for the Piksi. The new driver is written by Niels Joubert, and he has done a great job. It is only a start though, as this is a single point positioning driver. It will allow you to use your new Piksi if you were part of the kickstarter, but it doesn't yet let you use it in RTK mode. Niels and the SwiftNav team are working on a full RTK driver which we hope will be in the next release.

Support for more RC channels

This release is the first to allow use of more than 8 RC input channels. We now support up to 18 input channels on  SBus on Pixhawk, with up to 14 of them able to be assigned to functions using the RCn_FUNCTION settings. For my own flying I now use a FrSky Taranis with X8R and X6R receivers and they work very nicely. Many thanks to the PX4 team, and especially to Holger and Lorenz for their great work on improving the SBus code.

Flaperon Support

This release is the first to have integrated flaperon support, and also includes much improved flaps support in general. You can now set a FLAP_IN_CHANNEL parameter to give an RC channel for manual flap control, and setup a  FLAPERON_OUTPUT to allow you to setup your ailerons for both manual and automatic flaperon control.

We don't yet have a full wiki page on setting up flaperons, but you can read about the parameters here:

http://plane.ardupilot.com/wiki/arduplane-parameters/#Flap_input_channel_ArduPlaneFLAP_IN_CHANNEL

Geofence improvements

Michael Day has made an number of significant improvements to the geo-fencing support for this release. It is now possible to enable/disable the geofence via MAVLink, allowing ground stations to control the fence.

There are also three new fence control parameters. One is FENCE_RET_RALLY which when enabled tells APM to fly back to the closest rally point on a fence breach, instead of flying to the centre of the fence area. That can be very useful for more precise control of fence breach handling.

The second new parameter is FENCE_AUTOENABLE, which allows you to automatically enable a geofence on takeoff, and disable when doing an automatic landing. That is very useful for fully automated missions.

The third new geofence parameter is FENCE_RETALT, which allows you to specify a return altitude on fence breach. This can be used to override the default (half way between min and max fence altitude).

Automatic Landing improvements

Michael has also been busy on the automatic landing code, with improvements to the TECS speed/height control when landing and new TECS_LAND_ARSPD and TECS_LAND_THR parameters to control airspeed and throttle when landing. This is much simpler to setup than DO_CHANGE_SPEED commands in a mission.

Michael is also working on automatic path planning for landing, based on the rally points code. We hope that will get into a release soon.

Detailed Pixhawk Power Logging

One of the most common causes of issues with autopilots is power handling, with poor power supplies leading to brownouts or sensor malfunction. For this release we have enabled detailed logging of the information available from the on-board power management system of the Pixhawk, allowing us to log the status of 3 different power sources (brick input, servo rail and USB) and log the voltage level of the servo rail separately from the 5v peripheral rail on the FMU.

This new logging should make it much easier for us to diagnose power issues that users may run into.

New SERIAL_CONTROL protocol

This release adds a new SERIAL_CONTROL MAVLink message which makes it possible to remotely control a serial port on a Pixhawk from a ground station. This makes it possible to do things like upgrade the firmware on a 3DR radio without removing it from an aircraft, and will also make it possible to attach to and control a GPS without removing it from the plane.

There is still work to be done in the ground station code to take full advantage of this new feature and we hope to provide documentation soon on how to use u-Blox uCenter to talk to and configure a GPS in an aircraft and to offer an easy 3DR radio upgrade button via the Pixhawk USB port.

Lots of other changes!

There have been a lot of other improvements in the code, but to stop this turning into a book instead of a set of release notes I'll stop the detailed description there. Instead here is a list of the more important changes not mentioned above:

• added LOG_WHEN_DISARMED flag in LOG_BITMASK
• raised default LIM_PITCH_MAX to 20 degrees
• support a separate steering channel from the rudder channel
• faster mission upload on USB
• new mavlink API for reduced memory usage
• fixes for the APM_OBC Outback Challenge module
• fixed accelerometer launch detection with no airspeed sensor
• greatly improved UART flow control on Pixhawk
• added BRD_SAFETYENABLE option to auto-enable the safety switch on PX4 and Pixhawk on boot
• fixed pitot tube ordering bug and added ARSPD_TUBE_ORDER parameter
• fixed log corruption bug on PX4 and Pixhawk
• fixed repeated log download bug on PX4 and Pixhawk
• new Replay tool for detailed log replay and analysis
• flymaple updates from Mike McCauley
• fixed zero logs display in MAVLink log download
• fixed norm_input for cruise mode attitude control
• added RADIO_STATUS logging in aircraft logs
• added UBX monitor messages for detailed hardware logging of u-Blox status
• added MS4525 I2C airspeed sensor voltage compensation

I hope that everyone enjoys flying this new APM:Plane release as much as we enjoyed producing it! It is a major milestone in the development of the fixed wing code for APM, and I think puts us in a great position for future development.

Happy flying!

At the recent LCA'2014 conference in Perth I gave a couple of talks about research projects I'm working on with ardupilot. These show a couple of the things that we are working towards with APM.

The first is a talk on differential GPS which is part of a collaboration between Ben Nizette at ANU and myself.

Video:

https://www.youtube.com/watch?v=sl8aJlG52PE

Slides: http://uav.tridgell.net/LCA2014/dgps.pdf

The second talk is about the research project to run ardupilot directly on embedded Linux boards, which opens up some really interesting possibilities for APM:

Video:

https://www.youtube.com/watch?v=ealH3qP_pBE

Slides: http://uav.tridgell.net/LCA2014/AP_Linux.pdf

These projects are really just a small part of what we are working on, but I thought a few people might be interested in them.

Cheers, Tridge

I've just released APM:Plane 2.78

This is a bug fix release for a number of important issues found in the 2.77 release. 

The changes in this release are
Fixed sensor start-up on the APM1
I'm embarrassed to say that I didn't test the APM1 for the 2.77 release as my APM1 had died. It was a trivial fix, and the APM1 is working again in 2.78
Pixhawk Barometer fix
Fixed a potentially serious bug on Pixhawk if the board is flown in high temperature environments. If the board temperature gets above 65 degrees C then some boards would get bad barometric readings, thus giving bad altitude readings. This fix was a change in the GPIO settings on the SPI bus used to talk to the MS5611 barometer. Many thanks to Darrell Burkey for supplying the log file that found this bug.
Fixed LED behaviour on Pixhawk
The large 3 colour LED should now correctly display the failsafe and GPS status
Improved PX4 and Pixhawk compass calibration
We now run a strap calibration on every boot which improves compass accuracy by a small amount
Added RSSI_RANGE parameter
This allows you to scale your RSSI input to match your receiver
Fixed GPS health status in MAVLink
The GPS health bit will now show as unhealthy if the GPS does not have 3D lock. Thanks to Iskess for reporting this issue!
Also thanks to everyone who gave feedback on 2.77, much appreciated!

Issues with this release should be posted on the APM:Plane forum

With the release of the 2.74 version of APM:Plane and the introduction of TECS, the ability of APM to take full advantage of an airspeed sensor for fixed wing aircraft was greatly enhanced. A lot more people are now buying and installing airspeed sensors. APM has had support for airspeed sensors for a long time, but tuning for good airspeed control was somewhat difficult and error prone. Now it is much easier.

The next APM:Plane release will be 2.75, and will come out soon. In that release airspeed sensing will be improved even more, with three key changes.

New Digital Airspeed Sensor

The first change is to add support for a new digital airspeed sensor from Measurement Specialities, the MS4525DO. The PX4 dev team announced this sensor recently, and I've been test flying it to ensure it works well with APM. It does! This new sensor is a huge advance over the analog sensors we've been using up to now.

The key difference is how low the thermal drift is in the reported differential pressure. A long standing problem with airspeed sensors has been the drift in the reading as the sensor warms up. This doesn't matter very much if you only need accurate airspeed readings at high speed as the contribution of thermal drift to airspeed drops rapidly with speed (as airspeed is proportional to the square root of the measured differential pressure). At lower speeds, such as when landing, it can matter, and having a sensor with low thermal drift is very nice. The I2C based MS4525D0 has internal temperature calibration to cope with thermal drift, which really helps.

The difference can be seen in the following graph

the green line in the graph shows the airspeed from an analog sensor, and the red line shows the airspeed from a MS4525D0 digital sensor. The readings were taken on two Pixhawk boards side by side, started at the same time. You can see that the analog sensor drifted quite quickly to above 2 m/s average, whereas the digital sensor settled at around 0.5 m/s.

Right now we only have a driver for the MS4525D0 on the PX4 and Pixhawk. It would be possible to write a driver for the APM2, and we'd welcome a contributed driver.

Before we settled on the MS4525D0 we also tried the EagleTree I2C airspeed sensor but we found it suffered from thermal drift just as badly (and in some cases more badly) than the analog sensor. We still have the EagleTree driver in the tree, so if you have an ETS airspeed sensor it will work, but we don't recommend it if you can get the MS4525D0.

Automatic Airspeed Calibration

The 2nd big airspeed change in the 2.75 release will be the introduction of automatic airspeed ratio calibration. The airspeed ratio is the ratio between the calibrated airspeed and the square root of the differential pressure measured by the sensor. This ratio is normally around 2, and is controlled with the ARSPD_RATIO parameter in APM:Plane.As is described in the documentation, it is common that this ratio needs to be calibrated for different airframes. There are several reasons why the ratio may be different from 2.0:

• positional error, caused by how the sensor is installed in the aircraft
• sensor error, caused by small leaks or differences in sensor construction
• pressure altitude differences, caused by changes in airspeed measurement with altitude

For previous releases of APM:Plane users wanting the best possible airspeed measurement needed to calibrate the sensor themselves, by flying the aircraft and looking at the logged airspeed compared to groundspeed. That worked, but it was not convenient.

For the 2.75 release Paul Riseborough has contributed a small 3 state Kalman filter which can automatically calibrate the airspeed ratio while flying. To enable it you need to set ARSPD_AUTOCAL to 1 and then just fly normally. The ARSPD_RATIO is automatically updated while you are flying. The following graph shows it working on my AcroWot:

I had deliberately set ARSPD_RATIO to 1.2 on takeoff to give the autocalibration code something to do. As you can see, the groundspeed and airspeed don't match at all well while the ratio stays low. After a few minutes of flying the autocalibration has raised the ratio to the right value of 2.0, and the airspeed nicely matches the average groundspeed.

Compensation for pressure altitude

The final major change in airspeed handling for the 2.75 release is the introduction of the EAS2TAS ratio throughout the code. The EAS2TAS is the estimated to true airspeed ratio, and reflects the fact that airspeed measured by an airspeed sensor drops relative to the true airspeed as altitude increases. This change is due to the lower air pressure, which means less air molecules hitting the sensor.

We already had compensation for EAS2TAS in the core navigation code in the 2.74 release, but for 2.75 we have propagated this ratio throughout the code. In particular the ratio is now used to adjust tuning parameters in the servo control loops, adjust the navigation code and even adjust the loiter radius with altitude. The idea is to make APM tuning parameters for an airframe be the same at sea level as it is at the top of a mountain, which will make it easier for users to share parameters, and also be a big advantage for anyone who flies at a wide variety of altitudes.

We have tested this code using the excellent JSBSim flight dynamics simulator, which allowed us to take a simulated aircraft up to altitudes far beyond what we could go to with a real R/C model. The EAS2TAS compensation worked well up to altitudes of around 30km.

Overall the upcoming 2.75 release should be a big improvement for anyone using an airspeed sensor. We hope you enjoy flying it!