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
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.
Sorry if I hurt you with my question. :-(
I'm not assuming overhead at all, the fact is I'm spoiled by other design tools, hell even Arduino (through Visual Micro) has great tools now.
Working with ARM developement, on embedded linux and .net devices, has been VERY easy.... I don't want to go back to buggy compliers and develope tool problems, outside of my code.
But again, I don't know NuttX..... I just want to hear the teams thoughts?
@Dan and Angelo,
Based on which arguments do you assume that NuttX would add any relevant overhead in memory and speed? Did you measure it? Did you previously work with any of the named RTOS and did you compare it to one with better hardware abstraction, such as e.g. VxWorks? Why is a RTOS similar to VxWorks (look at the list of applications here: http://en.wikipedia.org/wiki/VxWorks) a step back, given that autopilots gain more and more functionality?
Processing power increased, as well does the complexity of missions we'd like to fly with these autopilots. Development with better hardware abstraction gets simpler, since on PX4 only a few people actually need to deal with the OS - the majority of developers can focus on functionality for users. This separation is something schedulers (like FreeRTOS and others) do not allow.
In the future an autopilot will be characterized by the functionality and the benefit it provides for users, not by the hardware it runs on. PX4 is a step into this direction.
When you even consider Linux, think about the overhead and the hard-realtime properties. Our setup is fast and satisfies hard-realtime constraints.
On the other way, why not a "simpler" RTOS, like Freertos, Chibios, etc...??? without the "Posix I/O stuff" which add overhead in term of memory and speed. OK, with STMF4, we have a lot of memory and MHz, but the code would be more portable between various projects and architecture.
Why NuttX?
Given all the GREAT tools for other ARM embedded solutions?
What am I missing here, seems like a step backwards?
*I admit to having never developed on a NuttX device, but have used Linux, and .Net micro framework, both with great tools.
The redundancy is on purpose, yes. We want our adopters to be able to compare the two sensors sets against each other. Since the software abstracts from hardware, any future sensor change will not induce any software change needs. We will however keep the redundant setup for some time.
The schematics and board's pictures shows MPU6000 and BMA180+L3GD20. Will all the boards fitted with this redundant configuration ?
@PX4 - I already ordered a ppm encoder from here along with the px4 and ar drone board :) I'm very excited! Is there a more exact shipping estimate already? In 2 weeks I'm going on holiday, hate to have fedex at my doorstep while I'm flying from europe to miami..
@Nick - The amount of board space required to support multi-channel PWM input is simply prohibitive in a system the size of PX4. Low-cost PPM systems are easy to come by (see for example the FrSky receivers), or if you can afford the space DIYDrones offers a PWM-to-PPM encoder that will do the job.
@Cliff-E - The SAM4S has been vaporware for nearly a year now, and you still can't buy them:
http://www.stkcheck.com/evs/atmel/atmelheader2.asp?mfg=atmel&pa...
ST were simply first to market with a CortexM4 device, and they were happy to support the ETH lab's development efforts with engineering samples. The relevant competition right now are the LPC43xx series, which has either less flash or less RAM, and the Kinetis K20 which is physically too large, slower, and also has less RAM.
One of the advantages of the PX4 system is, however, that most of the software isn't tied to the hardware. Any architecture that the RTOS runs on is a candidate with a modest amount of porting work.