New Working Group Proposal: Hardware Interface Working Group

Next Generation ROS
1

Because ROS is a federated system of packages, there are inherently more options for the packages used to combine into a robotic system. Interfacing between these packages is mostly handled by ROS messaging. Aside from a well-defined data structure to pass between independently developed nodes, there is also a need for good timing, semantic meaning of fields, endpoint behavior expectations, etc. With ROS2, it’s also possible to run on embedded devices that may also need to conform to various standards.

All these challenges have historically been addressed by those developing the packages or devices. For ROS to continue to deliver on expectations of universal interfaces, we propose a ROS Interface Working Group to address these needs. The working group would meet regularly and discuss topics related to:

• common message interfaces and related behaviors
• driver consolidation from multiple parties on the same hardware
• develop reference implementations for embedding on devices by manufacturer
• integrate/incorporate existing, applicable standards

Deliverables would be

• The above-noted reference implementations by hardware type/class
• Incorporation of relevant and existing standards
• Voice of end-user/OEM benchmarking to understand roadblocks in adopting reference implementations
• Highlight pilot ROS 2 implementations

Please provide comment below, if this sounds like a valuable initiative, or if there is something missing. Also please indicate if you are interested in participating in such a working group. As ROS-Industrial, the initial class of hardware will be industrial manipulators, but additional classes would be welcome, and collaboration on these other classes would be of value.

Thanks!

Matt R.
SwRI/ROS-I Americas Program Manager

21 Likes
2

Let’s do it! More alignment on interfaces for similar components and messages will help a lot!

3

This is a good initiative. In my experience hardware vendors often interpret the ROS common_msgs (and other related packages) in their own way to capture appropriately whatever features hardware delivers. This in principle seems harmless from the outside but ends up becoming extremely cumbersome while doing system integration because interoperability is broken and often requires a deep dive into drivers (and sometimes worse, even the robotics core logic needs to be tweeked). We experienced this heavily while building H-ROS.

Overall, +1 for it!

A few thoughts/comments that may help:

  • Rather then providing a reference implementation of “common message interfaces and related behaviors”, have you considered using a Model-Driven Engineering (MDE) approach? In other words, the interfaces will be autogenerated and interoperability tests could be automated in an MDE-centric manner (leading to safer verification paths). This was the whole idea behind the H-ROS trademark and we made a first implementation in the past funded by the European Union (ROSin) with the HRIM project (source code, paper). Source code is Apache 2.0. In addition to HRIM, @ipa-nhg has been contributing to this field as well. Her latest work presented at ROS-I Conference (Europe) showed lots of promise, specially the Theia integrations planned, which would lead to a (still developer friendly but) visual approach.

  • Hardware Interface Working Group is fine (HIWG) but the core aspect being treated is interoperability of hardware (at the software level, so technically, you’re actually dealing with both). Have you considered naming the group Interoperability Working Group (IWG)? This name in my opinion would be much more interesting for the community, and for outsiders as well (marketing-wise). Most people these days are speaking about interoperability but this is something that has been going on for many years in the community (with REPs). Some are focusing on inter-robot interoperability (i.e. different vendors), some others looking into intra-robot interoperability (i.e. among hardware components), why not grouping them both in the same WG?
    There’re quite a few interoperability projects around. Also, @mrobinson AFAIK you’ve interacted with both Mass Robotics and ARM Institute interoperability efforts. Landing all these initiatives into a formal ROS WG sounds like a good idea to me. I have privileges in the ros-interoperability GitHub org. Happy to give ownership to whoever leads the group.

  • Above you mention:

Incorporation of relevant and existing standards

Which ones?

  • One the biggest pains I encountered in the past was that comparing any two end effectors became painful purely from the spec sheets and experimental results. Have you considered adding benchmarking to the objectives and deliverables above? As a WG focused on hardware interface-ing and interoperability, you’re actually in a great position to facilitate tools and/or ROS constructs that instrument interfaces for vendor-fair-and-agnostic benchmarking. To do so I’d suggest to re-use @christophebedard’s work on LTTng integration. We did so at the Hardware Acceleration Working Group (HAWG) (see here).

  • I’m interested regardless but If you make the meetings at European friendly time I’ll try participating actively .

6 Likes
4

Great proposal Matt, let’s do it. And we are happy to look into model-driven approaches for interface generation.

3 Likes
5

@mrobinson - Tormach supports this and would be happy to participate. Please let me know how we can help.

1 Like
6

@mrobinson We have multiple active ROS based projects here at Spirit AeroSystems. We see the value in having common set of standards/best practices to help us reduce our development time. This is a great idea. Thank you for the initiative.
Bharath Rao.

1 Like
7

This is very good idea. Thinking of this as maintainer of ros2_control this is a hug things that should also influence ros2_control as current hardware gateway.

1 Like
8

Hello @mrobinson and everyone and happy new year to you all. I’d love to take part in this working group. Please count me in.

9

As someone who’s for the past three years focused on robotics integration, as leading a robotics systems integration organization - I have seen many first hand examples where the proposed work here would be of great value. Integrators end up spending quite a bit of time writing custom code to connect systems from the firmware layer and sensors up through the interoperability layers between different robot vendors. This group could develop common semantic interfaces, and allow for integrators to spend less time building connections and more time developing, improving and hardening scenarios and workflows (what end users actually care about).

Please count me in.

1 Like
10

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"

  1. semantics of individual fields as well as combinations are not always clear ↩︎

  2. @adamsj had a very nice example in the last ROS-I developer meeting where an OEM used /odom to report lat-long data ↩︎

  3. similar to how REP 145: Conventions for IMU Sensor Drivers came to be ↩︎

  4. Similar to REP 145: A Standard interface for Aerial Vehicles ↩︎

  5. <insert_your_favourite_standardisation_org_here> ↩︎

  6. 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 ↩︎

3 Likes
11

Absolutely yes :wink: , I secured it before proposing (otherwise it may have turned into a non-feasible proposal). WGs have (in general) well defined governance mechanisms. As pointed out:

2 Likes
12

I am very interested in this Matt. I belive it will be highly beneficial for all the robotics organizations like us.

3 Likes
13

Also in to contribute / take part to the discution as 80% of my work is to do integration of ROS components.

1 Like
14

I’m in! Great initiative @mrobinson!
I can provide an already established MDE solution, which would complement the formal definition of the specifications with tools for its use; tools like for example, textual and graphical editors or documentation auto-generators.

3 Likes
15

ISO TC299/WG6 has standardized “Modularity for service robots — Part 1: General requirements.”

Now this WG is discussing family standards for module-related issues, such as generic module common information model (201), software module standard (202), and hardware module standard. I’m joining to these sub-working groups. This initiative is related to the third one. If you are interested in this activity, I will contact the leader of the sub-working group.

1 Like
16

Hello, i would be interested to be a part of this working group. Do count me in. Thank you!

1 Like
17

Hello. I am interested in this working group. Please count me in.

1 Like
18

Thank you for the reply. I would like to propose to the leader to invite you to our ISO WG meeting.

1 Like
19

Thanks for all the interest! We are in the process of formally setting up the working group. Please consider joining the Google Group: hardware-interfaces-working-group@google.groups.com. It is open for anyone to join. This will enable efficient distribution of meeting invites for all participants.

Thanks!

Matt R.
ROS-I Americas

1 Like
20

Looking to set a kick off meeting:

Deleted old poll link

Looking forward to nailing down the scope!

1 Like