Choosing Message and Service IDs

Applications & Usage
1

Hello! I am starting to look into how to use UAVCAN 1.0 and one of my primary questions is regarding how I can create a device as a vendor that speaks UAVCAN and publish the message info for users to use. I generally understand the concept of DSDL for creating datatypes, and I read in the guide document that the Public/Unregulated type messages are primarily the ones recommended for vendors of devices to use, and that the public regulated ones are very limited and reserved for general widely applicable messages. My concern is that the guide recommends that vendors provide a way to reconfigure their devices to allow non-fixed IDs for their DSDL messages. This seems very complex, and something that a user of my devices doesn’t care about at all.

Let me give an example: A user has an aircraft with a PX4 flight controller. They buy a UAVCAN GPS device that supports a few public regulated messages, but it also has a few public unregulated messages that give additional data and control. This is a popular device and PX4 has a parameter that allows you to chose this specific GPS device, which then signals to PX4 that it should try to use the additional public unregulated messages, which it knows because the DSDL was published by the device vendor, along with the ID numbers. The ID numbers can’t change, because the device has been released and doesn’t have any UI for users to change the IDs. PX4 also needs to know it’s device IDs and it gets those from the vendor.

How does this not work? It seems like there should be a global spreadsheet or something where vendors can go in and choose their device IDs or something. It could be a way of notifying others that they plan to use these, but doesn’t preclude others from creating devices with the same IDs. It could then be kind-of driven by the market. If someone releases a successful device, people would know not to try to use those same IDs. If someone else marked that they plan on using a block of 1000 IDs and has no market share and products that actually use them, then people could just ignore his claim on those and win them by releasing a device that does use them.

Any guidance here would be very helpful! Thanks in advance.

2

UAVCAN is about building abstract interfaces to enable more complex systems while keeping things simple and maintainable.

The root of your misunderstanding is that you assume that an ID signifies not only the syntax of the data (how it is composed of primitives) but also its semantics (how it is applied in a particular system). I understand where this misconception is coming from – existing embedded systems generally tend to rely on cruder interfaces where there is often no need to introduce extra abstraction and low-level reasoning is generally effective. This mindset is no longer valid for modern robotic and vehicular systems due to the growing complexity, and it can result in serious scalability problems down the road, increasing the cost and putting a hard ceiling on how complex the behaviors implemented by the system can be.

The syntax of a data type is identified by its name (like uavcan.si.sample.temperature.Scalar.1.0). The semantics are identified by the subject-identifier. The two are orthogonal excepting certain special use cases, of which you can think as singletons in an OOP program, or as well-known UDP/TCP port numbers. In the case of DS-015, for example (the upcoming UAVCAN drone standard), most of the data types (especially those related to sensor messages, etc) are not going to have any fixed subject-identifiers. The detailed explanation and justification for this design choice are provided in The UAVCAN Guide (chapter “Interface design guidelines”).

Vendors are interested in upholding this principle because it expands the set of viable applications of their products. For example, if you manufacture a BMS, you will delegate to the integrator to decide where and how it should be integrated into the system. As a vendor, you would be unable to decide for the user which particular role the battery is going to be serving in the system: is it a traction battery? Which one of several? Is it powering the payload? Every participant of the ecosystem is interested in ensuring that the resulting systems are scalable and evolvable, even if the methods of ensuring these properties may seem non-obvious at first.

The view that the approaches we are proposing are more complex than the traditional alternatives is misguided and arises out of a misunderstanding of how systems are composed of COTS components. Whichever strategy is chosen, the hardware vendor cannot dictate the place and function of the hardware unit within the system (excepting few marginal cases) – at least some degree of configurability is necessary. Keeping this in mind, you can see that our approach does not add complexity or variance to COTS units, but rather it reorganizes the existing variabilities in a different way. Continuing the BMS example, the traditional approach would assume that the BMS has a configuration parameter that sets the instance-identifier for this device (which one of the several batteries onboard would that be?); the architecturally clean approach that we have implemented in UAVCAN v1 prescribes to remove the instance-identifier and configure the subject-ID instead. A convenient analogy is the topic name from ROS, DDS, MQ*, etc.

Concerning the integrator’s user experience, in the case of the drone ecosystem at least, the vendor does not need to get involved at all because eventually the configuration process will be entirely automated away. We have the full plug-and-play support on the roadmap for DS-015 already. The end device does not need to know whether it’s being configured by the human manually or by another device automatically because in both cases the same register configuration API is used. Whether there is a dedicated UI provided by the vendor is entirely irrelevant and it is left out to the vendor’s discretion.

I understand that what we propose is a little unorthodox, but sometimes new things have to be introduced to account for the changes in the environment.

1 Like
3

Thanks for the explanation. I’m still a bit unclear though. Are you saying that the subject IDs will need to be assigned dynamically? If so, is there a well known fixed subject ID that can be used to assign system specific subject IDs? Almost like how TCP port 80 is used to distribute out random unused ports to actually serve data during a transfer.

It would be really helpful to have an example of recommended device provisioning in a system. For example, if the device has no UI, it must have a method to configure it via the comms interface it has available right? Like is there a way to send a message from the central node in the system, like the flight controller, that pairs the textual subject name with a subject ID number? The device can then store this to it’s own NVM, but that at least needs to happen once. It seems like that process is so critical to the system that it should be part of UAVCAN?

4

No. They will be assigned statically, but they will be assigned by the integrator rather than the vendor. This means that the vendor will have to make them configurable. This is not the same as “dynamic” because they won’t be changing while the system is operational.

Yes, it’s called the Register API. It’s on a fixed ID (just like many other standard services).

This example should make things clearer: Automatic configuration of port identifiers (the discussion in that thread seems a little ragged because much of it was discussed in our private Slack, but we try to avoid that to keep all context public).

It is part of UAVCAN; specifically, it’s the part of the Register API. The UI is absolutely irrelevant here because whether it’s provided by the vendor or not has no effect on the UAVCAN interface – all DS-015-compliant devices will be required to support the Register API, always.