ROSCon 2022 Recap

(Image via ROSCon website)

Hey, I’m Will, a robotics engineer here on the Polymath Robotics team. I attended ROSCon 2022 in Kyoto, Japan a little over a week ago, and wanted to share a recap of the event.

If you’re considering going to ROSCon next year, or just bummed you missed out this year, here were some of the highlights.

Thoughts on ROSCon in general

ROSCon is a smaller community as far as events go, which is great because the event feels really personal and you can custom tailor your experience to fit your needs.

The conference has invited speakers and scheduled talks, but my personal favorite are the “lightning talks,” a session of presentations chosen lottery style where people get ~two minutes to share what they’re working on. It’s a great way to broadcast an idea and find others who’re interested or feeling similar pain.

There are experts in every aspect of the industry, whether it’s manipulation, navigation, perception, build tools or the build farm, hardware acceleration, deploying to hardware, and everything down to networking and middleware layers.

I find you can really maximize how much you learn from ROSCon by knowing what talks or subjects you are most interested in and then finding the right groups to talk to.

I also appreciate getting a direct line with the vendors at the exhibition hall. Not only do you get to hear about new feature sets, but there’s also the opportunity to give them feedback and discuss some of the complexities of the problems you’re facing.

If you’re thinking about attending next year, I’d say it’s absolutely worth it, not only for connecting with the community but also for getting a read on what’s working,what’s not, and what’s “coming soon”.

The great migration … ROS1 to ROS2

Over the last couple of years, we’ve gone from ROS2 being just on the horizon, to now having fully arrived. But I was almost surprised to still hear a lot of the same questions, especially: “Should I switch to ROS2?” or “If I’m just starting, should I use ROS1 or ROS2?”

And the answer is always … it depends. Either one is probably fine, but it’s really about what works best for your application.

That said, it seemed like this year the conversation shifted from “which architecture should I use” to "wow, the change is really hard."

I had lots of discussions around migration strategies and pains – the ROS1-ROS2 bridge, methods for converting a complex system, and the feasibility of making it work with robots already in production.

After a talk from Zebra Robotics, it seemed that the victors in the migration battle (other than, of course, those who avoided it all together) were those who had the foresight and resources to prepare for a piecewise switching strategy.

Zebra took a more agnostic approach to ROS1/ROS2 by leveraging their flow_ros tool, which allowed them to decouple their pub/sub system from either version of ROS. With this topology, they had individualized control to choose which data stream would be available over which protocol. This clever trick allowed them to migrate topic by topic, rather than node by node.

Fragmentation of architectures

The ROS1 / ROS 2 discussion seems to have another effect on the industry overall: fragmentation.

For those on ROS1 and considering the switch, the next question is “which version of ROS2?”

Many groups I talked to at ROSCon have built everything on ROS2 Foxy (the first LTS version). Others started on Galactic and are now migrating to Humble, because that is now the latest LTS released.

And to make that even more complex, what version of DDS (the middleware layer) are you using? Not everybody uses the default, especially after upgrading ROS2 versions.

For instance, if a team started in Galactic, they were likely Cyclone DDS by default. If they switched to Humble (default eProsima RTPS), they might want to instead carry over a custom DDS configuration, and stay with a Cyclone DDS middleware layer.

So as I discussed different technologies and methodologies with people throughout the conference, I realized I should probably ask them what versions they’re running. Just because someone came up with a solution that worked for them, doesn’t mean that exact thing is compatible with what I’m working on. You have to consider whether an approach works with how you’ve set things up.

Tools the community is excited about

One of the cool things about ROSCon is learning what tools other teams are excited about. Some of them I knew, some I didn’t, but these were the ones that were the most thought-provoking.

Zenoh: The “Zero Overhead Network Protocol”

Zenoh was a hot topic at ROSCon this year! ZettaScale, the developer, describes the tool as “a communication middleware designed to work across communication technologies.”

While I didn’t get a chance to stop by the ZettaScale booth for a live demo, I did catch their presentation “How to Make ROS 2 Work at any Scale and Integrate with Anything” and got to chat with some of the engineers.

Zenoh as a tool has a ton of potential, but it still seems to be early days in terms of readiness.

In theory Zenoh can be used to send data over various protocols and network topologies, even directly to/from a database or lower level devices. It also seemed to describe multi-hop schemes, that make sure the data gets to its endpoints no matter what devices are in between.

The ZettaScale team has published some great examples with ROS2 using FastDDS, but I talked to a few people who didn’t have much luck getting it to connect fully in their actual applications.

This was a good reminder that no matter how much a tool might look like a silver bullet, you end up coming back to the same questions: does it work for me, and my application?

Cogniteam: a cloud-based solution that allows you to manage your autonomous robots more effectively.

Cogniteam has some solutions for managing autonomous robots more effectively, including orchestration for robot deployment using containers. To me it seemed like a cool solution for networking between a distributed system of containers, and could be used in robot development, deployment, debugging, and operation.