No, not that ROS. This is about robots.



This Tutorial was claimed to work for Ubuntu16.04.


In 2017 it is wise to use 16.04. I have complete notes on creating a USB flash drive just to run ROS. Once you have a standard Ubuntu 16.04 installation, follow these official instructions for installation. Note that the install of ROS adds about 3GB to the system.

The Brave New World Of Debian 9 Stretch

Even on Debian it’s the same story for Jessie 8 as other distros (Ubuntu). Debian 9, however, is a very new thing. The weird thing that was hard for me to understand is that with Ubuntu and old Debian, you don’t run ROS on an Ubuntu or Debian system. You run ROS on a ROS system. On new Debian 9, everything that’s needed for ROS is actually in the real Debian system (not /opt with clever env tricks). The new Debian way is conceptually equivalent to Lunar or Kinetic (the new Debian packages can’t even mention that system). It’s a very clean design which surely must reduce redundancy. But as easy as it is to install and have ready, there’s still the considerable task of arranging for all the specific project dependencies.

For Debian 9/Stretch I’m not exactly sure but I think the correct way to install is to simply do this

$ apt-get install ros-desktop-full

On my system, this will install no less than 250 additional packages, including things like graphviz , OpenMPI, 166 libs, 35 Python modules, and a Ruby ecosystem. It does look like it gets the main ROS stuff though.

  • ros-base - Python Robot OS base metapackage

  • ros-core - Robot OS core metapackage

  • ros-desktop - Robot OS desktop metapackage

  • ros-desktop-full - Robot OS desktop-full metapackage

  • ros-perception - Python Robot OS perception metapackage

  • ros-robot - Python Robot OS robot metapackage

  • ros-simulators - Python Robot OS simulators metapackage

  • ros-viz - Python Robot OS viz metapackage

Because things can get complicated and there are so many ROS packages, I’ll list the full set of ROS packages that I know about for reference.

  • catkin - Low-level build system macros and infrastructure for Robot OS

  • gazebo7 - Open Source Robotics Simulator - Binaries

  • gazebo7-common - Open Source Robotics Simulator - Shared files

  • gazebo7-plugin-base - Open Source Robotics Simulator - base plug-ins

  • image-transport-tools - Robot OS image_transport package tools

  • libactionlib0d - Robot OS actionlib library

  • libbondcpp0d - Robot OS bondcpp library

  • libcpp-common0d - Robot OS utility library

  • libgazebo7 - Open Source Robotics Simulator - shared library

  • libignition-math2 - Ignition Robotics Math Library - Shared library

  • libimage-transport0d - Robot OS image_transport package

  • libinteractive-markers0d - Robot OS interactive_markers package

  • liblaser-geometry0d - Robot OS laser geometry package

  • libmessage-filters1d - Library for Robot OS message-filters

  • libnodeletlib-tools - Robot OS nodelet library

  • libnodeletlib0d - Robot OS nodelet library

  • libresource-retriever0d - Robot OS resource_retriever library

  • librosbag-storage1d - Robot OS library for rosbag_storage

  • librosbag2d - Library for recording from and playing back to Robot OS topics

  • librosconsole-bridge0d - Robot OS library for connecting console logging types

  • libroscpp-serialization0d - Robot OS library for roscpp serialization

  • libroscpp1d - Robot OS client library

  • libroslib0d - library for roslib (Robot OS)

  • libroslz4-1d - library implementing lz4 for Robot OS

  • librospack0d - Robot OS package information library

  • librostime0d - Robot OS library for time and duration

  • librviz2d - Library for the Robot OS 3D visualization tool

  • libtf0d - Robot OS tf transform library to keep track of multiple coordinate frames

  • libtf2-0d - Robot OS tf2 transform library

  • libtf2-ros0d - Robot OS binding for tf2 transform library

  • libtopic-tools1d - library for messing with Robot OS topics

  • libxmlrpcpp1d - Robot OS version of xml-rpc protocol library

  • python-catkin-pkg - Low-level build system macros for Robot OS — Python module

  • python-genmsg - Python library for generating Robot OS message and service data

  • python-genpy - Python Robot OS message and service generators

  • python-geometry-msgs - Messages relating to Robot OS geometry, Python interface

  • python-message-filters - Python library for Robot OS message-filters

  • python-rosbag - Python tools for recording from and playing back to Robot OS topics

  • python-rosclean - cleanup Robot OS filesystem resources (e.g. logs)

  • python-rosgraph - Command-line tool to print information about the Robot OS computation graph

  • python-rosgraph-msgs - Messages relating to the Robot OS Computation Graph, Python bindings

  • python-roslaunch - roslaunch tool for Robot OS

  • python-roslib - Python library for roslib (Robot OS)

  • python-roslz4 - Python library implementing lz4 for Robot OS

  • python-rosmaster - Robot OS Master implementation

  • python-rosmsg - Command-line tools for displaying information about Robot OS

  • python-rosnode - Command-line tool for displaying debug information about Robot OS

  • python-rosparam - Command-line tool for getting and setting Robot OS Parameters

  • python-rospkg - Robot OS package library

  • python-rospy - Python client library for Robot OS

  • python-rosservice - Command-line tool for listing and querying Robot OS services

  • python-rostopic - Command-line tool for displaying debug information about Robot OS Topics

  • python-roswtf - Tool for diagnosing issues with a running Robot OS system

  • python-sensor-msgs - Messages relating to Robot OS sensor, Python interface

  • python-std-msgs - Python interface for Standard Robot OS Messages

  • python-tf - Robot OS tf transform library - Python

  • rosbash - Assorted shell commands for using Robot OS with bash

  • rosout - Robot OS system-wide logging mechanism

  • rviz - 3D visualization tool for Robot OS

  • tf-tools - Set of utilities to operate with the Robot OS tf lib

  • tf2-tools - Robot OS tool for tf2 transform library second generation

  • topic-tools - Tools for messing with Robot OS topics

And yet, there are even more! Here’s one that isn’t included. * python-wstool - Commands to manage multi-VCS repositories (for Robot OS)

And what if you want the full development libraries? Count on another 487 packages!

$ apt-get install ros-desktop-full-dev

Here is an official list of Debian ROS packages.

Environment Setup

ROS needs a lot of packages, but wait until you see how many environment variables it needs! Fortunately they are encapsulated in a configuration script that can be sourced. Unfortunately, I scoured every file installed with all of the ROS packages (and deps) and couldn’t find it.

Ah, maybe with Debian Stretch this heavy handed environment tweaking isn’t needed since things are installed properly (PYTHONPATH legitimately contains ROS modules, etc).

Yes, it looks like with ROS on Debian 9 Stretch that you don’t need to worry about any of the environment stuff because all of the default paths are sufficient.


There are a lot of "packages". These can be viewed with rospack list. Here are the ones that start with ^ros.

  • rosbag /usr/share/rosbag

  • rosbag_storage /usr/share/rosbag_storage

  • rosbash /usr/share/rosbash

  • rosbuild /usr/share/rosbuild

  • rosclean /usr/share/rosclean

  • rosconsole /usr/share/rosconsole

  • rosconsole_bridge /usr/share/rosconsole_bridge

  • roscpp /usr/share/roscpp

  • roscpp_serialization /usr/share/roscpp_serialization

  • roscpp_traits /usr/share/roscpp_traits

  • roscreate /usr/share/roscreate

  • rosgraph /usr/share/rosgraph

  • rosgraph_msgs /usr/share/rosgraph_msgs

  • roslang /usr/share/roslang

  • roslaunch /usr/share/roslaunch

  • roslib /usr/share/roslib

  • roslisp /usr/share/roslisp

  • roslz4 /usr/share/roslz4

  • rosmaster /usr/share/rosmaster

  • rosmsg /usr/share/rosmsg

  • rosnode /usr/share/rosnode

  • rosout /usr/share/rosout

  • rospack /usr/share/rospack

  • rospy /usr/share/rospy

  • rosservice /usr/share/rosservice

  • rostest /usr/share/rostest

  • rostime /usr/share/rostime

  • rostopic /usr/share/rostopic

  • rosunit /usr/share/rosunit

This provides an idea of what these are (and where they are) but there are tons more than the ones shown here.

