As a practical experiment on the applicability of DSDL, I have designed a namespace defining the interface to an abstract UAVCAN-interfaced CAN adapter. It is not supposed to be included in the standard namespace since it’s too application-specific; rather, suppose that these definitions are contained in a vendor-specific namespace. The exact use I have in mind for these definitions is irrelevant as of now so I am not going to discuss that; think that the business requirements are to make a generic bridge.
The interface is designed to be fully stateless (one side does not make assumptions about the state of the other side) and is based on the continuous exchange of two messages between the “master” node (the user of the interface bridge) and the “bridge”/“adapter” node itself:
- Idempotent command message type
Configuration, published periodically by the “master”. - Informative status message type
Status, published periodically by the bridge.
Such message-based idempotent interface is desirable because it is self-recovering against loss of state on the bridges (e.g., due to power cycling) and scales automatically to any number of bridges working in lockstep (modular redundancy).
The proposed types define the management interface only. The application data is transferred via separate topics of type uavcan.metatransport.can.Frame.1.0, which is a very new experimental message type that I’m planning to merge into the standard namespace soon as a part of the ongoing work on the logging feature (the link points to PyUAVCAN but the feature is obviously supposed to be implementation-agnostic).
One thing I noticed is that having complex data type definitions with a deep level of nesting in one namespace directory gets messy fast. When you’re looking at the directory, the structure looks flat and it’s hard to grasp the purpose of the namespace at a glance:
Perhaps in the future, we should look at having some means of defining simple (anonymous?) types in-place or expressing the structure at the directory level.
Find the definitions at: