docs: add vendor ID allocation table

[alexcekay]

Context

The vendor range [20000, 21000) has grown organically with no tracking of who uses what. The result is vendors picking IDs ad-hoc. Without documented allocations, downstream projects cannot add messages independently without risking ID collisions when upstreaming their changes.

Changes

This PR documents current usage and formalizes contiguous blocks so each namespace has room to grow autonomously: 100 IDs for open-source projects, 20 IDs for companies. Blocks are anchored to each vendor's first existing allocation. IDs that fall outside their natural block are listed in another table.

This also adds the px4.* namespace (20800–20899) following the existing ardupilot/ precedent, and com.auterion.* (20900–20919) as Auterion's company namespace.

If your namespace is represented incorrectly or you'd prefer a different block size, comment and I'll happily adapt.

[hamishwillee]

@peterbarker Can we get this particular case looked at please?

[peterbarker]

Doesn't this need to come along with some sort of an allocation policy/mechanism, similar to board_types.txt?

[tridge]

better have all the ones that exist now

[tridge]

does this actually exist?

[alexcekay]

Can you please clarify? If you mean if there are px4 messages yet, the answer is no.

This is a reserved allocation which we would like to use similar to the ardupilot* range. The idea is to use them for project-specific messages. The first example I'd put into this space is #80. The change proposed there doesn't seem too useful for ArduPilot but is useful in the context of PX4. My plan is to open PRs for messages like this and, if they turn out not to be useful for ArduPilot, move them into this range instead.

[alexcekay]

@peterbarker: Good point, I added a description to the README.

[PYBrulin]

Thanks for this proposal, I was also under the impression that there was not enough formalization to prevent future collisions. I personally encountered ID collision twice since starting using UAVCANv0/DroneCAN. Especially with service types that are very limited in number (the upstream of Hobbywing services was one of such issue).

I would like to suggest one addition to this table, which would be a "protected" ID range reserved for specific use cases. Call it "specific", "protected", "independent" or "proprietary" (?), but the idea would be to have a reserved collision-free range for messages that are intentionally not meant for standardization or cross-vendor interoperability. Where only the system owner is expected to operate within this range. In such cases, using an ID from reserved or vendor-specific ranges carries too much risk of future collisions. This approach seems consistent with this PR to me, rather than opening an issue about it (sorry if that's out-of-scope).

As a use case: at my company, we have at least eight nodes that communicate with each other on our vehicles using custom service and broadcast definitions for configuration and telemetry. And although we use standard messages as much as possible, some of our definitions are too specific to our internal systems to ever make sense as upstream contributions. Yet we still need them to coexist on the same bus as the flight controller and other standard nodes without risking future ID collision.

Adding such protected range would prevent the creation of forks that would try to revert/override vendor messages, and allow independent developers to use custom messages on their own system without risking ID collisions with future standardized messages.

PS: As a side note, the current state of this PR does not document existing service ID ranges that are already used by vendors. Hobbywing already uses both 210-217 and 241-242 vendor service ranges. There is also mppt which defines a service with ID 240 in the vendor range. They need to be documented in the allocation table as well.