Architectural Overview And Terminology

  • ROS - Robot Operating System

    1. Perception

    2. Decision making

    3. Actuation

  • A node is a Unix process responsible for some aspect of the system. Could be nodes for…

    • wheel encoder

    • camera

    • position estimator

    • behavior execution

    • motor control

  • Coordinated by the ROS Master Process (roscore)

    • Allows nodes to locate each other and communicate

    • Parameter server - stores shared config values (like wheel radius, used by many nodes maybe)

    • Nodes can pass messages using topics which are named buses similar to a pipe. Nodes must publish to the topic to communicate. The receiver must subscribe to the topic. pub-sub architecture (publish/subscribe)

  • Messages - Over 200 different message types, such as

    • Physical Quantities

      1. Positions

      2. Velocities

      3. Accelerations

      4. Rotations

      5. Durations

    • Sensor Readings

      1. Laser scans

      2. Images

      3. Point clouds

      4. inertial measurements

    • Define your own

  • Messages can contain any kind of data

    • text

    • images

    • rotation

    • pose

    • velocity_cmd

  • Request-Response (as opposed to pub/sub) is supported too by "Services" Allow the passing of messages between nodes, unlike messages, not a bus. E.g. if the "behavior executor" node needs an image from the "camera" node but it doesn’t want to subscribe to every frame the camera publishes, then it can use a service and request an image only when needed.

  • Diagrams of all the nodes and what they communicate with are called "compute graphs". rqtgraph is a tool to help diagram these.


  • node = A component in a ROS system graph.

  • topic = Kind of like a VLAN for the robot’s messages.

  • named bus = Same as "topic".

  • message = The data that is passed.

  • tf = Track frames. Not TensorFlow.

  • service = A service a node can make available to request from. Like a camera node providing an image when requested.

  • action = Something like a service. But not quite. Just triggers. (Official docs). Discussion about when it’s best to use a topic vs. a service.

  • subscriber = a feature that allows a node to get all stuff published by another node.

roscore - The Master Process

The master process, roscore usually needs to be running somewhere in order to coordinate things with ROS components. Here are some of its functions.

  • Providing naming and registration services to other running nodes

  • Tracking all publishers and subscribers

  • Aggregating log messages generated by the nodes

  • Facilitating connections between nodes

Just run it by opening a screen term and typing roscore. That’s it. It seems the customary way to stop it is to just SIGINT (Ctrl-C).


ROS has a couple of build and package systems (I guess like dpkg and rpm). A mildly obsolete one is rosbuild (sometimes described as "dry"). The main one today seems to be catkin ("wet").

catkin packages

A catkin package may contain these things.

  • package.xml - information about the package required

  • CMakeLists.txt - a file with build instructions required

  • source code - for ROS nodes perhaps

    • scripts - Python executables

    • src - source code (presumably C & Cpp)

  • libraries

  • datasets

  • other stuff

    • msg - custom message type definitions

    • srv - custom call/response types

    • launch - configuration to run multiple nodes at once (ROS docs)

    • config - configuration files

To create a catkin package

cd ${P}/catkin_ws/src
catkin_create_pkg my_lil_package

catkin workspaces

A catkin workspace is a directory where packages are built, modified, and installed, (the top level therefor). Correspondingly catkin packages are the directories (zip? gzip?)

Steps to creating a catkin workspace.

mkdir -p ${MYPATH}/catkin_ws/src
cd ~/catkin_ws/src
cd ..

Apparently there is also a catkin_make clean too.


Turtlesim is a project desined to teach beginners about ROS. Unfortunately if you know absolutely nothing about the ROS jungle, even getting to the starting line can be extremely challenging. This was especially true for me with Debian 9 which has much better support for ROS than it seems any other distribution. That’s very ironic but the problem is that most documentation assumes a more challenging environment. It does look like turtlesim is not included with Debian’s packages by default. I did finally get it working on Debian 9 Stretch.

The first thing to note, turtlesim requires the installation of this QT package which the entire ROS did not require:


Then you must acquire (from Github) and build the ros_tutorials. Here’s what I did.

mkdir -p $C/src ; cd $C/src
git clone
cd $C
source devel/setup.bash

If all that goes well, you can then try running it.

rosrun turtlesim turtlesim_node
rosrun turtlesim turtle_teleop_key


The rosdep command can check on dependency requirements and fulfill them. Here is an example.

rosdep check simple_arm

This didn’t exactly work perfectly for me because of some messiness failing to evolve with the new Debian 9 native install. I tried adding this --os=debian:stretch but it still didn’t produce great effects.

In theory you can do this.

rosdep install -i simple_arm

Which should round up all the dependencies and install them. In practice, I was just going to github and getting them manually.


The roslaunch feature starts things running but unlike rosrun it can launch multiple nodes simultaneously and automatically. It can also set default parameters on the parameter server. It can also act as a keep-alive to respawn dead processes.

roslaunch simple_arm robot_spawn.launch


Had a hell of a time trying to get this sample project to run in Debian 9. Here is my Debian 9 script.

