Pixhawk Autopilot Hardware Standard Draft

Hi All,

I’m sharing here a PDF of the Pixhawk Hardware Standard Draft. The goal of this is to standardize the interface of the flight controller (as well as to the gimbal, but in a separate document). This has the benefit that drone manufacturers can build a custom baseboard and autopilot vendors can have confidence that there is a neutral industry standard for their products they can rely on and that has reach and longevity.

[pixhawk.org] Pixhawk Autopilot Reference Standard.pdf (2.3 MB)


What is the licensing of the document and its contents?

1 Like

Will this document be expanded to include CAN/UAVCAN connectors, transceiver standards, and/or power standards or will it defer to section 7 of the UAVCAN specification?

I’ve added a first pass at licensing in the living document:

Regarding connectors: Only the JST GH connector makes sense from a size perspective. All the other connectors are entirely unreasonable for a device the size of a drone.

In summary: We would be happy to align with the UAVCAN specs, but as of now they are not realistic when it comes to a real physical system and unless the spec is changed we would probably pick and mandate our own connectors.

I don’t think it’s true. The UAVCAN spec offers three connector options; one of them is JST GH itself, another is M8 which we have agreed on as the suitable option for larger UAV systems:

The size argument is also incompatible with the ongoing PX4 hardware standardization discussion where an even larger option from Fischer is proposed as an alternative.

The third connector type is the standard D-Sub; its omission would be unreasonable from the COTS compatibility standpoint.

I think on the hardware side the UAVCAN specification is close to optimal and the statement about its recommendations being unrealistic is misguided. We would be happy to provide additional options for hardware connectivity as long as the proposal is sufficiently well researched and reasoned.

For RC connector design, I think it can be done better.; users often mistakenly connect ppm rc to rcin, or sbus rc to ppm in. Delete SN74lVC2GU04DCKR on the h7 board; and connect SBUS with PPM. This is very good about the design of RC in fmu v5mini.

Great document, thanks a lot for this ongoing effort.

I think the document is missing bits of information regarding the conformance to the standard:

  • as a manufacturer: how do I make sure that my product is compliant with the standard?
  • as a customer/integrator: how do I know that a board meets the standard, both in terms of compatibility and of performance?

For both points, an open source reference implementation is a great solution.
An open source reference implementation leaves no doubt about what needs to be done to be standard compliant and also allows to test manufacturers’ designs against the reference design.
Is it planned to release an open source reference implementation of the Pixhawk standards?

When are the first FMUv5x products expected to reach market?

1 Like

Three suggestions about the FMU’s standard
1: H7 serial processor supports for the serial inverting.
So the IC U7 can be removed.

2: It’s maximum output current is just 1.5A.
It is not enough for p900 datalink module.

3: The last is the FMU standard should have can-power interface
for the smart-battery or the smart power module.

1 Like