Development moved to github

We moved APM development from subversion to git quite a while ago, and it was a big improvement, but we've been noticing quite a few rough edges to the git support on Meanwhile, has been rapidly developing as a great platform for projects like ours, with a really nice workflow and great issue tracking. One of the big advantages of git is that it's easy to move to a new host, so we decided to move APM development to The new master repository is at and the old repository on has been frozen with no new commits.

One of the big advantages of github is a nicer system for people to submit patches for inclusion in the master tree. On github this is called a "pull request" and it is explained nicely in the documentation. I'd encourage all APM developers to have a look through the github documentation.

The pull request system also has the advantage that it is much easier for everyone to see what patches are pending review and inclusion in the tree.

Another major change is that we've reduced the number of people that have direct access to pushing new code in the master branch. The way we worked previously was that if you submitted a couple of good patches then you would be given direct push access for future work. That sometimes led to patches going in that didn't really have adequate review, but it was the least painful way to do things with the system. Given the nice pull request interface on github we're trying a different approach, where nearly all developers, even people who have been contributing for years, will get their code into the tree via a pull request. Only 3 developers (Pat, Randy and myself) currently have access to accept pull requests, which we hope will lead to a bit more code review and higher quality code. We'll have to see how it works out over the coming months!

Issues now tracked on github

As part of the move to github we've adopted the github issue tracking system. This integrates very nicely with git commits, so we can for example add "fixes issue #7" in a commit message and the issue automatically updates to note the fix.

One tricky decision was whether we import over the old issues from to the new system. After much discussion we decided not to, as we'd been so slack in keeping the old issue system well maintained that most of the issues were not relevant any more. There are some important ones in there though, so if your favourite issue has been lost then please post it into the new system (after checking if its has already been dealt it!).

New developer mailing lists

Another big change is the creation of two new mailing lists, drones-discuss and drones-devel. In the past we've had a private developer mailing list, which Chris invited people to join when they made a contribution to the code. That private list really originated from the time where there was a much smaller group of APM developers, and there is no good reason why it was still private, so we've created the two new lists as public for anyone to join, and shutdown the old private list. So if you want to get involved in APM development or just want to lurk in the developer discussions then please join the drones-discuss list!

Please don't post to the drones-devel list though - this is just for coordinating releases. It is a public list, so anyone can join and listen in, but we want to keep the noise on it low if we can.

We'd also like to emphasize that these lists are not the place for help requests - they are meant for development discussions only, such as discussing new features as they are being developed. The diydrones forums are still the right place for user discussion.

AP_HAL - the Hardware Abstraction Layer

The biggest change in the APM code itself comes from the new HAL (Hardware Abstraction Layer) pioneered by Pat Hickey. If you have a look at the current git tree then you'll see some new directories under libraries that start with AP_HAL. The AP_HAL directory itself defines the new API that abstracts out the differences between the various autopilot board types we support. Then we have a separate AP_HAL_$board directory for each board. The code for the APM1 and APM2, which are based on AVR CPUs, is in AP_HAL_AVR, but you may notice there are some other board types in there as well.

The main motivation for the AP_HAL work was to give us a clean way to support the new PX4 autopilot, which is based on a 32 bit ARM core, but it does a lot more than that. It gives us a very nice way to make all of the APM vehicle types portable to a lot more types of hardware with very little work.

In our code you will notice that we have a new 'hal' object which contains methods to access the hardware specific functions. For example, to set IO pin 17 as an output pin we would now do this:

  hal.gpio->pinMode(17, GPIO_OUTPUT);

the HAL API replaces the Arduino specific calls which we used previously, and gives us a lot of flexibility to implement all the board specific functions in different ways for each board.

We think that the ArduCopter 2.9 release which is in its final release candidate now will be the last "pre-HAL" release. The master branch is fully converted to AP_HAL, and has all of the features from 2.9 merged in. It is also flying very well!

One thing to watch out for is that if you are building the APM code using the Arduino development IDE then you will need a special patched version to support the new AP_HAL based code. We've released zip files of the patched IDE for Windows and MacOS. If you build on Linux then please use the 'make' command.

PX4 support

The big test of the new AP_HAL system was the PX4 port. We've had the PX4 hardware for months now, but the software port was lagging behind badly. It was really quite tricky to port the code across to the new NuttX RTOS based platform cleanly. With the introduction of the AP_HAL system it was incredibly easy, and just a few days after we got AP_HAL into the tree we had our first successful flights of both ArduPlane and ArduCopter on PX4 boards on the same day!

