(Hardware) Interfaces Working Group Kick-Off Meeting

We are excited to share that we have settled on a day to officially launch the Hardware Interfaces Working Group, and have scheduled a kick-off meeting for this Friday, March 18.

The meeting info is below. We will want to discuss scope, what would be likely outcomes, and how we want to manage the working group.

I understand there may be some that this time does not work, but we will be sure to revisit the charter elements (scope, outcomes) at the next meeting as well, to ensure we get all the feedback we can.


Matt R.

Topic: ROS 2 Hardware Interfaces Working Group Kick-Off
Time: Mar 18, 2022 09:30 AM Central Time (US and Canada)

Join Zoom Meeting

Zoom Video

Join our Cloud HD Video Meeting

Zoom is the leader in modern enterprise video communications, with an easy, reliable cloud platform for video and audio conferencing, chat, and webinars across mobile, desktop, and room systems. Zoom Rooms is the original software-based conference…

Meeting ID: 879 0965 0725
Passcode: ros-hwwg
One tap mobile
+13462487799,87909650725#,*57082473# US (Houston)
+16699006833,87909650725#,*57082473# US (San Jose)

Dial by your location
+1 346 248 7799 US (Houston)
+1 669 900 6833 US (San Jose)
+1 253 215 8782 US (Tacoma)
+1 408 638 0968 US (San Jose)
+1 646 876 9923 US (New York)
+1 301 715 8592 US (Washington DC)
+1 312 626 6799 US (Chicago)
Meeting ID: 879 0965 0725
Passcode: 57082473
Find your local number: Zoom International Dial-in Numbers - Zoom


Meeting has just started!

Join via the Zoom link in @mrobinson’s post.

Thanks to all that attended. For the minutes from the HWIWG please see the link: HW Interface Working Group Kick Off-Minutes-031822 - Google Docs

We would like to set up the bi-weekly meeting, NOT on Fridays. Complete this poll: Doodle

I will get the invite out by COB (Central US time) Tuesday March 22.

Oh, I also added the slides shared here: Hardware Working Group-KO-March 18.pdf - Google Drive


Please respond to the above link if you are interested in participating in the HW Interfaces Working Group. I would like to get he recurring meeting out this week.



Oh, I just saw there was a meeting last week… sorry for missing out. I hope we add this into ROS calendar, so we all have it automatically integrated. Has someone already contacted @Katherine_Scott about that?

I just saw that there is interest to include functional safety related information in a structured way in ROS. I am very interested about that, especially in terms for ros2_control and hardware drivers supported there. We don’t have currently clear idea which data are usually needed and how it should be integrated, but we have many users working on integration of new hardware, and they are asking us about regularly about that. In my (biased) opinion, providing specification for functional safety information in ros2_control would probably have the biggest impact at the moment. @johnwason (I hope this is the right handle) please let me know if you would like to discuss this outside of the WG just to clarify each other’s ideas.

@mrobinson should have calendar access now. He can edit / update meeting times for the working group.


Thanks for posting and yes, I had contacted Kat per feedback from others, so there is now a spot on the ROS Calendar! I need to sort out how to edit/tweak and get others on the invite, but we will hopefully see greater awareness moving forward and of course the day before I will send a reminder out via our ROS-I/Discourse comms channels.


Matt R.

@destogl @mrobinson

I think it would be valuable to explain what I am hoping to achieve with my participation in this wg. I will try to be concise…


I develop Robot Raconteur (GitHub - robotraconteur/robotraconteur: A communication framework for robotics and the Internet of Things, developed by Wason Technology, LLC), an augmented object-oriented middleware, and PyRI Open Source Teach Pendant, a Python, browser based teach pendant (GitHub - pyri-project/pyri-core: Python Restricted Industrial (PyRI) Open Source Teach Pendant Core Package). These projects can be used with ROS, but they are often used standalone. Robot Raconteur began when I was a graduate student at Rensselaer Polytechnic Institute in 2010, and I have been continuing to develop it since then. Over the last few years RPI and I have received funding from the USA ARM Institute and New York State, with support from SwRI, GE, and Raytheon. Video on Robot Raconteur: Plug-n-play robot software coordinating robots and sensor from multiple vendors. - YouTube . The PyRI teach pendant began recently as another ARM project supported by the same team.

