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.
Comments
Thanks Alex, it's now more clear that the PH2.1 suits our needs.
https://forum.drotek.com/t/pixhack-v3-vs-drotek-pixhawk-pro-vs-pixh...
I am still not entirely sure myself if Ardupilot and Dronecode(PX4) are now tied to the hardware fork or if each code branch is compatible with each board.
Yes you can pair with Jetson TX1/TX2. As it is open source you can integrate the two boards any way you like with the appropriate code changes. But for a clean integration that makes no modification to the autopilot, you can connect the Jetson UART to the autopilot Telemetry port and send it Mavlink messages the same way a Ground Control Station does. There is a ROS wrapper for Mavlink also. This way you can send it waypoints and action lists. Or, I believe another option is to drive the autopilot with velocity commands that internally are routed to the RC Input.
Does anyone have an answer to my question above? Please.
Thanks.
I've looked into the Edison. Intel claims they will not be dropping it. It has it's place in the IoT market where a GPU is not necessary.
When you say discontinued do you mean by the autopilot community? I could see how the pixhawk 2.1 + Edison carrier board will be discontinued and replaced by a carrier board that integrates the Joule. Though there will be some time before that those options are available.
I had a look at the Raspberry, I can see how that solution would work for some builds, though it does not have realtime support. The Edison has a very appropriate architecture with the MCU in the same package. It is a very useful combination of high level control (linux + python) and realtime interfaces that are common in robotics architectures. The Nvidia can then take the vision heavy lifting. I have no idea but I am guessing the Joule still won't match the capabilities of the Nvidia. The Joule will certainly make a good companion computer for many smaller projects.
Hello,
It's not clear to me if the Drotek Pixhawk 3 Pro is actually better than Pixhawk 2.1 the Cube.
As better I intend more reliability, redundancy, connectors versatility, more integration with external sensors and, very important, if it can be paired with a Jetson TX1/TX2 for deep learning AI purposes.
Could you please tell me which is better?
Thanks.
Alex,
For Rover, you'll do better with the ArduRover software, which has a dedicated team and a Google Summer of Code project focused on it this year. (Although PX4 is the code I usually recommend for other platforms, its rover variant is not its focus). Both platforms support RTK well now.
As for the hardware, it doesn't really matter for your use case, since you'll be using a Nvidia companion computer and in the case of rovers the IMUs quality and number is not as important as it is for copters. Indeed, you'd be fine with the original Pixhawk. I would not recommend an Edison breakout, since the Edison is being replaced by the much more capable Joule, which can handle video. But there are not yet Joule carrier boards.
So for hardware, my recommendation would be that you actually go in another direction, and get the Navio2 board for RaspberryPi 3. This is the best of both worlds: an ArduRover compatible autopilot with great integration into the very capable RaspberryPi3, which can run TensorFlow, OpenCV and ROS.
That's what I use for rovers.
I am an autonomous robotics engineer now cofounder and CTO of a start up. I spent 4 years competing in the World RoboCup Federation Standard Platform League and my interests lay in high level control systems, perception, cognition and behaviour along with localisation and mapping in challenging environments. I have done a lot of control systems work but am trying to move away from it to tackle the real problems.
Please do not be offended by this but from my view the autopilot is now trivial, it is not anywhere near the leading edge of development. I see little value in proprietary autopilots.
In 2014 I built my own quad around the pixhawk after researching where the market was. Now that I am building a business around this technology I am trying to catch up and figure out what has changed since 2014. I have been reading for days as I am trying to make hardware and software selection decisions. I have to say I am both saddened and disappointed with what I see has happened. It is unfortunate what happened to 3DR but in hindsight I guess it is a lesson learned in competing with China in China's comfort zone. As far as what has happened to the software, I just kinda want to throw up in my mouth. There are a lot of valid points I have read on both sides, and also I have read a lot of posts written by zealots that are obviously out of their depth in the fast moving high tech domain of autonomous robotics.
I have decided to post this here as this thread has become divisive along with the other thread (http://diydrones.com/profiles/blogs/ardopilot-and-dronecode-part-wa...) but this one is more current. Divisive is fine in my context as I am looking for a balanced opinion and I know there are still a few fair minded and knowledgeable persons active here.
This is my query:
I am trying to choose between using the pixhawk 2.1(the Cube??) and the pixhawk 3.
I am also trying to choose between Ardupilot and PX4.
As far as the hardware goes I am interested in many ports so that I can integrate every sensor known to man.
As far as the software goes I am interested in the code branch with the most long term viability (Rover). The GPL3 vrs BSD or Apache is meaningless to me, I only have to make two single input/output changes to the code to make it do what I want and then most of what I will be doing will be on a companion computer (Nvidia) and as far as I am aware the GPL3 can't infect my high level system if it is entirely isolated. I'll push back my trivial changes if anyone cares.
A lot of the troubles I have seen in the development of the code up to know is related to dynamics and complex geometry and signal conditioning for standard sensors. This is one of my strength areas. I will have to make some changes to the autopilot to bring it up to the quality level I require. I am more than happy to push back such work as I am grateful for all the hardwork that went into the framework and user interfaces. And as I said, there is no real competitive market threat in that area. You'll all be happy *if I push back my autopilot work.
I have been reading about the differences in some of the modules that exist in Ardupilot and PX4 that are significant but for the life of me I can't keep track of them. I guess I am going to have to invest a lot of time into figuring out the hard way.
So having said all that, how different are Ardupilot and PX4 now? Which is the best choice for someone who is serious about this technology?
Also, same question with the hardware. I am interested in the breakout board with the Intel Edison. So the pixhawk2.1 looks appealing, also with the available ports. I haven't compared and counted the difference in port offerings yet but I have seen no pixhawk 3 - Edison integrated system. Is this true? Is the pixhawk2.1 companion board the option I want? Or is there a third option when the pixhawk 3 is compatible with the pixhawk2.1 carrier board??
But my ultimate question really is: does my choice of board influence my choice of software?
Are these all valid combinations?:
Pixhawk2.1 + Ardupilot(Rover)
Pixhawk2.1 + PX4(Rover)
Pixhawk3 + Ardupilot(Rover)
Pixhawk3 + PX4(Rover)
Addendum question:
Which system best supports RTK?
Please and Thank You for any input.
That ICM20602 looks great. Both the ICM20600 and the ICM20602 have rate noise power spectral intensity of 0.004 deg/sec/root(Hz). This is slightly less noise than the MPU6000's 0.005 deg/sec/root(Hz) and much less than the ICM20608.
With the IMU's internal digital filters set for 100Hz bandwidth the, the gyro rms rate noise would be:
MPU6000 - 0.05 deg/sec-rms
ICM20600 - 0.04 deg/sec-rms
ICM20602 - 0.04 deg/sec-rms
ICM20608 - 0.08 deg/sec-rms
No doubt that Invensense has done some research too. probably why temp compensation registers are now in one of their newest chips; the ICM20602. It should be noted the operational range for most of the sensors is -40C to 85C; with no mention of temperature compensation by the manufacturer.
In essence, perhaps the heater is just another bell!
True about the MPU6000. The chips made after that seemed to regress as far as noise is concerned. However, whether or not that is an issue depends on the application. In addition, it depends on how good the low pass filter implementation is. The ICM20602 is just as good as the MPU6000 if not better. Note the 20602, 20609, and 20608 are all pin compatible. They all seem to have a potpourri of FIFO buffer sizes too, but bigger is not always better since a larger buffer means more data which is older and losing its ephemeral/real-time value in a flight controller application.
Not sure why you would want to use the ICM-20608 IMU in a new autopiliot. It is a poor IMU compared to the MPU6000 used in the Pixhawk and even the APM autopilot.
The ICM-20608 being used in the Pixhawk3 has noisier gyros than the MPU6000 that is used in the APM, Pixhawk. Pixhawk2 also made the mistake of using an IMU with noisier gyros. This reduces leveling accuracy during startup and attitude accuracy during flight.
The MPU6000 has rate noise floor of 0.005 deg/root(Hz) gyro noise. The ICM-20608 is has a rate noise floor of 0.008 deg/root(Hz)). I think I will keep using the Pixhawk with the better MPU6000 IMUs.