mkdir -p ${MYPATH}/catkin_ws/src
cd ${MYPATH}/catkin_ws/src
DEPS=" "
DEPS+=" "
DEPS+=" "
DEPS+=" "
DEPS+=" "
DEPS+=" "
DEPS+=" "
DEPS+=" "
DEPS+=" "
DEPS+=" "
DEPS+=" "
for P in ${DEPS}; do echo $((C++)); git clone ${P}; done
cd ${MYPATH}/catkin_ws/src/xacro
ln -s xacro # Fixing a deprecation problem.
cd ${MYPATH}/catkin_ws/
echo "FIX catkin_ws/src/simple_arm/CMakeLists.txt find_package"
sed -i '/controller_manager/d' ${MYPATH}/catkin_ws/src/simple_arm/CMakeLists.txt
#source devel/setup.bash
#roslaunch simple_arm robot_spawn.launch

Maybe it also needs the Debian equivalent of these: * ros-kinetic-control-toolbox * ros-kinetic-forward-command-controller * ros-kinetic-joint-limits-interface * ros-kinetic-transmission-interface * ros-kinetic-control-toolbox * ros-kinetic-effort-controllers * ros-kinetic-forward-command-controller * ros-kinetic-gazebo-ros-control * ros-kinetic-joint-limits-interface * ros-kinetic-joint-state-controller * ros-kinetic-transmission-interface

Running Demos

This is an example of the kinds of things necessary to run ROS stuff. It’s encapsulated in a handy Bash script so that each part that must be started in a separate terminal can be done so easily.

# First terminal
function Usage {
  echo "Usage: $0 N"
  echo "Run each part of the ROS experience in its own terminal."
  echo "  1 - ROS core"
  echo "  2 - Create and run the hello world program."
  echo "  3 - Set up workspace and arm environment."
  echo "  4 - Run code that moves arm."
function Core { roscore ;}
function Hello {
  mkdir -p $HDIR
  echo '#!/bin/bash' > $HDIR/hello
  echo 'echo "The hello program is running."' >> $HDIR/hello
  chmod 755 $HDIR/hello
  cd $CWS
  source $CWS/devel/setup.bash
  rosrun simple_arm hello
function Arm {
  mkdir -p $CWSS
  cd $CWSS
  git clone simple_arm
  cd $CWS
  source $CWS/devel/setup.bash
  roslaunch simple_arm robot_spawn.launch
  # Problems:
  # Make sure the package `ros-kinetic--controller-manager` is installed.
  # rosdep check simple_arm
  # rosdep install -i simple_arm
function Armmv {
  source $CWS/devel/setup.bash
  rosrun simple_arm simple_mover
case ${1:-0} in
  0)Usage;; 1)Core;; 2)Hello;; 3)Arm;; 4)Armmv;; *)Usage;;


There are special commands to check up on what the ROS is doing. The rosnode list command shows which nodes are active. This is what it looks like when running turtlesim.

$ rosnode list

Note that /rosout is automatically launched by the ROS master and is responsible for aggregating and filtering text messages into log files.

Another way to query the running system’s activity is to use rostopic list. Here’s what it looks like in the same context as before.

$ rostopic list
  • /rosout_agg Aggregated feed of messages published to /rosout.

  • /turtle1/cmd_vel Topic for communicating velocity commands. Publishing a velocity message to this topic will move the turtle.

  • /turtle1/color_sensor Turtles have color sensors which are published to this topic.

  • /turtle1/pose The position and orientation of turtle1 are published to this topic.

You can get more details about a specific topic. Note the full path as listed in rostopic list is required.

