2 exercises to understand Robot Operating System without writing any code

As the field of robotics continues to prosper and innovate, Robot Operating System (ROS) has emerged as the de-facto framework used to implement new robot systems. Due to its architecture, ROS allows researchers and industry developers to easily share, integrate various ROS components and modules published by the community. Through the sharing of these components, a developer avoids having to “re-invent” the wheel when designing a new robot or enhancing an existing one.

How does ROS facilitate this sharing? Upon first glance, ROS appears to have a steep learning curve which makes it difficult to answer that question. But the essence of ROS can be captured with these 2exercises that don’t require you to write a single line of code.

Exercise 1

While it’s always more rewarding to follow along, you don’t need to actually do the exercises below to get the gist of what makes ROS modules “shareable”. They are simple enough to read along and understand. But in the case you do want to hammer out commands with us… install ROS on your computer.

Or if you have a Raspberry Pi, feel free to download and use our ROSbots’ ROS + OpenCV SD Card image. For those who don’t know, ROSbots’ a ROS + OpenCV Raspberry Pi robot kit for makers.

(Update March 5, 2020 — ROSbots is now ROSdroid, a robot kit to build and learn ROS2 and robotics.)

Once you have ROS installed, pull up 3 terminals. In the 1st terminal, type:

(1st_teminal)$ roscore

The roscore needs to be running in order for ROS to work. We’ll explain later why.

In the 2nd terminal type (or copy-paste since the spacing inside the single-quotes matter?!):

(2nd terminal)$ rostopic pub -r 0.5 /sample_drive_cmd geometry_msgs/Twist '{linear: {x: 1.0,y: 0.0,z: 0.0}, angular:{x: 0.0, y: 0.0, z: 0.0}}'

In the 3rd terminal type (or copy-paste):

(3rd terminal)$ rostopic echo /sample_drive_cmd

You should see the following printed in the 3rd terminal:

linear: 
  x: 1.0
  y: 0.0
  z: 0.0
angular: 
  x: 0.0
  y: 0.0
  z: 0.0
---

The above will print out every 2 seconds.

Congrats you just “created” and executed 2 ROS modules — or ROS nodes in formal ROS-talk.

Before we describe exactly what the commands do, let’s overview ROS.

We mislabel ROS by calling it an “operating system”. It is more a middleware than an OS that implements memory and process management. None of that happens in ROS. If given the liberty, I’d rename ROS as ROMS — Robot Messaging System. Oh well.

The power behind ROS comes from the messaging architecture that drives it. ROS nodes communicate with other ROS nodes through messages over topics — no different from any Publisher-Subscriber pattern commonly found in software design today. In addition to the extremely efficient messaging system ROS implements, it also comes along with all the (extremely powerful) tools to make sense of, visualize, record, play back, declare, debug the messages.

Back to our exercise #1.

In the 2nd terminal, you executed a “robot” module, or ROS node, that directs whoever is listening on the topic channel/sample_drive_cmd to move 1 meter per second in the x-direction, via publishing ‘{linear: {x: 1.0…}’, using the geometry_msgs/Twist message type, at 2 times a second, ie -r 0.5 hertz.

In the 3rd terminal, you executed a “robot” module, or ROS node, that listens to the /sample_drive_cmd. Sadly, this “robot” module has no motors, wheels, or thrusters so it can only echo back out to us the message data when received.

Mostly all ROS command line tools, such as the rostopic echo or rostopic pub, effectively kick off as a ROS node to publish or subscribe to certain messages to perform certain administrative tasks.

What about roscore? That is the message broker for ROS’ messaging system. It is responsible for directing how sockets should be open between which nodes for message communication. As the message broker, roscore needs to be running all the time in order for the ROS system to work.

Exercise #2

In a 4th terminal, type (or copy-paste)

(4th_terminal)$ rosnode list

And you should the following ROS nodes listed:

/rosout
/rostopic_3677_1522356295889
/rostopic_5414_1522358692368

The id numbers after /rostopic_xxx may be different for you. But here you see that each rostopic command results in a ROS node.

FYI, the /rosout node is a node that gets kicked off when roscore starts. It is effectively ROS’ standard out and err which any ROS node can output to.

Last but not least — ROS also has a RPC subsystem known in ROS-talk as ROS services which also facilitates ROS inter-node communications when a simple pub-sub fails. When ROS services combine with the ROS topic pub-sub architecture, ROS nodes can be implemented as independent modules having nearly zero code dependencies with upstream or downstream ROS nodes. Researchers and developers can implement all sorts of robotics modules as ROS nodes — controllers, object detection, pose calculation, mapping, etcetcetc — and freely share them in as a ROS package for others to use. There are literally thousands of these ROS packages open sourced and published, ready to be integrated into your next ROS robot which will change the world.

Hope this was helpful for anyone who has wanted to get the basic gist of what makes ROS so powerful and contributed to its growing popularity.

As usual, don’t hesitate to reach out with questions, feedback or just to say hi.

Thanks!
Jack “the ROSdroid Maker”