Category Archives: ROS

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.

ROS Basics – Step by step guide to a working ROS Indigo Ubuntu 14.04 Laptop/PC

We are beginning with a blank Xubuntu 14.04 Trusty x86 on a [amazon asin=B004URCE4O&text=Lenovo Thinkpad T520] . Any other version of a working Ubuntu 14.04 x86 should be compatible to this tutorial.

Setup Ubuntu environment:

If you are a complete beginner with Linux and Ubuntu, i would advice you to install several tools that are necessary or at least helpful while working with ROS. To install them use the following command and allow sudo to run with administrative permissions by entering your password when asked:

sudo apt-get install fail2ban ufw terminator git

In short, fail2ban is a advanced firewall tool that protects you from bruteforce, ufw is a ‘human readable interface’ to iptables and allows easy firewall rule organisation. Next, terminator is a terminal multiplexer that provides multiple terminals at once without leaving the keyboard while operating. Another essential tool is git, a source code versioning system.

There are more tools that are helpful, but can be considered as optional:

sudo apt-get install vim vnstat htop bmon chromium-browser

Setup ROS desktop environment Ubuntu 14.04 Trusty:

To install ROS itself we can easily follow the well written tutorials provided by their wiki: .

In short the commands are like shown below:

  • sudo sh -c 'echo "deb trusty main" > /etc/apt/sources.list.d/ros-latest.list'
  • wget -O - | sudo apt-key add -
  • sudo apt-get update
  • sudo apt-get install ros-indigo-desktop-full

Setup ~/.bashrc part I:

In order to work correctly ROS requires several bash environment variables, that are not very well documented in the install tutorial. You can enter the following commands every time you start a new bash, or add it to .bashrc, the script that gets executed every time you start a bash.

The most important command:

enables bash to provide all ROS related commands like roscore  and  rostopic .

In order to work in an network environment (see their wiki), ROS also requires three more variables, namely:

Where ROS_MASTER_URI, defines the ip location of the roscore and the other two the ip of the local instance. As you see, in the example all ips are the local host ip and need to be accordingly changed in order to work properly.

To simplify the ip settings, I suggest some modifications to the commands like that:

Which sets the ips to the local wlan0 adapter.

Create catkin workspace:

To use non packaged versions of ROS packages or the latest versions that did not have been compiled to the repository, you’ll need a local catkin workspace. Catkin is the ROS build tool, that is required to build packages from source. It allows multiple programming languages per package and handles linking dependencies.  To create a local workspace you can follow the ROS wiki tutorial:

In short, you also can follow these comands:

  • mkdir -p ~/catkin_ws/src
  • cd ~/catkin_ws/src
  • catkin_init_workspace

We will now build the empty work space as a first test:

  • cd ~/catkin_ws/
  • catkin_make
  • source devel/setup.bash

Setup ~/.bashrc part II:

We also need to reference the newly created local workspace in our bashrc. Without doing that, tools like roslaunch and rosrun wouldn’t be able to find the customly created packages.

source /home/insert-your-username/catkin_ws/devel/setup.bash

You can now build, clone or fork your custom packages and therefore can call your pc a working ROS Indigo environment! 🙂

ROS Tools you can try:

Synchronize the time in ROS offline environments without chrony

As our [amazon &title=CubieTruck&text=CubieTruck] is faced with strange issues when using chrony and internet access is not a general prerequisite on ROS setups, i needed to figure out a new way to synchronize the time with no internet ntp server available. For some reasons, even my local ntp was broken, which is why I try to set the time according to the ros master on all clients by this simple bash command:

it simply extracts the IPv4 part of the $ROS_MASTER_URI environment and uses ntpdate to set the time on the excecuting client system.

In case you only want to know the exact time derivation consider using the ntpdate parameter -q which only emulates the request.

Using Chrony on CubieTruck


Unless you really know what are you doing.

To synchronize the clock and fix a minimal time shift I was detecting, I followed the idea of the TurtleBot2 to use chrony to fix that Chrony is a little daemon that connects to your linux clock or hwclock and detect shifts. For some reason this lead to total chaos on the amosero.
I suppose chrony hasn’t been build for multicore dynamically speeded processors like the A20, which is why the shifting has been erratic and up to 2 seconds per minute.

sudo apt-get remove chrony

Fixed all timing errors on the [amazon &title=CubieTruck&text=CubieTruck]. Also it’s a bit disturbing how little changes can inflict complex setups.



TurtleBot Inventors Interview

Today I have found a very nice interview of Tully Foote and Melonee Wise on IEEE. I think it is a must read for everybody interested in low-cost mobile ROS robots.

Its amazing to read the thoughts they had while inventing the TurtleBot: Lower the entry barrier into ROS and keeping low cost for educational reasons. The same thing I try to achieve with my thesis and the aMoSeRo 🙂

Most of the time they speak right into my heart, the only thing I would disagree was this:

Melonee: I believe that the thing that robotics needs most is people who know how to program robots, and not as much people who focus on building robots. I’d like to see that shift in robotics competitions in general, where it’s more about what the robot is doing, as opposed to how it’s built. 

I’ve met a lot of engineers that are capable of building robots,but clearly underestimate the heavy lifting done by the computer science part – but also otherwise, some computer scientists do not have a single clue on how to move a real world motor by the power of code – someone needs to build a stable bridge between engineering and computing, and this is a person at least understanding both worlds or better mastering them, because as she also said:

Melonee: Because building robots is hard!