At the dev call yesterday we’ve been discussing the problem of data type regulation again with @scottdixon, @TSC21, and @dagar.
The conversation was revived due to the ongoing work on the standard UAV profile spearheaded by the PX4 team. Their objective is to define a reusable vendor-agnostic set of well-defined standard data types and protocols on top of UAVCAN v1.0, as we intended:
Our challenge here is to ensure that the UAV profile can be integrated sensibly into the larger UAVCAN (U for uncomplicated) ecosystem with the following objectives met:
UAVCAN-enabled hardware and software from different vendors are interoperable. This implies that the standard types are discoverable and vendors are not unnecessarily incentivized to rely on custom (unregulated) definitions.
The functionality addressed by regulated data type definitions is not unnecessarily replicated. It is acceptable and natural for a newer definition to obsolete its previous revision, but it is undesirable for the regulated set to contain multiple definitions addressing the same use case in incompatible ways.
Where appropriate and sensible, data type definitions are reusable across application domains. For example, manned electric aircraft and heavy UAVs typically leverage similar propulsion systems and power management hardware; likewise, the sensor suites of a car and an autonomous UAV may overlap. Cross-domain reusability would be beneficial for the larger UAVCAN ecosystem.
In the search for a sustainable data type regulation policy, we came up with the following options to organize the public regulated data type repository.
Segregation by owner
There will be one namespace under
regulated per vendor/project. This proposal is currently in effect and it’s been discussed above in this thread (although, naturally, it is not final, otherwise we wouldn’t be having this discussion here). I consider it the most viable among the alternatives.
Under this model, the data types that are being worked on by the PX4 team would be published under the namespace
regulated.px4 or similar. Having PX4 in the name does not imply that the types are specific to that project only; rather, it implies that they are the original author and initiator of the design.
Shall it be necessary to borrow definitions into an adjacent namespace despite everything, it should be possible to do by symlinking types or entire namespaces across directories. Remember that neither the name nor location of a type affects its wire compatibility.
Obviously, licensing issues have been considered: all regulated data types are released under the MIT license so reuse is possible with virtually no restrictions.
I would like to solicit opinions from the ArduPilot camp: @tridge @jani.hirvinen.
Segregation by application domain
There will be one namespace under
regulated per application domain. For example, the types developed by PX4 would go under
This arrangement creates obvious cross-domain reuse issues. To some extent, they may be addressed by symlinking, but the type discoverability issues persist.
Segregation by generation or some other abstract property
This is idea is new and rough. At the call, it’s been proposed to shard the
regulated namespace by a more abstract property. Assuming that we failed to come up with a well-reasoned solution now, a namespace named after no particular entity could be chosen to contain all definitions we find relevant at the moment; for example,
regulated.a. If this approach survived the initial trials, its successors could continue the trend with
This approach risks making the data type set unmanageable in the long run.
A flat structure like in ROS. For example, a particular BMS status message would go under
regulated.sensor.bms.BatteryPackStatus.1.0 (currently, it’s under
This is unlikely to work because we lack the required expertise.