Some thoughts from my side.
One of the first orders of business could be to make sure the name accurately reflects the goal(s) of the WG. Even in the small sample size we have here on ROS Discourse, there is already some confusion, and it would be good to address that.
Second, the word Hardware is in the proposed name as the initial goals would be to try and address the ambiguity that a few commenters here have already described – and which has mostly surfaced when interfacing with ROS drivers, which are the parts of ROS applications which talk to hardware.
Ambiguity at the message level [1], ambiguity at the ROS API level [2] and ambiguity beyond individual msgs, svcs and actions (system-level behaviour related to/instigated by information coming in over ROS-like interfaces). Especially the behavioural side should be formalised I feel.
Using an MBSE approach would certainly be interesting (to make things not just clearer for humans, but also for machines).
And as it comes up every now-and-then on ROS Answers and other venues, a good first step would be to draft a couple of (almost) retrospective REPs [3] which formalise the de-facto standards (topics, message types, semantics and behaviours) which exist for camera drivers, mobile platforms, navigation stack compatible systems and things like industrial manipulators [4].
Finally, to respond to @vmayoral’s question: “which relevant and existing standards?”
I would say that’s exactly why this working group should be created. Which standards indeed?
The descriptive side of the WG’s tasks is documenting what we currently have and use.
We can be prescriptive in certain cases (ie: this is how you are expected to behave as a ROS component in category X).
But in many cases, I would personally try and find existing relevant ISO/IEEE [5] standards and then it would be the WG’s responsibility to find a mapping between those standards and the ROS ecosystem (both conceptually as well as concretely (ie: msgs, svcs, actions and nodes if needed)) .
I expect this to save us time, avoid coming up with fragile first attempts at standardisation and most importantly it should facilitate integration of ROS applications (and systems) with everything non-ROS (but still standardised) [6].
How successful this will/can be will of course have to be seen.
Success would be entirely dependent on contributors who are exposed to standards in the context of their work with ROS, as it will be impossible for any one individual or organisation to be aware of everything, have experience with everything (at the level needed) or do all of the work.
Edit:
Did you create that for this post?
created_at: "2022-01-12T07:56:34Z"
semantics of individual fields as well as combinations are not always clear ↩︎
@adamsj had a very nice example in the last ROS-I developer meeting where an OEM used
/odomto report lat-long data ↩︎similar to how REP 145: Conventions for IMU Sensor Drivers came to be ↩︎
Similar to REP 145: A Standard interface for Aerial Vehicles ↩︎
<insert_your_favourite_standardisation_org_here>↩︎Some examples of this approach would be PackML (ros-industrial-consortium/packml and ros-industrial/packml_ros2) and things like New package to bridge ROS2 with Mass AMR Interoperability Standard ↩︎