Category Archives: ROS Basics

ROS Basics – challenges in the robotic low cost context

Applications in robotics need to solve a lot of computational intensive tasks. While some of them can be outsourced to an externally powered device like a laptop or a server, others essentially can be calculated on the UGV.

Examples for that are collecting sensor data, receiving and executing commands or streaming data. Balancing these is a challenging task, because on concurrent executing systems all processes can influence each other. Especially when computational power gets cut down to the limits in order to save energy. As most libraries, frameworks or software environments do, ROS requires additional resources when being compared to a single purpose application.

In conclusion providing enough computational power while using reasonable amounts of energy is an important task to solve.

Physical properties
Physical dimensions and requirements result from a tradeoff between costs and size, whereas smaller UGVs tend to be more expensive and complex. On the other hand, an upper bound among others is set by being manageable in terms of transport and storage.

The low cost target UGV is a four wheel or two tracks driven ground robot with physical dimensions below 150mm * 300mm * 300mm (height, width, length). The drive power should be accordingly with an effective force of more than 100 Ncm for moving or holding torque in case of stronger slope. Additionally, tracks are the preferred primary propulsion system as they have better grip properties and only require simple motor control. Another nice to have would be the capability of spot-turning, which would allow operating on small areas and facilitates 3D scans of rooms without moving further than required. Another optional point if the robot is going to be used outside of buildings or around kids is a splash-proof case that would increase the robots life. Furthermore, modular extensibility would increase the usability of the robot significantly.

Modular design

In order to solve the tremendous requirements of robotics in a low cost context, we need to think out of the box while structuring the challenges in solvable problems. Like the following graph shows, we should divide the functionality of UGVs into four main modules: First, Sensors are the parts the robot requires to sense the outside world, next Accumulators serving and saving power, followed by Processors the units are processing information gathered by Sensors and finally, Actuators which provide physical movement. These areas in turn get separated into further sections which we discuss one by one on the next posts.


ROS Basics – ROS in a low cost robotic context

UGVs like they are found in industry, education or Do it yourself (DIY) communities are currently not affordable for average technique enthusiasts, teachers in schools or sometimes even universities. The concept of low cost robots tries to solve that issue.

What is low cost in a robotic context?

The traditional interpretation of low cost is minimizing the expenses while keeping most important features. In borders of mostly expensive robotics this term needs to follow the same differentiation as between cheap , which means coming with a significantly reduced price and quality, and keen , considered as maintaining a certain amount of quality at a reduced total cost. For example, the 50 000 USD UBR1 is a low cost version 250 000 USD up to 400 000 USD PR2  of Willow Garage , but still is far away from the term cheap in a common way . Another example and at the same time another robot Melonee Wise worked on is the TurtleBot , which was constructed with the attempt to be the lowest cost version of a ROS robot at time of creation.1

How to achieve low cost?

There is no general solution to this problem. But an approach to solve the issue in the robotic context is to replace expensive single purpose solutions produced by companies in low quantities with mass produced products that get customized to suit the application.
A demonstration of this positive misuse are the first versions of the TurtleBot . Instead of constructing the robot with expensive 3D Laser Scanners they replaced it by a Microsoft Kinect originating from the gaming industry. Furthermore, it used a iRobot Roomba and later a iRobot Create as a low cost mobile base as constructing a custom movable footprint would
have been way more expensive. Also, the mass produced product came at a lower cost and unharmed warranty. An important side-effect of these replaceable parts is the independence of unique cost intensive and sometimes, due to customs regulations, not easily accessible parts. By that, the power to choose a cheap replacement at any time reduces overall expenses and
total risk.

As a consequence, an low cost UGV should be easy to build and reproduce, affordable for education and able to run ROS with some kind of 3D measuring device. It further should consist of easily achievable or replaceable parts.
In conclusion, these properties lead to a modular design concept with communication inter- faces between the inexpensive components. Also a certain degree of flexibility is required to maintain extensibility and independence of expensive parts.

ROS Basics – a short Introduction into ROS

The Robot Operating System (ROS) is an open-source meta-operating system which provides essential features, namely hardware abstraction, low-level device control, implementation of environmental functionality, such as visualisation, simulation or testing and allows message-passing between concurrent running processes [O’K13]. Furthermore, it offers implementations of commonly used functionality in installable packages which even cover complex
algorithms like Simultaneous Localization and Mapping (SLAM) and Visual Object Recognition (VOR).

ROS moreover contains tools and libraries for obtaining, building, writing and running code across multiple heterogeneous computers and therefore includes language and platform independent tools. For example, ROS supports multiple client libraries, namely roscpp for C++ , rospy for Python , roslisp for Lisp and many others. It is also possible to link application-related code and external libraries like OpenCV for computer vision or Eigen3 for efficient linear algebra computation. Furthermore, ROS can successfully be wrapped around other frameworks like the Player Project .

ROS is mostly licensed free and has been developed as open source software under BSD Licence, which offers a variety of advantages for a low cost robot.

Unsurprisingly, with the high complexity of ROS there comes one of the highest learning curves of all robotic frameworks. Besides, due to rapid changes of main characteristics during different major versions, nearly all books and most tutorials on the internet became unreliable which is often very confusing for a beginner. But, after the top of the curve, a lot of things are self explanatory and complex features can be implemented very fast.

Unfortunately, another point to mention and one of the main disadvantages of ROS is the dependency on the ROS host and its Operating System (OS). In case you do not develop on a x86 32bit system a lot of automations do not work and require patience to be solved.
Especially, the support of packages on armhf , the ARM release repository, is not very usable, yet. Additionally, despite the importance of reactivity and low latency ROS is – like all other frameworks – no realtime OS.

ROS general terminology

ROS is a message-based concurrent running heterogeneous peer-to-peer network application. Its structure can be imagined as a mostly undirected graph with an obligatory center process node, called roscore . Broadly speaking, this one master node tracks every other part of the robotic network, including running processes and their interfaces. The centralistic design consequently uses its advantages by offering global debugging possibilities and error logging. It further mediates direct connections between every graph node on request. This becomes very useful in cases like image processing, where running traffic over the central node would impact the global system by increasing network usage and processing power.
Still simplifying, other parts of the graph are organized name spaces, called rosnodes , which in turn are containing more rosnodes or process edges called dependently on their function as rostopics or rosservices . A rosnode in a ROS environment therefore can be a robot, a processing server for navigation or even a human interaction device, like a laptop. Usually they physically do not cross the border of a single computing system, but often a single system can run multiple name spaces. Also, rosnodes profit from zero copy shared memory handling between their topics by using the ROS nodelet manager and by that significantly reduce
memory consumption. Every rosnode offers at least one rostopic , a multi-peer subscribable message provider, or a rosservice , a bidirectional unique connection between peers containing parameters.

ROS history

In 2007, the first robot running a version of ROS was STanford Artificial Intelligence Robot
(STAIR) which was developed by Stanford Artificial Intelligence Laboratory (SAIL). During
that time ROS was called switchyard but already followed its main principles like inter-
process communication, concurrency and heterogeneous environments. After that, Willow
Garage primarily developed ROS until February 2013. At this time ROS reached the critical-
mass, every open source project needs to survive without being mainly driven by external
funding. Since then the stewardship of ROS has been moved to the Open Source Robotics Foundation  and subsequently left Willow Garage .
Major versions of ROS are called distributions and are named using adjectives that start
with with successive letters of the alphabet. Starting with box turtle , C Turtle , diamondback ,
electric , fuerte , groovy , hydro and finally Indigo , which is available since May 2014.

ROS Basics – Using ROS Indigo/Jade with a Webcam by the uvc_camera (USB Video Class) package

There are several ways to use ROS Indigo/Jade with a webcam. The one way working at most computer is using a ROS package called uvc_camera which has been created by Ken Tossell. UVC in this context stands for USB Video Class, which is a  standard that covers almost all consumer webcams.

Unfortunately there currently is no step by step tutorial how to use the package, which is why I created this page. In order to run the package, you will need a local catkin workspace as we created it in another post. This is caused by the fact, that the available package is outdated and does not contain any launch files.

Step by Step Guide

We start by cloning the files into our workspace ./src directory, solving the dependencies with rosdep and finally building the workspace with catkin_make:

Before I could build my workspace with the newly cloned files, I still was required to install video4linux support libraries in their development version by:

After catkin_make finished you can launch the uvc_camera node by:

After having a roscore running, the camera_node.launch file should give you something like the following output:

where you can see the possible run modes you know can configure in your custom launch file:

You can now start rqt and its plugin Visualization > Image View, choose e.g. the /image_raw topic and in case you have club mate and a hitchhiker’s guide to the galaxy by Douglas Adams around, you’ll get the following output:

RQT Image View UVC camera



ROS Basics – depthimage_to_laserscan with low cost depth sensors Asus Xtion or Microsoft Kinect

Most of my work depended on the efficient connection between the [amazon &title=Asus Xtion&text=Asus Xtion] and the [amazon &title=CubieTruck&text=CubieTruck] as a low cost laser scanner. As the [amazon &title=Asus Xtion&text=Asus Xtion] usually delivers 3D  sensor_msgs/PointCloud  data and most slamming algorithms need 2D  sensor_msgs/LaserScan messages to work properly, we need to find a solution to this issue: depthimage_to_laserscan .

If you already managed to use the ros-indigo-openni2-camera and  ros-indigo-openni2-launch you can use the following code:

As you might see, the  depthimage_to_laserscan gets initialized in a separate nodelet manager.

Nodelets are designed to provide a way to run multiple algorithms on a single machine, in a single process, without incurring copy costs when passing messages intraprocess. (Quote Wiki)

They hugely improve the performance of our 3D point clouds and allow significantly higher publishing rates.

An important property of an robot is the rate of data creation. A low rate influences most
higher algorithms leads to incorrect results. In most cases especially the depth sensors are
required to publish sufficient material to create detailed maps. The [amazon &title=Asus Xtion&text=Asus Xtion] Pro driver OpenNi2 and the ROS package openni2_camera offers multiple run modes which can be set by dynamic_reconfigure (I suggest using it in combination with rqt). Another essential option influencing performance is the data_skip parameter, which allows the system to skip a certain amount of pictures the hardware produces before loading them into memory and by that remarkably reduces computational load. It can be set to an integer value between zero, which means not to skip any frames at all, and ten, leading to every eleventh frame to be processed.

Performance Check

The different combinations of resolutions, maximum frequencies and the data_skip -parameter
ran on the aMoSeRo (my low cost [amazon &title=CubieTruck&text=CubieTruck] robot) is illustrated in the table below.  As it can be seen, especially the amount of frames that has to be processed per second highly influences the complete system.


In conlusion, the depthimage_to_laserscan package is really useful when working with low cost setups like depth sensors [amazon &title=Asus Xtion&text=Asus Xtion] or the [amazon &title=Kinect&text=Microsoft Kinect]. It furthermore is essential when interfacing SLAM algorithms.