I think the following would be a nearly equivalent restatement of your proposal: you suggest to introduce a new namespace under regulated dedicated to data types that are considered sufficiently stable and generic to be recommended by UAVCAN maintainers for cross-domain use. When you say that such types have to be developed by expert working groups, that seemingly implies that the types have to survive early testing somewhere outside of the regulated set. Following the example of vendor-specific CSS extensions, we could combine segregation by device class with segregation by the vendor. I think this model would be easy to explain to everyone who has at least cursory familiarity with CSS.
Suppose we retain segregation by owner as described in my previous post and introduce an additional namespace for such expert-defined namespaces, which we could name regulated.endorsed (a shorter name is needed perhaps because weâre limited to 50 characters per full type name but I couldnât come up with a better word yet). Once a particular namespace is deemed adequate for inclusion into the endorsed set, it is either moved there from an owner-specific namespace such as regulated.px4, or just symlinked directly. The idea of introducing base types first also seems very sensible and can be implemented here as well, such that the endorsed set supplies only the most vital functions, and owner-specific types can extend it as necessary. The endorsed set can also subtype its own definitions to support different degrees of generality, such as in your BMS light/heavy example.
Should we keep going in this direction?
Iâm not sure I agree with the GetInfo idea because a single device may implement multiple profiles. We could allow devices to report several profiles at once but it seems like another major can of worms that is perhaps best kept sealed until some other day.
Edit: the scope of the endorsed set should extend beyond just standard function nodes and also include common concepts that are frequently referenced in various robotic and vehicular systems, such as various mechanical conventions (e.g., twist, pose), electrical conventions (e.g., DC power), optical (e.g., camera image, point cloud), and so on, that are not necessarily grounded to a particular piece of equipment.
Edit edit: in line with the above idea we may consider moving uavcan.si into regulated.endorsed.si.
I donât like âendorsedâ because it will be strange to have deprecated types under endorsed in the future but we donât want to change the namespace when a type goes into deprecation. Similarly, when we have multiple versions which version is âendorsedâ.
As for the need to âbakeâ APIs, I agree this is a great plan but to get the standard started we should allow a v1 set of types that are proposed by experts but which are allowed before field-testing. As the standard sees greater adoption and deployment we can improve this process for future revisions of the types.
Regardless, it seems from your response that you do not like my proposal as presented?
I think what you described makes sense, I merely attempted to generalize it further. I think there might be cases where segregation by device class only might lead to undesirable over-specification.
Consider a battery management system. The key reported property here is the amount of energy available in the battery which is used for the endurance estimation; the kind of the energy source is in most cases irrelevant for the consumer. Similar messages can be applied to other on-board energy sources beside batteries, from fuel cells and turbogenerators to nuclear reactors. In this case, one might want to abstract the core physical process (power delivery) away from the particular means facilitating it (battery, turbogenerator, fuel cells, etc).
Under that example, the namespace that segregates definitions by the type of the physical process would define a message containing a few fields like the timestamp, current, voltage, available energy, and the total energy. A message specific to a battery-electric vehicle (like a typical light UAV) would inherit from that and add BMS-specific fields like cell voltage and so on. Another message specific to a turbogenerator would add RPM and fuel levels, etc.
Thus the name we chose for that sub-namespace should be generic enough to allow for different segregation criteria. If endorsed doesnât fit, we could consider regulated.uavcan unless there are other proposals.
Am I making sense here or did the conversation drift too far from the original goals? I think the key problem with the segregation-by-vendor approach is that some adopters might be reluctant to rely on definitions authored by some other parties for various non-technical reasons. I suspect that a particular open-source autopilot team might be particularly hard to persuade to adopt data types residing under the namespace named after another open-source autopilot project, if you catch my drift. By endorsing particular well-established interfaces we could act as a mediator here. This is not even a technical problem weâre solving here, if you look at it this way.
Any scheme will be subject to the infallibility of humans but the class-based scheme, as proven by USB itself, allows for mistakes to be corrected by defining new classes and deprecating old ones.
For your BMS example, the type could have a concrete baseclass that is generic. Certain systems would only require/consume generic BMS subjects but more specialized systems could extend this type to require more advanced subjects be present.
Iâm fine with regulated.uavcan. I think we discussed this in the past but thought that having uavcan.foo and regulated.uavcan.foo might be confusing however I think this is tolerable.
Are you saying that there may be classes that describe more abstract entities than a particular type of device? For example, may there be a class for âpower deliveryâ, which could be further specified as âbattery power deliveryâ or âfuel cell power deliveryâ?
Yes, thatâs exactly what I meant.
Seeing as neither of us are quite happy with the name, we should keep this question open for now, having regulated.uavcan as the fallback option.
To recap todayâs call: @lorenz.meier believes that the policy of segregation by owner may cause issues because the adopters will probably fail to recognize the interoperability benefits offered by UAVCAN. He is in favor of segregation by application domain, where the problem of limited expertise is to be addressed by well-organized working groups.
The two approaches do not necessarily have to be mutually exclusive. A (sub-)namespace proposed by a vendor could be symlinked directly into a domain-specific namespace as necessary.
This a somewhat half-baked idea, but maybe Iâll throw it here:
How about allowing type definitions to be âcontent addressableâ by hash, similar to what unisonweb.org is doing for code ?
This way vendor A would should have no qualms in copying the type of vendor B, calling it a different name but still be interoperable.
(this this doesnât address the issue with structurally identical types with different semantics, but maybe this can be resolved by a very minimalist list of âcompatible typesâ rather than screaming all over the codebase âIâm importing competitorâs codeâ)
Unison is an interesting thing but I canât immediately see how its ideas can be applied here. For now, we decided (at yesterdayâs dev call) to adopt the segregation by application domain where the issue of competence is addressed by the dedicated UAVCAN Drone SIG, which may be followed up by other SIGs in the future. We are going to see if it works out or not.