Robot Raconteur has a number of significant advantages over RMW, the biggest one being its plug-and-play capability. The full description of the plug and play capability is out of scope, but can be discussed elsewhere if people are interested. One important component to the plug-and-play capability is the standardized interfaces for hardware devices that were developed during the ARM project. These standardized interfaces can be found here: robotraconteur_standard_robdef/group1 at master · robotraconteur/robotraconteur_standard_robdef · GitHub . The most important one for this discussion is the robot standard interface: robotraconteur_standard_robdef/com.robotraconteur.robotics.robot.robdef at master · robotraconteur/robotraconteur_standard_robdef · GitHub . We had a number of different drivers already developed before the ARM project, but not standardized, so during the project we improved existing drivers and developed a few additional ones to conform to the standard. Unfortunately COVID hit at a bad time, so not all of the drivers were completed. A list of different available components: GitHub - robotraconteur/robotraconteur-directory: Directory of device drivers, applications, utilities, examples, and documentation projects for Robot Raconteur . One of the more interesting repositories contains a Gazebo based training simulator to interact with a few standard robots: GitHub - robotraconteur-contrib/robotraconteur_training_sim (at the time of this post there is a problem with the conda install, we are working on it…)

The PyRI teach pendant builds on top of these standard interfaces, and can control any standard robot and standard camera. We are working on expanding capability over time. A video on the teach pendant: Open Source Teach Pendant Jog, Save, Playback - YouTube

Robot Raconteur and PyRI can be used in the ROS ecosystem, and I am currently working on including them in the ROS package repository. The core Robot Raconteur package has already been accepted into Noetic, and over the next few months I will continue to work to have the components include in ROS 2 distros.


Feedback from industrial partners is they are looking for functionally safe components going forward. The drivers I currently have are not functionally safe or hard real-time. My plan is to begin work on drivers written in C, able to be embedded in kernel-mode or RTOS, and be functionally safe. My goal is not to have them certified immediately, but to develop them in a way that they can be certified over time.

@mrobinson mentioned that it would be worth combining efforts, since developing and maintaining these backends can be challenging and time consuming. If these drivers are written in a modular way, then I will be able to use them and contribute to the development.

@destogl unfortunately I haven’t been able to use ROS control because it doesn’t separate the lower level libraries from the communication layer, so I haven’t done much work with the project.

I have very limited knowledge of functional safety, so I will be learning as needed. This development effort is a medium-term project.

I am also interested in the standardized interfaces for use with the PyRI teach pendant. Right now we have been using proxy drivers to communicate with ROS devices, since each device has its own message interface. For instance, the Rethink Sawyer robot driver wraps the ROS communication and translates from the standardized RR interface to ROS topics: SawyerRobotRaconteurDriver/SawyerRobot.cs at master · robotraconteur-contrib/SawyerRobotRaconteurDriver · GitHub . It would be very helpful if ROS drivers all had the same interface so we didn’t need to maintain individual proxy drivers for each device.

The standard interfaces we have developed may be useful for the developing standardized ROS interfaces. We did reference ROS message types when developing these interfaces, but they are not identical.

As was discussed in the last meeting: if there is sufficient interest around functional safety, this could be given a place in the working group.

I’d suggest to form a committee with other interested working group participants and report on progress during the group meetings.

As standardisation is much too broad to have ‘everyone work on everything’, it is expected multiple parallel efforts will take place, with the meeting group meetings offering a venue to connect back and synchronise with other efforts.

As past experiences have shown us, trying to align all participants and address one topic at a time does not work, and tends to result in loss of engagement. With working groups being as small as they typically are, that’s something we should try to avoid.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.