DS-019: Pixhawk Standard Versions and Revisions

[nicovanduijn]

Hey everyone!
I've had this discussion with several individuals directly already, but I would like to open it up more widely:
With more and more Pixhawk FMUs and carrier boards, v5x, v6x coming out, it's easy to get confused about versions and revisions. What they are, and how we can best ensure intercompatibility. If we don't - what's the point of the standard anyway?

So far, there has existed a version/revision table buried in a google doc somewhere, where it doesn't get the visibility it needs and deserves. I've tried to summarize the current state and put all the boards known to me into a table. I've done this mostly for my own mental health so far, but I believe it provides value and should really be a community-managed topic in the first place. I'm proposing to add it to the Pixhawk standards repo.

Please have a look, leave some comments, suggestions etc. I can also put it in a different place like the px4 docs or the hardware repo, but I think this is a decent choice.

[nicovanduijn]

Bringing the discord conversation here for visibility:

Input from @AlexKlimaj:

I think for the baseboards we need to change the idea of X baseboard from this manufacturer is this VER. Instead it should be this VER of baseboard has this set of hardware. For instance has IO, or doesn't have IO, has ethernet or not, has one or two power ports, etc.
Also right now all the baseboard logic is in each of the FC board configs. This needs to be broken out into a common location.

@mrpollo mentioned:

Thanks for bringing this up for discussion, we should make sure we capture as much as possible on GitHub for posterity

[nicovanduijn]

agreed @AlexKlimaj , the eeprom should really contain a hardware manifest instead of a ver/rev.

However, I'd like to treat those two efforts separately - the motion to have a clear and public table of versions and revisions should not have to wait for the px4 support of hw manifest (which could take a long time).
The manifest too, may even deserve it's own DS-XXX standard?

[cuhome]

The pixhawk standard interface of px4 docs should link to the corresponding document when introducing the standard. The document should record the board name and manufacturer corresponding to VER, the difference between each board and the reference standard, and compatibility.

[nicovanduijn]

The pixhawk standard interface of px4 docs should link to the corresponding document when introducing the standard.

I'm not sure I understand. By "pixhawk standard interface of px4 docs", do you mean the pixhawk Autopilot standards DS-016 and DS-017 ? Or some page in the px4 documentation on docs.px4.io?

For the rest of your comment, that's pretty much exactly what I tried to document here - the board name and manufacturer corresponding to each ver. Are there some specific annotations you would suggest? Can you inline-comment it on the code, such that I can address them?

[vincentpoont2]

Input from @AlexKlimaj:

I think for the baseboards we need to change the idea of X baseboard from this manufacturer is this VER. Instead it should be this VER of baseboard has this set of hardware. For instance has IO, or doesn't have IO, has ethernet or not, has one or two power ports, etc.
Also right now all the baseboard logic is in each of the FC board configs. This needs to be broken out into a common location.

Agree it shouldn't be manufacturer specific, but hardware specific.

I think these VER on the 6X was done based on the baseboard hardware or ports it has, but since there isn't a proper placed to record what set of hardware & ports that particular version of baseboard, it got recorded as the Manufacturer's and model name instead.

Should a baseboard that has less or more ports use a different VER?

[vincentpoont2]

So far, there has existed a version/revision table buried in a google doc somewhere, where it doesn't get the visibility it needs and deserves.

FYI, here are the links to the Google Sheets

• FMUV6X_stm32_pinout
• FMUV5X_stm32_pinout

[vincentpoont2]

@nicovanduijn I grabbed these from the google sheet, should we put these chart and diagram on this diagram directly?

Config	R1 (K)	R2 (K)
0	NO POP	NO POP
1	442	24.9
2	174	32.4
3	115	38.3
4	84.5	46.4
5	61.9	51.1
6	51.1	61.9
7	46.4	84.5
8	38.3	115
9	32.4	174
10	24.9	442

	Expected limits	Boundary	Expected voltage	Boundary
ver/rev	range (DN)	thresholds (DN)	limits (V)	thresholds (V)
0	204	0	0.166	0
	553	579	0.441	0.467
1	605	580	0.492	0.468
	966	967	0.77	0.779
2	968	968	0.788	0.78
	1331	1356	1.062	1.093
3	1382	1357	1.125	1.094
	1738	1756	1.386	1.415
4	1774	1757	1.443	1.416
	2113	2137	1.685	1.722
5	2161	2138	1.759	1.723
	2476	2519	1.975	2.03
6	2562	2520	2.085	2.031
	2842	2919	2.267	2.353
7	2996	2920	2.438	2.354
	3230	3308	2.577	2.666
8	3386	3309	2.755	2.667
	3571	3699	2.848	2.981
9	3827	3700	3.114	2.982
	3946	4095	3.147	3.363

[vincentpoont2]

In this PR PX4/PX4-Autopilot#20182, there was concern of all these REV & VER taking up too much Flash Memory. How do we ensure intercompatibility if we are unable to add all the VER/REV due to flash limitation. Is there any idea on this?

[AlexKlimaj]

Can we look into each of these baseboards and list out the connections and features. Then try to make a list of baseboard versions that can encompass most of the use cases? Currently all 10 versions are already allocated...

On the topic of the baseboard EEPROM containing the manifest, that would need to be loaded by the manufacturer.

[AlexKlimaj]

@nicovanduijn @dagar @mrpollo @davids5 Can we have a call to discuss this? Maybe on the next pixhawk hardware call?

[davids5]

Bringing the discord conversation here for visibility:

Input from @AlexKlimaj:

I think for the baseboards we need to change the idea of X baseboard from this manufacturer is this VER. Instead it should be this VER of baseboard has this set of hardware. For instance has IO, or doesn't have IO, has ethernet or not, has one or two power ports, etc.
Also right now all the baseboard logic is in each of the FC board configs. This needs to be broken out into a common location.

@mrpollo mentioned:

Thanks for bringing this up for discussion, we should make sure we capture as much as possible on GitHub for posterity

This is what the manifest is used for.

[davids5]

@nicovanduijn There are CUAV boards https://github.com/PX4/PX4-Autopilot/pull/19819/files#diff-57baf7185821aa98bc86b03055e0192757228576370c495535cba7c402b39a1cR230

That were not the the sheets. We best check the code and get them all captured here

[nicovanduijn]

@nicovanduijn @dagar @mrpollo @davids5 Can we have a call to discuss this? Maybe on the next pixhawk hardware call?

@AlexKlimaj Unfortunately I cannot attend this week - is next week okay? (12/20)

[mrpollo]

@nicovanduijn @davids5 let's talk on the next pixhawk meeting if both of you are available https://www.dronecode.org/calendar

[nicovanduijn]

@mrpollo I would love to attend, but I'm very confused about dates and meeting links.
The calendar you linked to, shows a meeting on thursday, but the event agenda links to a discuss forum with a different date, so does the main pixhawk SIG site (https://pixhawk.org/sig/). The last few times I logged in on Tuesdays, there wasn't anyone in the call, and the meeting notes / agenda have been empty for months. Am I just looking in the wrong places?

[mrpollo]

The date that shows on the calendar is the date of the meeting I'll update everywhere else to match. Ill be there on all meetings from now on.

[nicovanduijn]

Great, I'll be there too!