The lengthy debate on the architecture of UDRAL culminated in the following draft that is currently maintained on a feature branch of the public regulated data types repository:
Everyone is welcome to read through the enclosed documentation in
README.md and submit feedback in this thread.
At the moment, the draft only includes the definitions for three basic network services: smart battery, ESC, and servo. Additional services will be added incrementally. One known issue is the
reg.udral.physics namespace which may need some refactoring, any help to this end would be welcome.
Those interested in the basic ideas behind this design may find this thread relevant: On multi-agent services and design guidelines
The demos have been updated to use the UDRAL draft instead of DS-015:
This design is based on the extensive notes taken by @coder_kalyan and @bbworld1 earlier, as well as the late DS-015 draft. The new design is intended to address the following issues raised on this forum:
- Composability and service orientation – by inheriting core design principles from DS-015.
- Type compatibility validation – by adopting the type compatibility check proposal submitted by @VadimZ.
- Automated port-ID assignment – by adopting the automated port-ID allocation proposal for which I made a PoC.
- Well-documented port-ID assignment – by adopting Vadimfiles containing the mapping from port names to port-IDs as proposed by @VadimZ.
- Bandwidth limitations – by validating the expected bandwidth utilization of this design against a set of typical vehicle configurations.
- Cognitive complexity – by relying on auto-generated rich HTML documentation for reading the data type definitions instead of raw DSDL files.
Find details on each item below.
Composability and service orientation
The draft upholds the principles of service-oriented design as explained in the Interface Design Guidelines published in the UAVCAN Guide.
This approach necessitates splitting large specialized messages as found in v0 into smaller orthogonal messages. Subscribers that are interested in the full set of data will need to perform timestamp-based matching. One related concern was that of the bandwidth implications, which is addressed in a dedicated section below.
Type compatibility validation
@VadimZ has demonstrated a convincing prototype of a data type signature that is compatible with the structural polymorphism and extensibility introduced in UAVCAN v1. The technical details are discussed in the dedicated thread.
At the moment, the draft does not mention this capability at all. I would like to invite Vadim to submit a pull request adding the documentation for his type signature directly to the UDRAL’s README document. Also, the actual implementation of the signature generation code should probably be accepted into PyDSDL, as well as data types generated by Nunavut should be annotated with their signatures.
Automated port-ID assignment
A detailed description is already available in the README document. The only implementation available at the moment is my PoC in Python. Volunteers are needed to provide a production-grade implementation of this logic in C++ for eventual inclusion into PX4 & ArduPilot. Please report here if you would like to take this on.
Well-documented port-ID assignment
Vadimfiles are intended to define the mapping between ports and their identifiers. This proposal has seen very little development so far, so I would like to encourage @VadimZ to continue on this promising path once the type signature is documented in the UDRAL doc and its first implementation deployed in PyDSDL and Nunavut. I suggest we start a separate thread dedicated to this sub-project.
A deeper inquiry revealed that the new design is not significantly inferior to v0 in terms of its bandwidth utilization. This is mostly attributed to two properties: 1. The new design provides a standard interface for turning off undesirable publications via
uavcan.pub.*.id, which is not possible with the legacy version. 2. The new design avoids large specialized messages in favor of smaller, generic, orthogonal messages, which can be published at different rates thus conserving bandwidth.
While the new design does indeed require more bandwidth to attain the same goal, the difference is not significant enough to make it unsuitable for Classic CAN networks (which are not the primary transport for this standard). For reference, this spreadsheet submitted by @Dima directly compares the v0 vs. v1 bandwidth utilization for a reasonably complex VTOL:
There is another assessment for a similar configuration done for v1 only:
While the HTML documentation generator created by @bbworld1 is not yet finished, it already provides a significant improvement over browsing DSDL files manually. Please submit feedback and change proposals on GitHub.
I started this thread to collect feedback and introduce appropriate modifications to the draft. Once this stage is completed, the draft will be merged into the main branch of the public regulated data types repository, replacing the defunct DS-015 proposal.
We need to complete the two major proposals submitted by @VadimZ: the type signature and the Vadimfiles.
Also, the physics namespace requires a review to determine whether its refactoring is necessary.