# Pixhawk Autopilot Hardware Standard Draft

**URL:** <https://discuss.px4.io/t/pixhawk-autopilot-hardware-standard-draft/15459>\
**Category:** Pixhawk\
**Created:** [March 1, 2020, 10:48am UTC](https://discuss.px4.io/t/pixhawk-autopilot-hardware-standard-draft/15459 "2020-03-01T10:48:18Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![LorenzMeier](https://discuss.px4.io/user_avatar/discuss.px4.io/lorenzmeier/32/17_2.png) [@LorenzMeier](https://discuss.px4.io/u/LorenzMeier)\
**Post date:** [March 1, 2020, 10:48am UTC](https://discuss.px4.io/t/pixhawk-autopilot-hardware-standard-draft/15459/1 "2020-03-01T10:48:18Z")

</div>

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](https://discuss.px4.io/uploads/short-url/hDRYO5hxdNfbmNhWvnSVrpAayuB.pdf) (2.3 MB)

---

<div class="post-metadata">

**Author:** ![thirtytwobits](https://discuss.px4.io/user_avatar/discuss.px4.io/thirtytwobits/32/5693_2.png) [@thirtytwobits](https://discuss.px4.io/u/thirtytwobits)\
**Post date:** [March 1, 2020, 5:32pm UTC](https://discuss.px4.io/t/pixhawk-autopilot-hardware-standard-draft/15459/2 "2020-03-01T17:32:34Z")

</div>

What is the licensing of the document and its contents?

---

<div class="post-metadata">

**Author:** ![thirtytwobits](https://discuss.px4.io/user_avatar/discuss.px4.io/thirtytwobits/32/5693_2.png) [@thirtytwobits](https://discuss.px4.io/u/thirtytwobits)\
**Post date:** [March 1, 2020, 5:44pm UTC](https://discuss.px4.io/t/pixhawk-autopilot-hardware-standard-draft/15459/3 "2020-03-01T17:44:37Z")

</div>

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](https://new.uavcan.org/specification/UAVCAN_Specification_v1.0-alpha.pdf)?

---

<div class="post-metadata">

**Author:** ![LorenzMeier](https://discuss.px4.io/user_avatar/discuss.px4.io/lorenzmeier/32/17_2.png) [@LorenzMeier](https://discuss.px4.io/u/LorenzMeier)\
**Post date:** [March 2, 2020, 7:55am UTC](https://discuss.px4.io/t/pixhawk-autopilot-hardware-standard-draft/15459/4 "2020-03-02T07:55:06Z")

</div>

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

> **[\[pixhawk.org\] Pixhawk Autopilot Reference Standard](https://docs.google.com/document/d/1KlQeYnhtK43maBSeFuH5s03XsbLIsRVQQ3sZO1HYUM0/edit#)**
>
> Table of contents Table of contents	2 Document Revisions	3 Contact and Public Developer Call	3 Trademark Guideline	3 License and Disclaimer	3 Flight Management Unit Standards	4 Interface Standards	4 Common External Interfaces	5 Pixhawk Autopilot Bus...

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.

---

<div class="post-metadata">

**Author:** ![PavelKirienko](https://discuss.px4.io/user_avatar/discuss.px4.io/pavelkirienko/32/3464_2.png) [@PavelKirienko](https://discuss.px4.io/u/PavelKirienko)\
**Post date:** [March 2, 2020, 3:37pm UTC](https://discuss.px4.io/t/pixhawk-autopilot-hardware-standard-draft/15459/5 "2020-03-02T15:37:19Z")

</div>

> [@LorenzMeier](#):
>
> 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.

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:

> <https://github.com/OpenCyphal/public_regulated_data_types/issues/30>
>
> See this thread: \<https://groups.google.com/d/msg/uavcan/Er2ghsqumVs/1671vlOtCgA…J\>
> 
> TL;DR: we're going to add an alternative connector option that will be compatible with the CiA 303 DB9 connector specification (the de-facto industry standard D-Sub connector for CAN).
> 
> !\[image\](https://user-images.githubusercontent.com/3298404/27197116-bfd9cd52-5215-11e7-9490-3120dbfec139.png)
> 
> The power supply voltage in this pinout is ranging from +18 to +30 VDC, the nominal is +24 VDC. This is unlike the currently used JST GH, where we're supplying +5 VDC.
> 
> This proposition doesn't rule out the possible emergence of other connector types in the future.
> 
> Here's the CiA 303 document: \[303\_1v01080001.pdf\](https://github.com/UAVCAN/dsdl/files/1078800/303\_1v01080001.pdf)

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.

---

<div class="post-metadata">

**Author:** ![cuhome](https://discuss.px4.io/user_avatar/discuss.px4.io/cuhome/32/5205_2.png) [@cuhome](https://discuss.px4.io/u/cuhome)\
**Post date:** [March 3, 2020, 5:11am UTC](https://discuss.px4.io/t/pixhawk-autopilot-hardware-standard-draft/15459/6 "2020-03-03T05:11:36Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![jlecoeur](https://discuss.px4.io/user_avatar/discuss.px4.io/jlecoeur/32/5043_2.png) [@jlecoeur](https://discuss.px4.io/u/jlecoeur)\
**Post date:** [March 3, 2020, 1:58pm UTC](https://discuss.px4.io/t/pixhawk-autopilot-hardware-standard-draft/15459/7 "2020-03-03T13:58:58Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![kevindsp](https://discuss.px4.io/user_avatar/discuss.px4.io/kevindsp/32/5192_2.png) [@kevindsp](https://discuss.px4.io/u/kevindsp)\
**Post date:** [March 3, 2020, 6:17pm UTC](https://discuss.px4.io/t/pixhawk-autopilot-hardware-standard-draft/15459/8 "2020-03-03T18:17:05Z")

</div>

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

 ![serial-inverting](https://discuss.px4.io/uploads/default/original/2X/6/664ed39feebfb03c4ac468a9160a4019d149e437.jpeg)  
2: It’s maximum output current is just 1.5A.  
It is not enough for p900 datalink module.  
 ![maximum current](https://discuss.px4.io/uploads/default/original/2X/a/a84545142009316b597368a84521ba09361c281e.jpeg)  
3: The last is the FMU standard should have can-power interface  
for the smart-battery or the smart power module.  
 ![can-power](https://discuss.px4.io/uploads/default/original/2X/1/1acef95d1d0222e5731cf775c65783c861dd8a80.jpeg)
