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
Chris: I fully understand the reasoning for the events that happened with Dronecode, 3DR is a business, not a charity, so I can appreciate the issues GPL v3 presented.
The open nature of 3DR’s code and hardware, whilst it has many upsides, it did mean it was easy for the competition to quickly copy new ideas 3DR came up with, 3DR created smart shots, yet in very little time all the other brands had their variants, some using similar Catmull Rom mathematics. Prior to the Solo, DJI didn’t have redundancy in its flight controllers and had single magnetometer drones which needed the infamous compass dance, I doubt any one of us believe that DJI made many decisions in the P4 design which echoed the Solo merely by coincidence. I suspect 3DR could now have been very rich, had its technology been protected by patents.
But none of this mitigates the need for open and honest communication and transparency, the fact ArduPilot seemed shocked at being removed from Dronecode suggests (again as someone seeing events from the outside) they weren’t properly consulted, regardless of the business logic in decisions there is always a right and a wrong way to approach dealings with partners.
This is again a personal view, I haven’t spoken to Philip on the matters in this thread, I’m aware from the various customer groups I’m involved in that bringing out a new replacement product within 12 months is seen as bad form, even 18 months, whether it’s a new camera, a new drone or a new flight controller.
Using the Pixhawk name in an incremental numerical manner, should, just as a matter of business courtesy consider partners where a product has been on the market within these kind of time frames, personally if I found myself creating a new product that was using a shared brand name, I’d consider it a matter of integrity to give 6 months’ notice as a minimum if I was using a brand in a manner that could be misunderstood as superseding an existing product, both to avoid customer confusion and to allow a rebranding effort where necessary. Rebranding isn’t a quick exercise and even 6 months’ notice would be rather mean.
It’s a long time now since 3D Robotics rebranded as 3DR, yet many people to this day still say 3D Robotics, demonstrating that rebranding doesn’t happen overnight.
Having a choice of flight controllers and associated hardware isn’t a problem, but confusing and misleading branding is.
~@ Darrell, by "out of topic" is meant "not the OP's post topic. It has Nothing to do with what you're referring to.
@Hugues - One man's 'out of topic' vomit is another man's technical facts. Unfortunately for those who attempt to spread inaccurate information, on this forum they will be challenged by experts with credentials to back up their statements.
Woow wow wow. How can such a post trigger the production of so much "out of topic" vomit ? with the usual offended fanatic and hysterical ones defending "the cube" as their precious. Pathetic, especially considering the apparent IQ level of these people.
The topic is about a new autopilot that brings a very welcome alternative board (with its pros and cons) to the market which is in demand of high quality autopilots after the disappearance of 3DR'Pixhawk boards.
An alternative brings more competition, more choice and will drive overall quality and functionality upward. Or are we living still in a soviet era still where the only authorized autopilot should be Pixhawk2.1 (which is far than perfect on many points) ?
I have no affiliation with Drotek, I'm not paid by them nor did I receive free products from them to review on my various youTube channel or web blogs.
However in view of the reactions here, I feel compelled to thank you, Drotek, for daring to produce a new autopilot is such an hostile environment. I particularly appreciate the fact that your board, although still in early development, is available (and in stock) for anyone to buy and test and so to be able to provide feedback for improvements (because your board is not perfect obviously, but has potential) which is rarely the approach taken by other Pixhawk compatible boards developers.
Ian: Most open source projects splinter or fork at some stage, and that's a natural evolution as success breeds divergent interests. In this case, it's actually less acrimonious than most (just see the craziness in the fracturing of the FPV racing MultiWii code for a particularly nasty example of the norm). ArduPilot is lucky to have, in Tridge and Randy, two of the finest developers I've ever had the privilege to work with, and both have been honorable and pragmatic through this split. It's never easy to divorce, but this one happened because of a legitimate disagreements over licencing philosophy rather than any lack of respect on either side.
In short, it was unfortunate but not unprecedented and there is still a lot of opportunities for cross fertilization between the projects ahead of us.
Gary: You may want to do a little more research on the BSD licence, which is what PX4 uses, before you use terms like "a more restrictive license that essentially gave them control over distribution". Both BSD (PX4) and GPLv3 (ArduPilot) are popular open source licences, but the BSD licence actually gives less control over distribution. The main difference between them is that GPL v3 requires all distributors to open source their derivatives, while BSD does not. After more than a decade of experience, I've come to prefer BSD, but both have legitimate pros and cons.
@Gary
I was aware of ArduPilot being kicked out of Dronecode, which I think is the root cause of the poor relationship between 3DR and ArduPilot, albeit I suspect in time it will all be water under the bridge, well it would be if it wasn't for actions such as the matters discussed in this thread.
@ Ian - Chris,
To say this is an incendiary issue is an understatement.
For one thing, the split of 3DR with Ardupilot and adoption whole cloth of Lorenz - Pixhawk - Dronecode was in no way mutual.
From all accounts at the time it was an ouster of the heavy investors and Chris performed directly against Ardupilot because the Ardupilot developers intended that their code remain in it's current publicly distribute-able license.
The investors and Chris wanted a more restrictive license that essentially gave them control over distribution.
As the primary development of Ardupilot had been done by unpaid or barely compensated developers and testers and (a huge batch of other contributors myself included on the wiki) it seemed only fair (to us at least) that our efforts, made primarily on a public spirit be maintained in that form.
It had originally been promoted by all concerned as being a open development and the assurances had been that this would continue.
Until actual money came to the fore at which point that silly concept was discarded by the usual suspects.
At that point the Ardupilot developers had the choice of betraying their really large contributing public or staying true to their stated purpose.
If you know Andrew Tridgell (lead Ardupilot developer), you will know that one thing about him is a very careful and fair method of operation.
Basically there was no option, Ardupilot was essentially forced out in favor of parallel code (drone code that up until that time the Ardupilot devs had also contributed too.
I do not doubt that their may be room for a law suit in there somewhere, but that is not the ArduPilot way and I am pretty sure it is not something that they could afford in any case.
In any case it was not at all mutual, it was an ouster by Chris, 3DR, the investors and Lorenz on the whole of Ardupilot.
These facts keep getting sidelined in the ongoing lore, but they are the "Actual Facts" not the currently popular "Alternate Facts".
Clearly now Ardupilot and Dronecode will continue to be developed in parallel, and the choice and competition will probably make both products better and I am personally glad that multiple platforms will support either.
Bygones are becoming bygones, but their will always be a bitter taste in the mouths of those of us who went through this.
It is also worth pointing out that The ardupilot developers developed the original APM series and then a descsion was made to adopt Lorenz and ETH's superior PX4 design and continue development with that the development of the Pixhawk was a collaborative effort with ArduPilot and Lorenz/ETH developer participation.
Personally I think the name Ardupilot and the name Pixhawk/PX4 should be completely abandoned by the current Ardu Devs, we don't even work with Arduino any more so it seems to me a new name is needed for all concerned.
Best Regards,
Gary
I know Lorenz Meier has the Pixhawk trademark, my point still stands on common sense, the name could have been Pixhawk "whatever" there's a range of names that could have been appended onto Pixhawk, adding "3" suggests it's a newer and more advanced model and I'm not going to get into the pedantics of the specifications of both, but from my view as a customer, who rates redundancy and reliability as my most important factors, I consider the 2.1 Cube to suit my needs better. I prefer the idea of 3 IMUs and I believe Philip was correct adding heating as I personally recall the failures on the IRIS using Pixhawk 1 in cold weather. I could even find the warnings posted by Vu on this very matter, should anyone want to debate this.
It's also important for the Solo to see its continued potential that a pin compatible Cube should exist for purchase.
The Pixhawk 2.1 is using the branding "Cube" to transition away from using the Pixhawk name, the choice of Pixhawk for the 2.1 I'm sure was to keep continuity from the Solo given the pin compatibility. Whilst I consider myself diplomatic, I'm not naive and I can't accept a range of intelligent individuals chose the name "Pixhawk 3" without knowing it would be confusing.
I am member of one of Arducopter's partners, so I will be voicing my concern and my viewpoint on the naming, at first I saw the funny side, but some of comments I've seen made in this thread have left a sour taste.
A few random facts...
1. Pixhawk 2 was designed from the ground up with a few key requirements from day one
A. Modular, so it can suit multiple vehicle types, from the smallest racer, to the Research vehicle
B. For DIY, full accessibility to all the available io (full carrier board)
C. Fit for OEMs. From day one, the module approach allowed for custom carrier boards by the community.
2. The full carrier board was designed BEFORE the start of the Solo project
3. The concept of "the Cube" and the initial design were designed by Philip Rowse, as a sponsored community member. The design was his.
4. 3DR refused to release Pixhawk 2 when it was ready to go in December 2014 due to not wanting other OEMs to beat Solo to market. So the product was put on hold until after Solo was launched.
5. 3DR promised to OEMs that they would release the cube, the PSM, and the Sololink for custom vehicles. Yet they refused to actually do this.
6. The integration of the Intel Edison was completed in 2014, and was presented at the Intel Developer Conference for the launch of Edison
-
2
-
3
-
4
-
5
-
6
of 8 Next