The PX4/Dronecode team and Drotek have been working on the next generation of Pixhawk autopilots, and you can now see a preview of that with the Pixhawk 3 Pro. It's based on the new PX4 FMU4 Pro standard, which includes a full suite of next-generation sensors and and the more powerful STM32F469 processor. It's designed for the Dronecode/PX4 flight software, which is the current official Pixhawk standard.
The board is currently in developer release, but will be taken out of beta after testing is complete in the next month or two.
All details are here (and below):
------------------
Introduction
FMUv4-PRO takes input from all of the Pixhawk stakeholders; end users, developers, researchers and manufacturing partners. Goals for this iteration of the platform are:
- – An integrated, single-board flight controller for space constrained applications
- – A modular multi-board flight controller for professional applications
- – Sufficient I/O for most applications without expansion.
- – Improved ease-of-use.
- – Improved sensor performance
- – Improved microcontroller resources (384 KB RAM, 2 MB flash).
- – Increased reliability and reduced integration complexity.
- – Reduced BoM and manufacturing costs.
Key design points
- – All-in-one design with integrated FMU and optional IO and lots of I/O ports.
- – Improved manufacturability, designed for simpler mounting and case design.
- – Separate power supplies for FMU and IO (see power architecture section).
- – Onboard battery backup for FMU and IO SRAM / RTC.
- – Integration with two standard power bricks.
Technology upgrades
- – Microcontroller upgrade to STM32F469; flash increases from 1MiB to 2MiB, RAM increases from 256KiB to 384KiB, more peripheral ports.
- – ICM-20608, MPU9K integrated gyro / accelerometer / magnetometers.
- – LIS3MDL compass (HMC5983 is now obsolete).
- – Sensors connected via two SPI buses (one high rate and one low-noise bus)
- – Two I2C buses
- – Two CAN buses
- – Voltage / battery readings from two power modules
- – FrSky Inverter
- – JST GH user-friendly connectors
I/O ports
- – 6-14 PWM servo outputs (8 from IO, 6 from FMU).
- – R/C inputs for CPPM, Spektrum / DSM and S.Bus.
- – Analog / PWM RSSI input.
- – S.Bus servo output.
- – 6 general purpose serial ports, 2 with full flow control, 1 with separate 1A current limit, 1 with FrSky protocol inverter.
- – Two I2C ports.
- – Two external SPI ports (unbuffered, for short cables only).
- – Two CANBus interfaces.
- – Analog inputs for voltage / current of two batteries
- – On-ground usage piezo buzzer driver.
- – Sensor upgrade connector scheme
- – High-power RGB LED.
- – Safety switch / LED.
Mechanical Form Factor
- – 71 x 49 x 23 mm (with case)
- – 45g (with case)
- – Standardized microUSB connector location
- – Standardized RGB led location
- – Standardized connector locations
System architecture
FMUv4-PRO continues the PX4FMU+PX4IO architecture from the previous generation, incorporating the two functional blocks in a single physical module.
PWM Outputs
Eight PWM outputs are connected to IO and can be controlled by IO directly via R/C input and onboard mixing even if FMU is not active (failsafe / manual mode). Multiple update rates can be supported on these outputs in three groups; one group of four and two groups of two. PWM signal rates up to 400Hz can be supported.
Six PWM outputs are connected to FMU and feature reduced update latency. These outputs cannot be controlled by IO in failsafe conditions. Multiple update rates can be supported on these outputs in two groups; one group of four and one group of two. PWM signal rates up to 400Hz can be supported.
All PWM outputs are ESD-protected, and they are designed to survive accidental mis-connection of servos without being damaged. The servo drivers are specified to drive a 50pF servo input load over 2m of 26AWG servo cable. PWM outputs can also be configured as individual GPIOs. Note that these are not high-power outputs – the PWM drivers are designed for driving servos and similar logic inputs only, not relays or LEDs.
Peripheral Ports
FMUv4-PRO recommends separate connectors for each of the peripheral ports (with a few exceptions). This avoids the issues many users reported connecting to the 15-pin multi-IO port on the original PX4FMU-PRO and allows single-purpose peripheral cables to be manufactured.
Five serial ports are provided. TELEM 1, 2 and 3 feature full flow control. TELEM4 can be switched into inverted mode by hardware and has no flow control. Serial ports are 3.3V CMOS logic level, 5V tolerant, buffered and ESDprotected.
The SPI ports are not buffered; they should only be used with short cable runs. Signals are 3.3V CMOS logic level, but 5V tolerant.
Two power modules (voltage and current for each module) can be sampled by the main processor.
The RSSI input supports either PWM or analog RSSI. CPPM, S.Bus and DSM/ Spektrum share now a single port and are auto-detected in software.
The CAN ports are standard CANBus; termination for one end of the bus is fixed onboard. .
Sensors
The new ICM-20608 has been positioned by Invensense as higher-end successor of the MPU-6000 series. The software also supports the MPU-9250, which allows a very cost-effective 9D solution.
Data-ready signals from all sensors (except the MS5611, which does not have one) are routed to separate interrupt and timer capture pins on FMU. This will permit precise time-stamping of sensor data.
The two external SPI buses and six associated chip select lines allow to add additional sensors and SPI-interfaced payload as needed.
IMU is isolated from vibrations.
Power Architecture
Key features of the FMUv4-PRO power architecture:
- – Single, independent 5V supply for the flight controller and peripherals.
- – Integration with two standard power bricks, including current and voltage sensing.
- – Low power consumption and heat dissipation.
- – Power distribution and monitoring for peripheral devices.
- – Protection against common wiring faults; under/over-voltage protection, overcurrent protection, thermal protection.
- – Brown-out resilience and detection.
- – Backup power for IO in the case of FMU power supply failure.
- – Split digital and analog power domains for FMU and sensors.
FMU and IO Power Supplies
Both FMU and IO operate at 3.3V, and each has its own private dual-channel regulator. In order to address issues seen with PX4v1 and noisy power supply connections, each regulator features a power-on reset output tied to the regulator’s internal power-up and drop-out sequencing.
The second channel of each dual regulator is switchable under software control. For FMU this is used to permit power-cycling the sensors (in case of sensor lockup), and for IO this will make it possible to perform the Spektrum binding sequence.
Power Sources
Power may be supplied to FMUv4-PRO via USB (no peripherals in this mode) or via the power brick ports. Each power source is protected against reverse-polarity connections and back-powering from other sources. Power spikes observed on the servo bus (up to 10V) led to the removal of the power-from-servo option, users wanting this feature can connect the servo rail with a cable containing a Zener diode to the 2nd power brick port.
The FMU + IO power budget is 250mA, including all LEDs and the Piezo buzzer. Peripheral power is limited to 2A total.
Power Brick Port
The brick port is the preferred power source for FMUv4-PRO, and brick power will be always be selected if it is available.
Servo Power
FMUv4-PRO supports both standard (5V) and high-voltage (up to 10V) servo power with some restrictions. IO will accept power from the servo connector up to 10V. This allows IO to fail-over to servo power in all cases if the main power supply is lost or interrupted. FMUv4-PRO and peripherals combined may draw up to 2A total.
Power is never supplied by FMUv4 to servos.
USB Power
Power from USB is supported for software update, testing and development purposes. USB power is supplied to the peripheral ports for testing purposes, however total current consumption must typically be limited to 500mA, including peripherals, to avoid overloading the host USB port.
Multiple Power Sources
When more than one power source is connected, power will be drawn from the highest-priority source with a valid input voltage.
In most cases, FMU should be powered via the power brick or a compatible offboard regulator via the brick port or servo power rail.
In desktop testing scenarios, taking power from USB avoids the need for a BEC or similar servo power source (though servos themselves will still need external power).
Summary
For each of the components listed, the input voltage ranges over which the device can be powered from each input is shown.
| Brick ports | Servo rail | USB port | |
| FMU | 4 – 5.7V | no | yes |
| IO | 4 – 5.7V | 4 – 10V | yes |
| Peripherals | 4 -5.7V, 2A max | 4 – 5.7V, 250mA max | yes, 500 mA max |
Peripheral Power :
FMUv4-PRO provides power routing, over/under voltage detection and protection, filtering, switching, current-limiting and transient suppression for peripherals.
Power outputs to peripherals feature ESD and EMI filtering, and the power supply protection scheme ensures that no more than 5.5V is presented to peripheral devices. Power is disconnected from the peripherals when the available supply voltage falls below 4V, or rises above approximately 5.7V.
Peripheral power is split into two groups:
- – TELEM 1 has a private 1A current limit, intended for powering a telemetry radio. This output is separately EMI filtered and draws directly from the USB / Brick inputs. Due to the noise induced by radios powering a radio from this port is not advised.
- – All other peripherals share a 1A current limit and a single power switch.
Each group is individually switched under software control.
The Spektrum / DSM R/C interface draws power from the same sources as IO, rather than from either of the groups above. This port is switched under software control so that Spektrum / DSM binding can be implemented. Spektrum receivers generally draw ~25mA, and this is factored into the IO power budget. S.Bus and CPPM receivers are supported on this rail as well.
Battery Backup :
Both the FMU and IO microcontrollers feature battery-backed realtime clocks and SRAM. The onboard backup battery has capacity sufficient for the intended use of the clock and SRAM, which is to provide storage to permit orderly recovery from unintended power loss or other causes of in-air restarts. The battery is recharged from the FMU 3.3V rail.
Voltage, Current and Fault Sensing :
The battery voltage and current reported by the power brick can be measured by FMU. In addition, the 5V unregulated supply rail can be measured (to detect brown-out conditions). IO can measure the servo power rail voltage.
Over-current conditions on the peripheral power ports can be detected by the FMU. Hardware lock-out prevents damage due to persistent short-circuits on these ports. The lock-out can be reset by FMU software.
The under/over voltage supervisor for FMU provides an output that is used to hold FMU in reset during brown-out events.
EMI Filtering and Transient Protection :
EMI filtering is provided at key points in the system using high-insertion-loss passthrough filters. These filters are paired with TVS diodes at the peripheral connectors to suppress power transients.
Reverse polarity protection is provided at each of the power inputs.
USB signals are filtered and terminated with a combined termination/TVS array.
Most digital peripheral signals (all PWM outputs, serial ports, I2C port) are driven using feature series blocking resistors to reduce the risk of damage due to transients or accidental mis-connections.
Inputs / Outputs
Comments
@Marc Dornan - I couldn't agree with you more. I would encourage Ardupilot team to move away from the Pixhawk name as well. It's an inferior product that they would be better off not being associated with IMHO (and I'm confident they won't be happy with me being so blunt about it being the highly ethical types that they are).
I'm afraid once again Chris has backed the wrong horse. The word is already out and all the cool kids are now all over at ArduPilot.
Ian: Thanks for the thoughtful note.
FYI: The name "Pixhawk" (and trademark) is owned by Lorenz Meier of the PX4/Dronecode team (who have been behind every official Pixhawk design, including Pixhawk 2, which they developed with 3DR) and that team worked directly with Drotek on the Pixhawk 3, which is based on the official PX4 FMU4 Pro design. So although I wasn't part of that, from my perspective it appears that Drotek has done all the right things by coordinating with the PX4 team.
There are many clones in China that use the Pixhawk name, but those are unauthorized.
This is the first time since discussing early issues with the IRIS that I've felt compelled to post.
I’ve been a long term supporter of 3DR, I was one, if not the first IRIS owner in the UK, I was first admin on the IRIS Facebook group after Ferdinand and then went on to support the Solo and its community through thick and thin. Incidentally the Solo was a fantastic product, where if lessons had been learned from the IRIS, then we’d likely not be where we are now, anyway I digress.
One of the main reasons that attracted me to 3DR, was the software choice, ArduPilot; having come from DJI (having had the Phantom from the day of launch and I believe I had the first recorded Phantom flyaway) I was very impressed with ArduPilot having seen documentation and YouTube videos by Randy showing the logic to deal with flyaways, I was reassured that instead of hiding from issues and bugs they were out in the open, being systematically tackled one by one.
From an outsider’s view, a customer’s view, I was genuinely sad to see that the Solo failed and the harm that did to 3DR and its staff, the industry needs competition against DJI for the sake of customer choice, it’s also sad to see what appears to be a damaged and hurtful relationship now between 3DR and ArduPilot.
I don’t know where all the fault lies between the sour relationship between 3DR and ArduPilot, but I know one fact, it’s take both sides for a fall out to occur and remain, the situation as it exists now does neither party any good and will harm 3DR’s brand, something especially Vu Tran has spent years building up. There will also be consequences for the PX4 brand, Dronecode and the consumer brands that run their architecture, especially given many of the people supporting those communities and buying into those brands are from the 3DR customer base.
There are brands now on the PX4 architecture, with flyaways, the same as the Phantom 1, with what appear to be very much the same root cause. Trolling isn’t taking place for the greater good of the industry, but the idea communities that aren’t in the DJI camp will stick together is going to fall apart if some of the kind of behaviour evident in this thread continues.
I have no idea whose idea it was to name this Drotek flight controller Pixhawk 3, so soon after the Pixhawk 2.1 launch, but anyone with an ounce of common sense, which I’m sure is everyone in this thread would know full well that would damage the Pixhawk 2.1 from ProfiCNC, which is the hard work of Philip Rowse, someone who is very well respected in the industry. To me it looks like a deliberate and mean spirited move, furthermore referring to the heating of the IMU as a hack is throwing salt into the wounds, personally I say shame on Drotek, I’m puzzled why ArduPilot has them as a partner with such behaviour.
Chris, you have the means to deal with a lot of this and build some bridges, for example making the Solo’s gimbal code public to allow ArduPilot to see the Solo user base being supported for years to come and maybe speak to some of the key people at ArduCopter and see that going forward there’s no bitterness or bad feeling for either side.
+ 1 to Olivier and Chris,
following that route has a lot of benefits.
You can have separate primary control controllers for aerial and robotic use with common interfaces to more advanced functionality on specialized companion computers.
It provides a safety plus where the primary controller can detect problems in the companion computer and initiate safety protocols.
It means that powerful dedicated companion computers can handle specialized tasks such as 3D vision, object detection and navigation across a lot of platforms.
The Nvidia TX1 and new and recently available TX2 seem particularly well suited to this with a large number of high performance GPU cores and a powerful multiprocessor core.
It is also low power and power consumption scales according to processor/GPU load.
Really perfect for a 3D vision and navigation companion computer in a very small package.
They even have very good development tools and a community producing open source projects.
Direction I am going anyway.
It has been interesting to watch Nvidia, the leader in PC graphics boards leverage their multi GPU architecture into 3D vision capable controllers and into Deep Learning AI.
Brilliant idea to buy stock in February of 2000.
In March of 2000 the stock I bought in Nvidia totally saved our butt.
Only stock I ever bought that really did well.
Got out of stocks after that though, figure I have sort of the reverse touch of Midas.
Best Regards,
Gary
+1 to what Oliver said. (Full disclosure: I work with the OpenMV team, too). The trend in the industry is to "black box" the flight controller into a relatively simple system, with modest computing requirements, and to handle more processing-intensive tasks in a separate "applications processor"
Originally we had assumed that this would just be Python scripting and the sort of things you can run on a relatively low-powered Linux computer such as the IMx on Solo or the Edison on Pixhawk2. But after a few years of experience, it's becoming clear that the simpler scripting functions can be done on the ground, while the onboard app processors are better used for computer vision tasks, such as sense and avoid and VIO.
Thus the trend with the Intel Aero and Qualcomm Snapdragon Flight to emphasize video processing in the onboard stack. That's something even the M7 isn't really good enough for. It's better to have a GPU. The Intel Joule has such as GPU, but the Edison does not. Expectation is that the Edison will be retired soon, with the focus moving to the Joule and higher-end processors.
An M7 couldn't hurt, and maybe it will happen. But while vision tasks on an microcontroller like OpenMV can always benefit from more power, current Pixhawk MCs have plenty of processing power for conventional flight control and it's rarely, if ever, an issue. The current trend right now, justified imho, is to decouple and use companion computers when heavy processing is required, e.g. for vision tasks or SLAM navigation. In other words use flight controllers as sensor heads only, communicating with companion computers when intensive computation is required. (Tridge has written a great overview of this here, see "Sensor Head port of Ardupilot" section.
That's a direction Ardupilot is following now, with its integration facilitation of Intel Edison or Joule, NVidia TX1 or TX2, Odroid, Raspi, etc ..., for instance. (e.g. APSYNC, or see also Randy's very cool work here. ). These computers are order of magnitude faster than any microcontroller, and some are hardware optimized for some specialized tasks, like NVIDIA's CUDA based graphic engines. And all benefit from mainstream Linux and its available software bells and whistles.
Decoupling flight control and sensors from higher level navigation tasks also has advantages from a software and hardware engineering point of view imo, in terms of reliability, modularity and ultimately quality.
Guys I have looking forward for IMU with Cortex M7. OpenMV guys have come up with a borad which has M7. So why is Pixhawk behind. It seems to be the logical next step.
Hi Rob,
I agree that the combined graphic is misleading, especially regarding Pixhawk 2 AKA cube.
Simply putting everything in a rectangular bounding box grossly misrepresents it's relative size.
Especially when this is the real thing.
I think each of these has valid uses, and the main problem is the number of people exploiting the ground breaking work done by the ArduPilot group while trying to divorce themselves from it.
In the case of the Autopilot software itself, except for Ardupilot, the others are something between a direct rip off of Ardupilot and a replication of its capabilities so they wouldn't be subject to the license (openness) of Ardupilot.
Basically an attempt to make proprietary that which was already public.
Sort of like Apple with all of Xerox Parc's stuff - mouse and window based operating system.
Gets back to why maybe free for all free market capitalism may not be the best thing for the World or it's people.
Different (and current) topic.
Personally I welcome this new system with even more internal redundancies.
The real system of the future will be a full at least triply redundant system with full voting and self monitoring capability and we are inching closer to that.
You can never make it failure proof, but you can make it more resistant.
Best,
Gary
The community effort on solo is blazing forward fulfilling many of the promises that 3DR made to the consumer.
We could however continue to support 3DR more if they were to release the remaining code for the gimbal and IMX
This would benefit both 3DR and solo owners.
3DR Please consider supporting those of us who supported you through thick and thin, by supporting the community effort
-
3
-
4
-
5
-
6
-
7
of 8 Next