High level node descriptor

Applications & Usage
1

Hi all!

I’ve been trying to understand DSDL and how we can use it in our systems. I like the DSDL composition of types and services but I feel it’s missing a higher level node construct.

SensorNode:

  • Service ADCService
  • Service VoltageSensorsService
  • Message Status

The intent here is that by using node descriptors we can create target generators and save ourselves a lot of code to write.

Is there anything like this in UAVCAN/DSDL that I have missed? Is anyone working on similar projects?

Cheers,
Mike

2

You seem to be proposing something close to electronic datasheets, am I correct? Currently, there are no well-defined plans underway to support that, but you may find this post (closer to the end) relevant: GUI Tool – Next Generation

If you have a specific detailed proposal in mind, please post it in https://forum.opencyphal.org/c/dev and we will discuss it.

3

Electronic datasheets are exactly the type of thing I am talking about! Apologies for the dump below, I have been using this comment as a scratchpad for some thoughts and they are a bit jumbled.

I think I am coming from a slightly different angle from a lot of that discussion, I am primarily concerned with system descriptions (and highly reliable systems!) - the interest in DSDL is because it is succinct, lightweight… and ripe to have more features abused into it!

I don’t have a proposal at this point but I’m looking at a few of things:

  • A node descriptor which captures the services and messages the node may call and respond to
  • A method to attach documentation to DSDL descriptors (think doxygen style comments in dsdl, or files that match up with dsdl descriptors)
  • A method to handle multiple versions of the same message.

The comment you mention, and specifically The electronic datasheets are likely to be preferred in high-reliability settings hits the nail on the head. I have a system, I know at deployment exactly what goes into it. I don’t want my nodes to negotiate, establish a connection and subscribe to things, I want them to come up ready to handle a message and do their job within milliseconds of power on.

Node descriptors make lots of awesome things very easy to do. A full node descriptor allows generation of more embedded code (in libcanard the handle and filter functions can be generated). It also allows us to create a python object and bind functions on to it to represent a specific node. We can now easily make a python implementation of a canard node - we just need to write the behavior in behind the interface. This is awesome for testing! Another benefit as well is having a good way to describe system nodes lets us lay out interfaces more effectively at design time - the test nodes can be created long before hardware arrives.

Introspection was mentioned, yes please, and with rich documentation attached to the dsdl. The user should be able to do help(node) and see something which allows them to use it. This can also be used in generation of documents such as Interface Control Documents.

Regarding being able to work with multiple versions of the same message, would it ever be possible to use something like:

[default data type ID.][version.]<data type name>.uavcan

Suppose I want to be able to work with multiple versions of a system where I also want to keep the ddtIDs fixed. From my understanding collisions should be avoided because of the CRC. It’s not pretty, but the big hub node can brute force trying each versions signature to match the CRC.

Anyway, this is a very interesting project - I’m interested to get involved!

4

These are very valuable ideas, but I should introduce a few corrections here.

First of all, you seem to have based your reasoning upon the experimental version of the specification, which I boldly call “legacy”, also known as UAVCAN v0. The first stable release which is termed UAVCAN v1.0 differs somewhat from v0; you should familiarize yourself with it here: https://new.uavcan.org/ (if you have strong feelings about the new logo, please head this way: PR preparations for the upcoming UAVCAN v1.0 release: new website, new logo). Important differences between v1 and v0 are that there are no more “data type identifiers”, and that there is native support for data type versioning. A brief but comprehensive recap of the differences is available here, although you may have already read that: Stockholm Summit recap

Second of all, UAVCAN is intentionally designed to be very stateless and robust. Specifically this:

<…> negotiate, establish a connection and subscribe to things <…>

…is not about UAVCAN. The only kinds of dynamic negotiation are the plug-and-play node allocation feature (which is optional and is actually somewhat discouraged by the specification!) and automatic configuration of the physical layer (auto bit rate detection, which is also optional). A typical UAVCAN node is ready to work immediately once powered on, which is emphasized in the spec:

5.2.1 Node initialization
UAVCAN does not require that nodes undergo any specific initialization upon connection to the bus — a node is free to begin functioning immediately once it is powered up.

This is important for UAVCAN because high-reliability applications are among its primary use cases.

Other than above, we seem to be on the same page. It might be an interesting exercise to come up with a working PoC of a declarative node generator as you described, where one defines a high-level node logic using DSDL types and some interface definition schema (not necessarily DSDL-based). Further development of this idea is highly welcome.