Hello ROS community,
Every year, as part of the development for the next ROS 2 release, Open Robotics puts out a roadmap detailing what the core development team is going to work on. That roadmap, along with roadmap items from other TSC members, can be found here.
This year, the OSRC team at Intrinsic plans to do something slightly different. Rather than address a myriad of different tasks, the team is going to take on one very large task: the development of a non-DDS RMW implementation.
If you aren’t familiar with the concept of an “RMW”, it stands for “ROS MiddleWare”, and is the API that sits between the client libraries (i.e. ROS code) and the underlying communication mechanism (there’s a diagram of this layer here). The RMW interface is an abstraction layer that allows ROS to swap out its underlying communication mechanism at both compile and run time. As long as an RMW implements that API, it can be used as a communication mechanism.
Each RMW is assigned a ROS “support tier” roughly based on code quality and the amount of integration testing performed on the RMW. There are currently three Tier 1 RMW implementations, all of which are based on DDS and are tested nightly:
But others have created other RMW implementations over the years:
This brings us back to the development of what we are calling “rmw_alternate” (for now). Currently, all of the current Tier 1 RMW implementations use DDS, which means that DDS specific details can sometimes bias the RMW API. Further, DDS struggles in some situations, particularly where multicast UDP might be disabled or other network restrictions are in place (such as one might find in an office). We’ve also heard feedback from some members of the ROS community that DDS can be overwhelming and complex. rmw_alternate is meant to be an alternative for those who can’t or don’t want to use DDS, and aims to deliver a better out-of-the-box solution for educators and hobbyists.
I’m going to stress that DDS will always be part of ROS 2. Certain parts of our community use ROS 2 because it is based on DDS, and would not be able to use a different RMW. But having an alternative Tier-1 RMW implementation will help ensure that we don’t bias the RMW API with DDS details, and will give people who are struggling with DDS issues another path to take. Note that we are not targeting this to be the default RMW at this time; only another available option.
What does this mean for all of you?
We are purposely calling this “rmw_alternate” because we haven’t yet chosen what the underlying communication mechanism will be. What we want to hear from the ROS community is how you are using ROS 2, the issues you are facing, and what things you think would make your experience better. We want to generate our rmw_alternate requirements directly from feedback from the ROS community. To capture that feedback, please take the time to fill out this survey, which should take about 10-15 minutes. The responses will be anonymous, and we’ll leave the survey open for approximately 2 weeks.
We’ll use the data from this survey to come up with a list of requirements, and see how well the individual middlewares fit those requirements. Once we’ve chosen a middleware, we’ll spend the bulk of our Jazzy development time working on the new RMW.
If you have questions or comments about any of this, please feel free to respond to this thread.