Our robots are Hotdog-powered!

At Locus, our robots run on a popular robotics middleware known as the Robot Operating System, or ROS. ROS is an open-source project with a vibrant, ever-expanding community that spans industry and academia across the globe.

One of the common themes I used to hear in my previous life as a defense contractor was that ROS was great for prototyping, but wasn’t really something you could use in “real” applications. While their arguments weren’t completely without merit – ROS2 is itself an acknowledgment of the shortcomings of ROS – many robotics companies around the world have managed to create viable products that are based entirely on ROS.

However, the ROS distribution release cycle doesn’t necessarily mesh well with every company’s needs. The Open Source Robotics Foundation (OSRF) puts out a new distribution of ROS every year. Once that release has been cut, modifications to that release are generally limited to bug fixes; any major improvements that are merged into the main ROS code repositories are generally not released until the next distribution. While some third-party package maintainers eschew that paradigm in favor of making sure new features in their packages are available to every ROS distribution, most follow OSRF’s lead.

This model has served the community well, but its pace can be too slow for companies like Locus. A critical change that gets merged into one of the core ROS libraries won’t be available in binary form (i.e., as an installable software “package”) until the next ROS distribution. For companies with hundreds or thousands of robots in the field, such changes can make a world of difference, and so their timely release is of the utmost importance.

What can we do to get around this issue? Why, roll our own ROS distributions, of course!

At Locus, we have set up our own build infrastructure – the software and hardware that are required to turn a whole bunch of source code into binary executable packages that can be deployed to the robots from the cloud. That infrastructure allows us to use whatever versions of the ROS source code we want. So if someone makes a critical change to a core ROS component, and we’d like to roll that out on our robots, we can tell our build “farm” to start using the new software right away (pending thorough testing, of course). On the other hand, if we find that someone has introduced a bug into some other ROS library, we can either roll back to the previous version, or patch it ourselves.

What we end up with in this scenario is a set of disparate packages that span different ROS distributions. As such, our robots aren’t all running a specific ROS distribution, but a custom distribution that we tightly control, thereby ensuring maximum value for our customers. But what do we name this customized ROS distribution? If you were thinking ROS Hotdog, you were right! Also, please don’t use that name. It’s taken.

Like real hotdogs, ROS Hotdog is an amalgamation of different components. And like real hotdogs, the net result is greater than the sum of those components. Continuing on this culinary metaphor, ROS Hotdog wouldn’t be as delicio — er, amazing as it is without our “secret sauce,” that is, all of the proprietary Locus software packages that run on top of ROS Hotdog. We have improved upon or replaced a myriad of ROS packages that didn’t live up to the needs of large, dynamic warehouse environments. Moreover, we have created a slew of new applications that deliver greater value to our customers.

And the results speak for themselves.