One of the primary motivations behind the Robot Operating System is helping robot creators avoid reinvent the wheel for every project. From my history of hobbyist robots, where I did build the software stack from the ground up every time, I was very happy to see the logging and diagnostics tools built into ROS.
No robot ever does everything right the first time. When things go wrong, the builder needs to figure out why. When the software stack is written from scratch, it means all the debugging tools will need to be written as well. Which means constantly asking the question: Should we build the tool? Will building it tell us what we need? Will it help solve the problem at hand? In end, will the work be worth the time investment?
When the robot system components are integrated in a ROS graph, that question goes away because ROS has the tools already at hand. There is a visualization tool (rqt_graph) to see which components are talking to each other. There is a tool that can record the messages and play them back. (rosbag) So on and so forth. The robot builder won’t have to reinvent any of these wheels.
These tools certainly looks promising and sounds great on paper, but I won’t know for sure until I build a project and try using these tools to debug my problem. I have high hopes but I’m also no stranger to things looking better on paper than in reality.
Final amusing note: The general ROS configuration diagnostic app is named WTF. (roswtf) I’m sure there’s a G-rated name for this thing (“Where’s The Failure” tool?) but we know the truth…
When it came to walking through writing actual code to build nodes in a ROS (Robot Operating System) network, the tutorial offered the reader the option to write the nodes in either C++ or in Python. I went through it in Python the first time around, then for curiosity’s sake, I looked over the C++ version for comparison.
The first glance was horrifying: Where the Python ‘talker’ sample was a small code listing with 20 lines of code, the C++ counterpart was sprawled over 100 lines of code. But a second glance quickly dispelled the impression: most of the lines in the C++ sample are comments explaining what’s going on. Comments are good! When counting the actual executable lines of code, the two samples are roughly similar in size, which surprised me as I expected the C++ version to have a lot more overhead as typical of a lower-level language.
A little reading of the comments and the tutorial page found the explanation: a lot of the tedious book-keeping that raw C++ programs have to contend with have been taken care of by Boost code libraries. This is how the C++ version of the demo ended up almost as concise as the Python version.
I still intend to continue my ROS education in Python, because I still think that’s an interesting way for me to train my Python programming muscles. But it’s nice to know that if I should ever need to do ROS coding in C++, I can get help to keep the complexities under control.
Historically I’ve been skeptical of C++ libraries – they are really wonderful when things work as designed, but when things go wrong things the code quickly become very difficult to debug. This may or may not be true for C++ code using Boost libraries, I’ll find out if I go there.
One trivial detail: the Python ‘talker’ sent out the current time but the C++ version just sent out a counted integer. Looking at the documentation of the ROS libraries, it looks like the time utility used by the Python version has a straightforward counterpart in the C++ library. Why wasn’t it used in the C++ tutorial to match the Python tutorial? It may just be simple oversight, but I wonder if there’s a more interesting story behind the scenes.
One of the items on my longtime to-do list is to investigate at least one of the publicly available robotics frameworks. Every robot project I’ve participated in so far has been a ground-up affair, everything built from scratch. At my simple hobbyist level I haven’t experienced a whole lot of tedious repetition across robots, but I definitely got far enough to see it looming on the horizon. My last robot (many years ago) was built around a very compact PC laptop as its brain, which made the project very powerful but also very expensive for its day. Today, I can get that kind of power in an inexpensive Raspberry Pi. Which happens to be one of the platforms supported by the Robot Operating System. So this is where I’m going to start.
I’m barely into the beginner tutorials but I see enough to appreciate what they have, and also to start having questions. I like the fact modules communicate over commodity network transports (TCP or UDP) and the master negotiation procedures are built around XML-RPC. It does add overhead but it’s the kind of overhead that allows a great deal of flexibility. But it is also a vulnerable security exposure. I haven’t seen anything talking about best practices to deal with rogue nodes on a ROS network but I hope that is coming up soon.
When the tutorial starts talking about writing code to create ROS nodes, it offers an option for the reader: write in C++, or write in Python? The prudent thing for me to do is to stick to C++, a language I know, while I learn ROS. If I go with Python I’ll be learning the programming language on top of learning the ROS framework.
Today I’m in a ‘chasing shiny objects’ kind of mood, so I’ll start down the Python path. Whether this turns out to be a wise or foolish choice is yet to be seen. Either way, it’ll be documented in upcoming posts!