Robot Operating System for the DronebotWorkshop Builders. Part 3

Just a quick update today about something that caused me more stumbling and fumbling than I care to admit.

Today we are going to into the history of ROS to help understand why something which seems simple can be a bit complicated.

If you have been following along, you will have noticed I rambled on about abstracting parts of a large robot project into nodes which use messages to pass information between themselves. You might have thought to yourself, that is just classes. We have been working with those that since Smalltalk in 1972.

There is a ‘yes. but…’ ROS is designed as a Distributed System. Rather than having a single computer manage everything, ROS allows you to spread the system across multiple computers.

Historically, in the mid 2000’s when ROS was designed at Stanford University, state of the art research robots consisted of a laptop strapped to a vacuum cleaner. The onboard laptop was capable of running some basic nodes. More complex processes were sent via WiFi to nodes running on workstation which were capable of greater computation.

802.11a WiFi with its blazing speed of 54 Mbit/s was common. WiFi dead spots were common. Sensors, like cameras, spew out data like a fire hose. A lot of the early effort was directed at managing data flow across slow and unreliable connections between nodes.

Modern robots are also modular. They often consist of several Arduino like microcontrollers, one or more Raspberry Pi like single board computers (SBC) and one or more GPU based boards for heavy processing.

This is done to allow the motor control and encoder processing to run in a very tight loop on dedicated yet inexpensive processors. This enables near real time processing for these elements. Sensor processing and planning which are less time critical are run on separate systems.

As you read the documentation you will see a nearly obsessive emphasis on ‘messages’, ‘topics’, ‘publishers’, and ‘subscribers’. On many modern systems we have grown to expect this type of setup to happen transparently in the background. ROS requires you to do the setup manually because it can require tweaking to get the data passing correct. IE if you send to many HiRes camera streams across a slow connection you are going to get erratic behavior.

You will also come across terms like ‘roscore’ and ‘master-node.’ With names like that it is easy to think, wow! this must be where all the exciting stuff is happening.

Quite the opposite is true. The Master node is similar to the DHCP server in your home routers. It just informs other nodes how they can find each other on the system and then it gets out of the way.

While impressive sounding, roscore just starts the ROS Master, starts a parameter server, and starts some logging services.

All of the interesting stuff happens within the nodes you create on your robot’s graph.