by Evan Bretl.
Our RoboCup team is in the middle of a major software re-organization, re-writing key parts of their software stack in order to leverage ROS 2.
What is ROS?
According to Open Robotics, the organization that created the software, “The Robot Operating System (ROS) is a set of software libraries and tools that help you build robot applications” (from https://ros.org). The core libraries of ROS implement a message-passing system for cross-platform inter-process communication. ROS has recently undergone a major update from ROS 1 to ROS 2, offering better performance for real-time applications. RoboNav and RoboRacing both use ROS 1, as they have for years, but plan to update to ROS 2 soon.
This integration of ROS into the RoboCup technology stack is not simply a light refactoring of a few bits of code — it changes the whole software architecture. This begs the question of why it’s worthwhile to undertake such a project.
Firstly, using ROS simplifies a complex part of RoboCup’s code base that deals with multi-language support. RoboCup programs their high-level strategies (such as running coordinated team plays) in Python, while they code their motion planning and controls in C++. Using ROS 2 for inter-process communication greatly simplifies the problem of communicating between these two systems. The previous “bridge” code between the two added a lot of maintenance overhead for the team and was difficult to explain to new members. ROS’s distributed message-passing system, by comparison, is much easier for new members to learn, and experienced members of the team don’t have to maintain it as an added project.
Second, it allows for more knowledge sharing between RoboCup, RoboNav, and RoboRacing, as all three teams use ROS. RoboCup has support from other teams during the code migration, and software training for new members can now be combined for the three teams not only for C++ concepts, as in the past, but also for ROS concepts. For years, RoboNav (IGVC) and RoboRacing have been co-developing training materials and sharing technical expertise with one another to greatly improve the technical teams’ experience on both sides. Including RoboCup in this relationship will increase the strength of RoboJackets’ software teams together, building on the foundation established by RoboNav and RoboRacing.
For all its potential upsides, this project is no small undertaking and will reshape RoboCup’s entire software architecture. Team member Kyle Stachowicz is leading the migration effort, which has been making steady progress in recent months and is nearing completion.
In the old architecture, all of the software modules share a global state called Context, and the overall program flow is coordinated by the Processor module. This kind of system architecture (the kind with lots of shared global state) can have very good performance, but is notoriously hard to maintain, debug, and test.
By contrast, migrating to ROS allows for a more modular software architecture. By passing messages between different parts of the stack, these different modules of the overall system no longer need the shared Context state. Each module or sub-group of modules has well-defined inputs and outputs, and its behavior can be tested and monitored independently.
The migration to this new architecture has required heavy refactoring of the code base, mostly on the autonomy (C++) side of things. But the payouts, from ease of development and training, to better modularity, to knowledge sharing with other ROS teams, promise to be worth the effort.