$ rostopic info /turtle1/color_sensor
Type: turtlesim/Color

 * /turtlesim (http://usb64:45023/)

Subscribers: None

To get more information about the type of a message, use the rosmsg show command. Here we see more details of the geometry_msgs/Twist type associated with the /turtle1/cmd_vel topic.

$ rostopic info /turtle1/cmd_vel | head -n1
Type: geometry_msgs/Twist
$ rosmsg show geometry_msgs/Twist
geometry_msgs/Vector3 linear
  float64 x
  float64 y
  float64 z
geometry_msgs/Vector3 angular
  float64 x
  float64 y
  float64 z

You can also just have a look at the files that define these things if you can find them.

$ cat src/ros_tutorials/turtlesim/msg/Color.msg
uint8 r
uint8 g
uint8 b
$ cat src/ros_tutorials/turtlesim/msg/Pose.msg
float32 x
float32 y
float32 theta

float32 linear_velocity
float32 angular_velocity

Some people think that rosed can be helpful for finding and editing these files.

If you want to monitor a topic in real time, you can use rostopic echo. This will spew tons of transaction details as the system operates.

$ rostopic echo /turtle1/cmd_vel
  x: 2.0
  y: 0.0
  z: 0.0
  x: 0.0
  y: 0.0
  z: 0.0
  • rosservice

  • rosparam


You can have a display of a real time values plotted on Y scrolling across a plot.

This is pretty easy to use if you have values that are being published on topics. Fire up this viewer and select what topic to view. Or specify it directly. Something like this.

rqt_plot /vehicle/throttle_cmd

ROS Logging

Logging is coordinated by roscore. Here are some types of logging and where they output to.

  • rospy.logdebug(…) - log file

  • rospy.loginfo(…) - stdout, log file

  • rospy.logwarn(…) - stderr, log file, /rosout

  • rospy.logerr(…) - stderr, log file, /rosout

  • rospy.logfatal(…) - stderr, log file, /rosout

Logging can occur on the ROS topic /rosout. Check out: rostopic echo /rosout

ROS Publishers

A publisher puts messages on a topic so that other subscribing nodes can receive it. Here is how it is set up in Python.

pub1= rospy.Publisher("/topic_name", message_type, queue_size=size)

To actually publish a specific message involves something like this.


Official details here.

If more than one publisher sends a message to a topic, it can block unless there is a queue set up with queue_size. When a queue is configured the system is asynchronous.

ROS Subscribers

sub1= rospy.Subscriber("/topic_name", message_type, callback_function)

The callback_function is run anytime a message is received; it can simply pass.

ROS Parameters

The roscore process manages the state of parameters which are a bit like the entire system’s constants and variables.

This can be used to change parameters for a running system.

rosparam set /arm_mover/max_joint_2_angle 1.57


The Python library for doing ROS things is rospy. It can create nodes, and do all the things that can be done. Official documentation is here.

The first thing that has to happen is a node must be initialized.


You can get a time marker with this.


Request-Response (as opposed to pub/sub) is supported too by "Services". For example, allows a node to request an image from the camera publisher only when needed.

The Python way to create a service.

service= rospy.Service('service_name', serviceClassName, handler)
  • service_name - used by other nodes to specify this service.

  • serviceClassName - refers to an .srv file belonging to each service.

  • handler - callback to do the service’s function. The service call message is passed as an argument. It should return a proper service response message.

There are several ways to use a service. They can be called from the command line directly. Here is how to use a service from another node. Set up a ServiceProxy.

service_proxy= rospy.ServiceProxy('service_name',serviceClassName)

Now it can be called.

msg= serviceClassNameResponse()
#Modify msg with desired message here.
response= service_proxy(msg)

Services can also be called something like this.

rosservice call /arm_mover/safe_move "joint_1: 1.57
joint_2: 1.57"

Yes, there is a weird hard return in there.

Services are defined in special directories like catkin_ws/src/myproj/srv which should be created if necessary. The service definitions end in .srv and contain stuff like this.

float64 joint_1
float64 joint_2
duration time_elapsed

The top section above the --- is for service requests and the bottom part is for responses. In the example above, the request takes two joint positions and returns how long the operation took.


Messages are similar to how services are defined except they use the msg directory and have only one section without a divider. To use messages you need to have these in your catkin_ws/src/myproj/CMakeLists.txt file in the find_package section. * std_msgs package contains definitions for common message types. * message_generation is a library required to properly compose messages.

Official relevant documentation * General message documentation * CMakeLists.txt * package.xml

ROS Exceptions

ROS uses many special exceptions. Here is list of ROS exceptions.


  • rqt_image_view - Shows realtime feeds of the images in the ROS topics.

  • rqt_plot - Shows real time plot of selected topic values.


Extract images from bag files.

Check what the images in your bag are published on with rostopic list while playing. If your bag has a topic called /image_raw you can do this to extract the images.

rosrun image_view image_saver image:=/image_raw
rosbag play my_ros_data.bag

Logs And The Less Obtrusive Absence Of Logs

Here’s how I used the real OS to suppress ROS' overactive logging enthusiasm. I know there are better ways, but not for me.

To make this work, start with sym linking this away:

ln -s /dev/shm/roslog ~/.ros/log

Then this clears the previous run before starting.

cd /home/xed/u/ateam/ros
mkdir -p /dev/shm/roslog; touch ~/.ros/log/ok
sudo rm -rv ~/.ros/log/*
catkin_make && \
source devel/ && \
roslaunch launch/styx.launch && \
echo $D # Date at start.
date    # Date at finish.