Naturally, enforcing an exact port name is not possible because in that case, different service specifications may conflict with each other (e.g., a servo service also has a
statussubject). Hence, implementations are to be allowed to add arbitrary prefixes before the port name.
@pavel.kirienko can you elaborate on this? My understanding here is that you can enforce it if you use and enforce proper prefix to the port ID as well, if you make it specific to the service. This argument doesn’t seem to reasonable in my view.
a standalone developer is likely to adopt this approach of grouping registers independently even if it is not explicitly documented anywhere because it just makes sense .
Sorry but you cannot assume this. Also, why the naming of primary and secondary and not indexes? What do you do if you have multiple servos? What prefixes to you expect? Why not indexes? How do you expect that the autoconfiguration handles a situation like this? A servo is left, right? What if you have multiple different servos in more exotic configurations?
In any case, the fact that you state, and I quote:
For UAVCAN, the prospect of providing rigorous machine-readable network service definitions has been explored in the past, and it is, in fact, something that is likely to be worked on in the long term, but it is not manifested on our roadmap in any concrete terms yet. Such automation is a highly complex feature that we will not be able to commence any work on until we have is a solid empirical base, which means that it is at least years away from now.
Just makes clear that we far from being aligned on the overall requirements that are expected to be fulfilled in the PX4 side and the stakeholders involved. The Pareto principal is only applicable if you actually answer to what people are requesting to exist and if that subset composes a solution that is applicable to the end systems in the way that is expected by the end user to be, not the way you think it should be. If the argument here is that UAVCAN v1 should be similar to what ROS is, I am sorry to disappoint you but no one asked for a distributed network that mimics ROS. Or in the other hand, you can architect UAVCAN v1 whatever way you want, but in the end if people don’t see the value of moving from v0 and even see the UX being worse than before, they won’t pick it up, and this will be more an academic research than a productizable protocol.
Defining a semantic port grouping solution but still don’t have a way of programatically define it as a standard, at this stage, doesn’t answer what we are looking for. If that’s something, as you said, that would take years to be implemented, then we will have to find solutions ourselves to our needs and leverage the existing tooling to build an higher level network service definition that can actually be defined on code and that provides the enough helpers to people actually pick it up.
We are currently working on an architecture document with a aim to provide a sequence of tooling inputs and outputs that will allow us to properly define the network services, also following the conventions you are proposing. The primary/secondary… naming should be reviewed though.
@dagar, @PetervdPerk FYI.