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…