ROS Resources: Documentation | Support | Discussion Forum | Service Status | Q&A

Call for Participation: Middleware Working Group

We’ve had several design issues come up in the past revolving around the middleware components of ROS 2, and so, to help address those and future needs, we propose to setup a Middleware Working Group to focus on these issues and try to resolve them, as well as help involve more people in the development of the packages which provide access to the communication features in ROS 2.

The Middleware Working Group’s mission is to identify and address issues with usability and performance in the core communication features of ROS 2, which are provided by the middleware (i.e. implementation of the rmw API) or one of the client libraries (e.g. rclcpp or rclpy).

This working group will focus on the core ROS 2 stack, including the rmw API and its various implementations as well as the client libraries like rcl, rclcpp, and rclpy as needed.

I’m still working on setting up a working group repository based on the ROS 2 TSC’s WG template, but I’d like to start hearing from people that are interested in being involved and/or helping with the working group. We’ll have open meetings, I’m thinking biweekly, with meeting notes posted after each meeting.

If you’re interested in participating please fill out this doodle for which times would work best for you and I’ll do my best to select a time that’s international friendly and also not overlapping with existing working groups:

I’d also like to take feedback on what the first topics for discussion in this working would be, so if you have ideas please let me know here, or if you’d prefer to wait, once I have the issue track setup for the working group I can post a link to that here and you may open an issue instead.



I notice you posted this today (June 16th) and some of the options I see for the meeting are yesterday and shortly after the post today. Was this meant to start next week?


Sorry for the confusion, I’m bad at doodle apparently. I haven’t scheduled the first meeting yet, those were just supposed to be recurring times that could work, regardless of what week it falls on. The dates are not important.


Just double checking on those times listed.
They were intentionally set at 10-12 pm pacific time correct?
Is the intention to alternate between morning/late pacific to ensure all individuals from all timezones can reasonably participate?

Yes. The early morning times for NA are often very late for Asia pacific areas. I was just trying to see what could work. I don’t plan on swapping back and forth but just seeing what people would be willing to do. It’s perfectly fine to decline such times.

I tried to pick times that worked for Madrid, Tokyo, and San Jose using this site:

So have we picked any times/dates to start?