This is probably the biggest immediate problem I have with embracing UAVCANv1 for the wider ecosystem right now.
I understand the flexibility in untangling the combined data type, subject, and ID (/priority) we had in UAVCANv0, but I struggle with the jump to it being so free-form like in differential_pressure_sensor demo or subject names coming from comments in service files (eg air_data_computer).
Can we find something in between those extremes combining the type safety and simplicity we enjoy with current UAVCAN with respecting the UAVCANv1 interface guidelines (no fixed port IDs, etc)? It seems to me for the majority of the usage we actually need we should be discussing things at the level of a simple directory of subjects (mapping to data types).
Simple map of subject name to type
- port id would come from a known register naming convention using the subject name
- resolves type safety issues
- port id could even have acceptable defaults in many cases (I know this might be contentious)
- code generators could directly consume this and produce libuavcan style Publisher and Subscriber helpers that have things like the port id from register part handled automatically
- this could be extending the existing services idea, but digestible by tooling, and probably the goal of each service being much simpler/coherent at least at the start