When learning something new, I always find it useful to find a part that I could use as a foundation. Something I can use to build my new information on top of. I had trouble finding such a foundation for ROS as it was such a big system. So it was a great gift to have the chance to look at Rhys Mainwaring’s ROS stack for Curio rover, a sibling of my Sawppy rover. This meant the rover I designed and built was my foundation for learning Curio’s ROS software stack.
Such a foundation was less critical when I had explored Curio’s interaction between Arduino Mega and Raspberry Pi. But it was very useful when I explored how command messages were sent around inside the system. This was built using
ros_control, a set of ROS packages that help abstract the concepts of robot motor control from the actual details of motor controller commands.
The promise here is allowing a robot builder to swap around different motor controllers without changing the logic about how a robot would use those motors. Conveniently, Sawppy has both of the basic categories: “Joints” specify a position, and that fits Sawppy’s four corner steering servos. Whereas “Transmission’ specify rotational motion like Sawppy’s six wheel motors.
The idea of abstracting motor control from implementation is common, I even had a primitive form of it inside SGVHAK_Rover software allowing us to hack a servo into a RoboClaw placeholder, and later adapted to Sawppy’s LX-16A serial bus servos. The power of such abstraction comes when it becomes open and flexible enough for software modules implementing either side of the abstraction to be reusable beyond its original author’s use. That certainly was not going to happen with a homebrew pack of servo software, but a convention in ROS is a different story.
Which is why I was puzzled to learn
ros_control does not appear to be in the works for ROS 2. It is absent from the index, and I found only a discussion thread with no commitment and this page with a dead link. I thought
ros_control would be a fundamental part of the platform, but it is not. Its absence tells me there’s an important gap between my expectation and ROS community’s actual priorities, but I don’t know what it is just yet. I’ll need to find its successor in the ROS2 ecosystem before I understand why
ros_control is being left behind.