Introducing the PX4 autopilot system

The PX4 team is pleased to announce early availability of the PX4 autopilot platform, with hardware available immediately from 3D Robotics. 


The platform is a low cost, modular, open hardware and software design targeting high-end research, hobby and industrial autopilot applications.

PX4 is an expandable, modular system comprising the PX4FMU Flight Management Unit (autopilot) and a number of optional interface modules.

The PX4FMU autopilot features include:

  • 168Mhz ARM CortexM4F microcontroller with DSP and floating-point hardware acceleration.
  • 1024KiB of flash memory, 192KiB of RAM.
  • MEMS accelerometer and gyro, magnetometer and barometric pressure sensor.
  • Flexible expansion bus and onboard power options.

Expansion modules available at release include:

  • PX4IOAR This module interfaces PX4 to the AR.Drone motor controllers, allowing a complete quadrotor to be assembled using an AR.Drone frame and motors.
  • PX4IO A flexible interface module with support for eight PWM servo outputs, relays, switched power and more.

As an open hardware design, third-party and DIY expansion modules can be easily developed for specific applications, and more PX4 modules are in development.

In addition to the versatile hardware platform, PX4 introduces a sophisticated, modular software environment built on top of a POSIX-like realtime operating system. The modular architecture and operating system support greatly simplify the process of experimenting with specific components of the system, as well as reducing the barriers to entry for new developers.

Adding support for new sensors, peripherals and expansion modules is straightforward due to standardized interface protocols between software components. Onboard microSD storage permits high-rate logging and data storage for custom applications. MAVLink protocol support provides direct integration with existing ground control systems including QGroundControl and the APM Mission Planner.

Pricing of the PX4 components reflects more than a year of careful development and a strong commitment from our manufacturing partner.

This release is targeted at early adopters and developers looking for a more capable platform than existing low-cost autopilots. With more than an order of magnitude more processing power and memory compared to popular 8-bit autopilot platforms, PX4 is exceptional value for money and provides substantial room for future growth.

For more information about the PX4 autopilot platform, visit the project website at

PX4 modules can be purchased from our manufacturing partner, 3DRobotics.

E-mail me when people leave their comments –

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

Join diydrones


  • What about this?

    Looks like there's a xxd binary in there.

  • Sorry about the typo in my previous post. English is not my native language.  Brain thanks - I'm trying to get it compiled on a win64 system. I faked it a bit. The xxd is used to create a romfs header file. Found the header file someware else and used this one - for sure, the content might be wrong and I removed the generation using the xxd from the makefile. Then the make went all the way through to the final bin file. There are a certain amount of warrnings showing up during the build process. I'm used to zero warning, at least that's a policy at work. Anyway this project is just starting - hardware available - and therefore that's fine with me. I ordered already a set of the hardware, to me it looks really great - guys I'm sure you did a great job here. Your software architecture looks great too. Finally can somebody help me getting the "xxd" issue solved running Win64?!?


    btw the bootloader build fine - try now to explore the nuttx using my stm32f4-discovery board

  • It's apparently installed with vim, at least on my Fedora machine.

  • I'm trying to generate the software. Followed the instructions, even I had already a toolchain installed for this target.

    Getting following error:


    The "xxd" cammond was not found. It's a Linux command. Can somebody help me out here ??

    Thanks in advance
  • The PX4 flight videos and airframes only show indoor quads where robust state estimation is less critical than say a windy outdoor environment.

    1. What does PX4 use for sensor fusion (e.g. Extended KF, Unscented KF)? What Hz does your state estimation loop run at?

    I did't find any mention of calibration routines on your wiki. The more robust IMU's I've seen require a static and dynamic calibration - either by the user, or at the factory. For example, VectorNav, AutoQuad, DJI(?).

    2. Is there a calibration phase to properly setup the PX4?

    The hardware looks very nice, but I was less certain about the firmware. Thanks

  • @px4 - I see the code and appears that you're not using MPU6000 for nothing. Will you support a sensor fusion between the 2 gyros and 2 acc to get better stability?

  • This looks more interesting the more I read about it.  I'm looking forward to seeing specifics on what folks are doing with this.

  • @Dan/Angelo - The key here is balance.

    Using a simpler RTOS (really just a scheduler and some messaging primitives) like FreeRTOS or Chibi would have meant much more work for the project, as we would have had to implement and maintain a whole lot of OS code from scratch. 

    Using Linux would have required substantially more expensive hardware, as well as introducing more complexity in other areas (e.g. effectively maintaining a distro).

    The .netmf tools are interesting, but .netmf is not structured well for implementing a modular, realtime system. Additionally, the CortexM4 port is still very green.

    Using a more full-featured RTOS like NuttX strikes a good balance for us. Other open-source alternatives in this space would have been eCos or RTEMS.

  • In practice yes. Control / UAV people are these days also typically trained in *nix environments, in addition to all technical considerations this will also help to get some more advanced estimation and control techniques onto this platform.

  • Sound interesting, guess I'll give it a try,sounds like the tools are there

    So overhead was the deciding factor over lets say .Net or Linux?

    *Note as a design engineer, I tend on focusing on my code, and the possible application of any hardware, and therefore the developement tools are always my first concern. Thanks for your thoughts


This reply was deleted.