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 http://pixhawk.ethz.ch/px4/
PX4 modules can be purchased from our manufacturing partner, 3DRobotics.

Comments
Here is the link to the schematic of the production version, the wiki is updated accordingly:
https://pixhawk.ethz.ch/px4/_media/modules/px4fmu-schematic-v1.6.pdf
@ Gary: working on that, we're following up closely.
@Jose: Thanks for pointing that out, that is actually a prototype schematic and that has been fixed. Uploading a new schematic now. The MPU-6000 *is* operational
Hi
Looking the schematic of PX4FMU , sheet 3 , i think there is a bug in MPU6000.
Pin 13 of MPU6000 not connect to 3V3 , only connect to a capacitor and not to Supply VCC.
Regards
Jose
You can download a working xxd.exe in the meantime from here:
https://pixhawk.ethz.ch/px4/_media/xxd.zip
Unzip it to C:\px4\toolchain\bin (check that arm-none-eabi-gcc is in the same directory)
It should be fine then. I'll have an updated installer soon.
What about this?
http://code.google.com/p/vim-win3264/
Looks like there's a xxd binary in there.
It's apparently installed with vim, at least on my Fedora machine.
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.
I just tried to explain the considerations that led to the choice of NuttX, there is nothing personal in it. I can only recommend to read up the documentation a bit to see if you like it before drawing quick conclusions.
Dan, the tools for NuttX are obviously the standard GNU tools, but single-step debugging with JTAG or SWD via Eclipse is available and you can upload software from within Eclipse via USB. What we also valued is a toolchain that is available on Windows, Linux and Mac OS. This is already a great step forward from many setups where graphical single-step debugging is not easily achieved.
-
4
-
5
-
6
-
7
-
8
of 10 Next