So if you have a PX4 then it is now possible to use it with any of the 3 vehicle types we support (copter, plane and rover). There are still some interesting issues with how to plug in servos and radios, but if you don't mind a bit of creative wiring then it does work. We will be posting some instructions soon.

I'd also encourage you to have a good look around the PX4 website. Lorenz and the whole PX4 development team have done a fantastic job with this board, creating something that gives us an incredible scope for future development. The work they have done on the sensor drivers and ORB integration is top notch, and I found it really nice to work with the system they have created in doing the APM port.

If you want to build the APM code for PX4 yourself then it's worth noting that one of the things we don't have yet is a good way to build the APM code for PX4 on Windows - it's building fine on MacOS and Linux, but the Windows build system still isn't ready. We'll post an update when we have that working. The core PX4 code does build on Windows with Eclipse, but we just haven't done the extra bits needed to allow the APM code to build within that development environment yet.

Meanwhile, if you want to build on MacOS or Linux then you'll need the PX4 firmware tree somewhere on your system, and you need to use the "make px4", "make px4-clean" and "make px4-upload" commands.

There are still some missing features on PX4, for example we don't yet have analog inputs, so no airspeed sensor on ArduPlane, but we'll get that sort of thing fixed up pretty quickly I think. Even so, I've done around a dozen flights with my PX4 equipped SkyFun so far, and it is flying very nicely! Both Pat and Randy have flown ArduCopter on PX4 as well, and both found it flew very well. Here is a video showing Pat flying the master git branch on PX4

Note that the port to PX4 doesn't mean we are abandoning the APM1 and APM2. All the APM code builds on all 3 platforms (plus the 'SITL' simulator platform), and our plan is to continue to support the APM1 and APM2 for as long as we can. What we expect to happen is that some new CPU and memory intensive features will only be enabled when you build for PX4, where we have so much more CPU and memory available.

Happy Flying!

I hope the above gives everyone a bit better idea of what has been happening. The pace of development has been very high over the last month, and if you've noticed that some of us have been a bit quiet on the forums then this is why. Over a thousand patches have gone into our git tree in the last 2 months to make all this possible, so we've actually been quite busy!

Views: 16034

Comment by Martin Poller on January 16, 2013 at 6:21am

Thank you Andrew  for this very detailed and informative post to keep us all in the picture.

I for one will shortly be investing in a PX4, and for me the Windows build system can't come too quickly!

Great work by you and all the other developers involved.

Comment by Thomas J Coyle III on January 16, 2013 at 9:18am

Nice and effective reorganization Tridge!



Comment by Rana on January 16, 2013 at 9:48am

Just wonderful Tridge !

Comment by Scott Berfield on January 16, 2013 at 10:04am

Thanks for the writeup. I have been havinga  lot of fun wandering through the code. Learning a ton from it even though a lot of it is over my head. We are starting to use Git for work as well and I agree it is really coming together as a base for development with distributed teams.

Guess I better start saving my pennies for a PX4 or two :)


Comment by Simon Wunderlin on January 16, 2013 at 10:44am

Thank you tridge. I am very happy the dev mailinglist is opened up for everyone to see where the APM software is heading to.



Comment by Alex McEwan on January 16, 2013 at 12:56pm

Thanks tidge

Is the planed dev path PX4 and beyond or will there be a 32bit APM 3 ?

Comment by John Wiseman on January 16, 2013 at 1:16pm

Wonderful changes, thanks and congratulations on all the progress.  It feels like with these reorganizations the ardupilot project has done a good job of 1. encouraging better code, 2. making current developers' lives easier and 3. making it easier for potential future developers to learn about the project and eventually contribute.

Comment by Andrew Tridgell on January 16, 2013 at 1:23pm


PX4 is what we have now, and it's a really great board, but it wouldn't surprise me if 3DR did something new based on the same chip - I'll leave Craig or Chris to comment on that though!

Cheers, Tridge

Comment by Jiro Hattori on January 16, 2013 at 3:52pm

Regarding PX4, I have some questions that is development environment and some trick to use start up script.

What about Eclipse that is described to use as PX4 tool chain on the web site of Lorentz ?

Some say, needs of linux or unix on Macintosh for compiling PX4 code is essential.

PX4 is easy to use start up script by micro SD card. However, the reliability is not clear by difference of manufacturer of micro SD card and socket hardware uncertainty of vibration.

One more thing is that compatibility issue of PPM encording and Futaba s-bus.

Actually, I am so excited to move 32bit environment and touch on PX4.

I'd like to fly with PX4 soon.

Comment by lot on January 16, 2013 at 3:56pm

Sorry, I need to say:




You need to be a member of DIY Drones to add comments!

Join DIY Drones

© 2020   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service