Define and Utilize Domain-Specific Namespaces

[opencyphal]

Define and Utilize Domain-Specific Namespaces

[thirtytwobits]

I added this issue so we can capture debate but the more I think about it the less I feel like this is a useful proposal. For example, what do we do about types that are general to several of the domains? For example: a camera gimbal is something all of the imagined vehicle types might support. Along those lines it seems more like the differences would be outliers.

Another example: air data is pretty specific to aircraft but fast moving autonomous cars might use such a sensor.

[kjetilkjeka]

I like this idea. What I like about it tis that it attempts to make uavcan more suitable for general robotics or even simply just more general use. We should do so without sacrificing any niceness when used in flying robots (multicopters, planes, etc).

Let me first try to put words on what i found difficult when attempting to use uavcan for other things than flying robots:

• The support for custom dsdl is worse than for the standard definitions. (This has improved with the gui tool begin able to read custom definitions).
• ESC is a (in my opinion) slightly weird term that only exists in the hobbyist uav/e-skate segments. More general terms exists, and would make using this type of message more intuitive.
• There are no organic place to put things like a wheel speed sensor. And a general position sensor message doesn't exist.

---

To attempt to build further upon your suggestion I think we should also consider to split the core namespace in message types that are required for the protocol to work (GetNodeInfo, GetDataTypeInfo, NodeStatus, GlobalTimeSync, Panic, RestartNode + dynamic node ID stuff) and things that can be considered util (File, debug, etc). We should probably have (at least unofficially) stronger stability guarantee on the core stuff.

For example, what do we do about types that are general to several of the domains?

We will probably not be able to put everything in categories of domains. If we attempt to group functionality first, then we can extract out functionality only relevant for one domain. I would like to throw out the following as a basis for further discussion.

• protocol - similar to @thirtytwobits core ( we can alternatively expose these sub categories on the highest level)
  • core - definitions (almost) required for the protocol to work
  • file - same as "uavcan/protocol/file"
  • debug - same as "uavcan/protocol/debug"
  • tunnel - same as "uavcan/tunnel"
  • parameter - same as "uavcan/protocol/param"
• time - for Timestamp etc
• vehicle - everything concerned with a physical entity.
  • navigation - Needs to be made quite general to fit different crafts and frames.
  • air - similar to "uavcan/equipment/airdata" perhaps generalize to include water speed sensors etc
  • aircraft - similar to @thirtytwobits suggested aero
    • flaps - Not suggested to be added, just as an example.
  • watercraft - similar to @thirtytwobits suggested marine
    • anchor - Not suggested to be added, just as an example.
  • ground_vehicle - similar to @thirtytwobits suggested ground
    • wheel - Wheel speed sensors, tire pressure, etc
  • equipment - equipment agnostic of domain etc
    • actuator - both "uavcan/equipment/actuator" and "uavcan/equipment/esc" should be somehow united under this umbrella
    • camera - gimbal and trigger related things.
    • ice - Internal combustion engine.
    • attachment - similar to "uavcan/equipment/hardpoint"
    • sensors - Generic sensors that doesn't have a more specialized message. Temperature, pressure, position, etc
    • etc

[pavel-kirienko]

I think we should also consider to split the core namespace in message types that are required for the protocol to work (GetNodeInfo, GetDataTypeInfo, NodeStatus, GlobalTimeSync, Panic, RestartNode + dynamic node ID stuff) and things that can be considered util (File, debug, etc).

There is only one thing that is required for the protocol to work: uavcan.protocol.NodeStatus; everything else is util, and I don't anticipate this to change. I don't think we should introduce an entirely new concept of core data types just for the sake of one data type.

A positive side effect of getting rid of DSDL signatures in the new specification is that now we're going to be able to move data types around while retaining backward compatibility. This should help with the upcoming restructuring of the standard data type definitions.

[thirtytwobits]

Your "ground_vehicle" example exposes more of my concern about my own proposal: i.e. many airplanes have wheels :)

While I think there's room to cleanup the "equipment" namespace what's most important about this issue is the need for the specification and implementations to allow for a vehicle system to configure only the standard types it wants and easily support custom types. Given the limited number of messages and services this capability is essential to the long-term utility of this specification.

As such I think there are three buckets that are obvious:

1. NodeStatus – i.e. "core" since Pavel has pointed out that it is the only required message. This might be more clear if it did live in its own namespace.

2. utility – Stuff like dynamic node allocation, debug, firmware update, etc. Most everything under "protocol" in v0. We should make it clear that this is a smorgasbord that a given vehicle system can choose from.

3. equipment – Standard types we provide to support a COTS ecosystem. We should be clear that a vehicle system does not need to adhere to nor support these types to utilize the specification, its implementations, or the associated tools.

[pavel-kirienko]

I am inclined to agree with Scott – keeping domain-specific data type sets completely orthogonal would be challenging if not impossible. Therefore, as Scott said, we should focus on restructuring the existing set rather than adding domain-specific namespaces.

While I don't see much value in adding a dedicated new namespace for the sole required data type, if you both think that's useful we can do that. Preferably the name of the namespace should be self-explanatory to avoid introduction of new concepts into the specification. Perhaps required works? Or is core sufficiently clear?

Do we want to create a new namespace for COTS applications (aptly named cots) to contain non-equipment-specific data types, such as GlobalNavigationSolution? E.g. uavcan.cots.navigation.GlobalNavigationSolution, uavcan.cots.equipment.actuator.Command.

Looking at the quickly growing set of drastic differences compared to UAVCAN v0, I am beginning to think that it would be much easier to abandon backward compatibility with UAVCAN v0, and instead require nodes that must support both v0 and v1 to carry two independent implementations of the protocol, switching between them at runtime according to their configuration. This approach would enable v1 implementations to get rid of the no-longer-needed data type compatibility enforcement logic and avoid the standard data type set compatibilty issues.

[pavel-kirienko]

Closing as this question has lost relevance