ROS: Good, bad and ugly

I don’t think this cool little bot uses ROS. Photo CC-BY by langfordw.

At work, we use The Robot Operating System is some parts of our software. ROS is a software framework for building robot applications. There’s a message passing system with C++ and Python implementations and a bunch of ready-made robotics modules and hardware wrappers that use the message passing system.

We’ve now used ROS for a while. It has been a success in some regards, but also a source of frustration. Below I’ll look at some of the issues.

This post is about the core of ROS. A major selling point for ROS is the ecosystem of existing modules. We use almost none of them, so I can’t comment on their quality.

The good

The message passing system itself is nice. It’s based on publish-subscribe channels and works over TCP. There’s a protobuf-style serialization format, a server for channel discovery (rosmaster). There are also command-line tools for inspecting, recording and replaying the messages.

Adopting a message passing system was a great idea. It’s now easy to write new nodes, because there’s an easy and flexible way to communicate with the existing system. Inspecting a running system by looking at the message streams is handy, and you can also use the same tools to look the recorded messages.

You could build a message passing system of your own, but it’s nice to find an integrated package.

The bad

ROS is very framework-y. It comes with its own build system and a tool for running the applications developed with it (roslaunch). In theory, you do not have to use them, but ROS is pretty much built around the assumption that you do. Retrofitting ROS communication into an existing applications can be painful. Prepare for yak shaving.

We’ve also had problem in building robust long-running systems with ROS. There have been resource leaks and thread safety issues and we’ve had problems with handling failures like rosmaster dying. I have a feeling that this might be because there aren’t that many ROS users building systems that actually need to be robust.

The ugly

There’s an unofficial, unmaintained Java port. The resource leaks were so bad that we simply stopped using it.

Should I use ROS?

If you’re considering ROS for a small project, like a school project, go for it - especially if you can leverage the third-party modules for ROS. You will get a lot of handy stuff pre-made and likely the bad bits won’t bite you.

If you’re considering ROS for a bigger project, do your due diligence. Are you able to deal with robustness issues if they come up? Is supporting C++ and Python enough? The ideas behind ROS are good but not unique. For a long-term project, handling problems should be a bigger issue than getting stuff “for free”.

Comments or questions? Send me an e-mail.