2: ROS at a high level
Basic concepts of ROS

PRR Chapter 2: ROS at a high level

Use SSD - Don’t install :)

  • No need to install anything!
  • Use the SSD we provide it has everything on it that you will need
  • Take advantage of our TAs to help you to get to where you can successfully run roscore


  • Not really an operating system!
  • Runs on top of the OS, i.e. Linux
  • A highly sophisticated concurrent distributed process management and communication framework (my own definition)

ROS Fundamentals

  • A distributed operating system
  • Not really an operating system.
  • A process coordinator and an inter-process communications model
  • Different parts (nodes) can run on different computers
  • They all need to be connected by a LAN via TCP/IP


  • Fundamental concept in ROS
  • ROS runs a number of collaborating processes called “nodes”
  • Think of it as a program or a process which forms part of a system
  • A real robot will have dozens to hundreds of nodes
  • You can write nodes in Python (we will do) or C++
  • Nodes talk top each other by publishing and subscribing to messages
  • Everything starts with the ‘traffic-cop’ roscore
  • Once ROSCore runs, additional nodes can run
  • Each node is essentially a serpate program, maybe even a single file
  • Can be written in Python or C++
  • We will use Python mostly


  • Topics have a name and a message type
  • Twist message type is very very common.
    • Expresses a velocity in linear and angular aspects
    • Note our robot can only move forward and backward (x axis)
    • And it can only rotate around (z axis)
    • Twist doesn’t say anything about where the robot (thinks it) is
    • “cmd_vel” is the topic to directly command the base (people often refer to the robot as a whole as the base) to move. The message type for cmd_vel is Twist
  • Odometry
    • The Robot’s “belief” of where it is, and what it is doing.
    • Based on sensors in the base, including possibly the motors, a gps, a magnetometer etc.
    • Odometry is published as topic /odom and the message definition is called nav_msgs/Odometry
  • nav_msgs/Odometry
    • Header - standard header
    • pose - where does the robot thinks that it is (including Covariance - how sure is it?)
    • twist - how does it think it is moving (also with a covariance)
  • tf packages
    • See TF Tutorial
    • Coordinate system
    • There will/can be many
    • Some of the components might move (an arm for example)
    • tf system periodically broadcasts the current relationship between coordinate systems
    • Quaternions

Communication model

  • Message based
  • Most important model is “publish/subscribe”
  • publish a topic, subscribe to a topic
  • Many to many
  • Topics have a name (e.g. /cmd_vel)
  • Topics have an associated message


  • Master coordinator of all the nodes
  • It is run once at a known ip address or domain name
  • Any other node will make contact with it to announce itself
  • When one node talks to another, roscore helps them find each other and then steps out of the way.


  • A “hidden” file in your home directory
  • Contains a series of shell commands that are executed each time you start a shell
  • It is populated with lots of useful stuff by the installation of ROS
  • Any commands you want run each time will be placed there
  • note: source command reads the file and exectutes it as if you typed it into bash
  • Key environment variables have to be defined in .bashrc
$ source ~/catkin_ws/devel/setup.bash
$ export ROS_MASTER_URI=http://localhost:11311
$ export ROS_HOSTNAME=localhost
$ export TB3_MODEL=burger
$ export TURTLEBOT3_MODEL=burger


  • catkin is the ROS build system
  • It’s quite complicated and related to CMAKE
  • Treat it like a black box


  • A subdirectory in which you will be doing your ROS work
  • You need only one and it will be called catkin_ws/
  • You should already have it on your linux install, but here’s how you would create it otherwise:
$ mkdir -p ~/catkin_ws/src
$ cs
$ catkin_init_workspace
  • From time to time you have to build things, called “doing a build or make”
  • Use the alias cm

ROS Packages

  • A complete “application” or “tool”
  • Analogous to a gem in ruby, or a library in Java
  • Has a standardized layout:
$ cs
$ catkin_create_pkg my_new_package rospy
  • Contents of a package directory
    • package.xml # describes all the things that are in the package
    • CMakeLists.txt # describes how to “build”
    • ./messages # descriptors of the messages
    • ./scripts # contains all the python source files
    • ./launch # contains all the .launch files
Python programs
  • Most of your python code will implement nodes
  • You should put them into the ./scripts directory
  • Name them *.py and give them execution file property: chmod +x myfile.py
Synchronizing clocks
  • It is important that all computers that are in the ROS system (probably three - robot, roscore1 and your computer) have the same time. Note timeset is a bash function that is defined our class utilities directory, ./rosutils. which you should be calling from .bashrc (see above)
$ settime
Handy ROS CLI utilities
$ rosrun <package> <program>          # run a certain program from a certain package
$ rqt_graph                           # display nodes and topics graphically
$ roscd <package>                     # change directories to directory containing that package
$ roslaunch <package> file.launch     # "execute" that launch file
Names, Namespaces and Remapping
  • Everything in the ros world has a name that looks like a file path
  • For example: /cmd_vel is a topic name
  • To allow flexibility,m you can remap a name to another name on the command line, e.g.
$ ./image_view image:=right/image
  • Many real ROS applications have multiple nodes
  • To save time having to start each one separately
  • (And for many other reasons)
  • A .launch file contains instructios on what to launch and in what order
    <node name="talker" pkg="rospy_tutorials" type="talker.py" output="screen" /> 
    <node name="listener" pkg="rospy_tutorials" type="listener.py" output="screen" />

Frames (tf)

  • Essential concept
  • Complicated concept
  • High level: a way to quickly compute relative coordinate systems
  • If I know a position relative to the room, what is that position relative to the robot?
  • Handy and very common term to mean: 3d position and 3d orientation of something
  • (Not velocity, just the position)
  • Coordinate systems, which have an origin and an orientation
  • tf is a central package of ROS which computers transformations for Frames
  • It is a complicated topic which we will come back to