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.

I was very excited when I learned Rhys Mainwaring created ROS software for Curio rover, a sibling of my Sawppy rover. An autonomous Sawppy on ROS has always been the long-term goal but I have yet to invest the time necessary to climb the learning curve. Rhys has far more ROS experience, and I appreciated the opportunity to learn from looking over the Curio Github repository. Here are some of my notes. written with the imperfect accuracy and completeness of a ROS beginner learning as I go.

The most novel part of Curio is obtaining odometry data from LX-16A’s position sensor with the use of a filter that recognizes when we’re in the dead zone of that position sensor and rejects bad data. I believe Rhys has ambition to extrapolate position data while within the dead zone but I didn’t find the code to make it happen. Either I missed it or that is still yet to come.

I love the goal of odometry calculation without requiring additional hardware, but Rhys ran into problems with bandwidth and a little extra hardware was brought in to help as (hopefully?) a short term workaround. While Sawppy didn’t need to communicate with the servos very frequently, Curio needed to also poll servo positions far more frequently for the odometry filter. Rhys found that the LewanSoul BusLinker board’s serial to USB bridge could not sustain the data rate necessary for the filter to obtain good data.

As a workaround, Curio makes use of an Arduino Mega 2560 to communicate with BusLinker via its 5V UART TX/RX pins, and then translating that to USB serial for the Raspberry Pi. The Arduino Mega is necessary for this role because it has multiple hardware UART necessary to communicate with both BusLinker and Raspberry Pi at high speed. I only have Arduino Nano on hand, with a single UART, and thus unsuitable for the purpose.

Curio’s Arduino Mega also has a second job: that of interpreting PWM commands from a remote control receiver, relaying user commands from a remote control transmitter. This is an alternative to my HTML-based control scheme over WiFi.

Curio’s Arduino communicates with its Pi over USB serial, using the rosserial_arduino library. Rhys has set up Curio’s Arduino firmware code such that its two jobs can easily be separated. If a rover builder only wants one or the other function, it should be as easy as changing the values of ENABLE_ARDUINO_LX16A_DRIVER  or ENABLE_RADIO_CONTROL_DECODER to trigger the right #ifdef to make it happen.

When I created Sawppy, my first goal was to deliver something that could be fun for robotics enthusiasts to play with. The target demographics were high school students and up, which meant creating a software stack that is self-contained and focused enough to be easy to learn and modify.

To cater to Sawppy builders with ambition for more, one of the future to-do list was to write the necessary modules to drive Sawppy via open source Robot Operating System. (ROS) It is a platform with far more capability, with access to modules created by robotics researchers, but not easy for robotics beginners to pick up. I’ve played with ROS on-and-off since then, never quite reaching the level of proficiency I needed to make it happen.

So I was very excited to learn of Rhys Mainwaring’s Curio rover. Curio is a Sawppy sibling with largely the same body but running a completely different software stack built on ROS Melodic. Browsing the Curio code repository, I saw far more than just a set of nodes to run a the physical rover, it includes two significant contributions towards a smarter rover.

Curio Rover in Simulation

There’s a common problem with intelligent robotics research today: evolving machine learning algorithms require many iterations and it would take far too long to run them on physical robots. Even more so here because, true to their real-life counterparts, Sawppy and siblings are slow. Rhys has taken Sawppy’s CAD data and translated physical forms and all joint kinematics to the Gazebo robot simulator used by ROS researchers. Now it is possible to work on intelligent rovers in the virtual world before adapting lessons to the real world.

Rover Odometry

One of the challenges I recognized (but didn’t know how to solve) was calculating rover wheel odometry. The LX-16A servos used on Sawppy could return wheel position, but only within an approximately 240 degree arc out of the entire 360 degrees circle. Outside of that range, the position data is noisy and unreliable.

Rhys has managed to overcome this problem with an encoder filter that learned to recognize when the servo position data is unreliable. This forms the basis of a system to calculate odometry that works well with existing hardware and can be even faster with an additional Arduino.

ROS Software Stack For Sawppy

Several people have asked me for ROS software for Sawppy, and I’m glad Rhys stepped up to the challenge and contributed this work back to the community. I encourage all the Sawppy builders who wanted ROS to look over Rhys’ work and contribute if it is within your skills to do so. As a ROS beginner myself, I will be alongside you, learning from this project and trying to run it on my own rover.

https://github.com/srmainwaring/curio

(Cross-posted to Sawppy’s Hackaday.io page)