If you have ever tried building a third party ROS package, you know the time and effort it takes to setup the required dependencies. Often times, the package you are trying to install will be compatible with only specific versions of its dependencies. Say for example you are using a deep learning framework like TensorFlow/PyTorch. These frameworks require specific version of CUDA packages to run correctly. If you already have an incompatible version of CUDA installed, your TensorFlow installation may throw errors. Downgrading/upgrading the CUDA version has its own set of associated problems. On top of this, if you are working on a collaborative project, the version of TensorFlow and CUDA that you have might not be the same as what your colleague is using. This may result in the classic problem of software development: “It works on my machine”.

This is where Docker comes in. Docker is like a virtual machine, but smarter. A VM runs an entire OS within an OS, taking up precious computing resources. Docker is much smarter. A Docker VM, called a ‘Container’, only runs a stripped down version of an OS. This bare-bones version of any OS only has the minimum required packages to run whatever task you are trying to accomplish. Docker containers also utilize the full memory and processing power of your system, making them much faster than traditional VMs. The benefits of using Docker containers for software development are endless and require their own separate article to do proper justice. For now, I will explain how using Docker simplifies our ROS2 installation.

Every ROS version requires a specific Ubuntu version to run. For example, ROS Melodic is made for Ubuntu 18.04. Installing Melodic on Ubuntu 20.04 will undoubtedly cause problems. The current Long-Term-Supported (LTS) version of ROS2 is called Foxy Fitzroy. ROS2 Foxy is made for Ubuntu 20.04. So for installing ROS2 on your system, you will need Ubuntu 20.04. But as Melodic is the current LTS for ROS1, there is a high chance that you, like me, are using Ubuntu 18.04. Even if you are using Ubuntu 20.04, there is a chance that you might have ROS1 Noetic installed on your system. In all these cases, installing ROS2 will cause numerous problems, be it due to incompatible OS version, or simply due to conflicts between ROS1 and ROS2 packages. To avoid this, we can install and run ROS2 in an Ubuntu 20.04 Docker container.

Docker Containers, Images and Dockerfiles

The simplest way to understand Containers and Images is via an Object Oriented Programing (OOP) analogy. A Docker image is like a class and a Docker Container is an object (or instantiation) of the image. A Docker Image contains everything needed to run a container: code, libraries, environment variables, configuration files, etc. It serves as a blueprint which can be used to create an instance, ie, a Docker Container. Once a Docker Container is created, you can tinker with it as much as you like, and it won’t affect the image from which it was built.

You can find prebuilt Docker Images for many different applications on the DockerHub¹, which uses a GitHub like cloud solution where you can pull images to your local computer. These prebuilt images have relevant libraries, environment variables, etc. already setup so you can simply create a Container from the Image and get started on your work.

If you can’t find a suitable image for your use case on DockerHub, you can create your own Docker Image using a Dockerfile. A Dockerfile is a set of instructions to build a Docker Image. You can learn more about the syntax and standard practices of writing a Dockerfile from the documentation². For the purposes of this guide, I will explain the commands that I used as we go.

The Open Source Robotics Foundation(OSRF) has hosted ROS Docker Images on the DockerHub. While having the knowledge of Dockerfiles and building your own images is helpful, if you are in a hurry, you can pull the ROS2 image from DockerHub here.

Building the ROS2 Image

ROS2 Foxy Fitzroy is made to run on Ubuntu 20.04. So in the first line, we download the Ubuntu 20.04 Docker Image:

FROM ubuntu:20.04

If you don’t have the image locally, Docker is smart enough to pull it from the official Ubuntu Images on DockerHub.

The instructions that follow are for the ROS2 installation on top of Ubuntu 20.04. My approach to this was modifying the existing set of instructions given in the ROS2 documentation³.

Set locale

This can be done easily in Docker Images using:

ENV LANG C.UTF-8
ENV LC_ALL C.UTF-8

The ENV command is used, as the name suggests, to set the environment variables.

Setup Sources

Next, we need to setup the sources so that the system knows where to look for ROS2 packages. The RUN command essentially lets us execute terminal commands.

RUN apt update && apt install -y curl gnupg2 lsb-release
RUN curl -sSL https://raw.githubusercontent.com/ros/rosdistro/master/ros.key  -o /usr/share/keyrings/ros-archive-keyring.gpg

Notice that there is no sudo before apt. This is because by default, you are already logged in as root in docker. The -y was added to bypass the prompt by apt, which asks the user if they want to continue the installation or not.

RUN echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/ros-archive-keyring.gpg] http://packages.ros.org/ros2/ubuntu $(lsb_release -cs) main" | tee /etc/apt/sources.list.d/ros2.list > /dev/null

Install ROS2 packages

After updating the existing packages, we are ready to install ROS2 foxy. This is as simple as:

RUN apt update
RUN DEBIAN_FRONTEND=noninteractive apt install -y ros-foxy-desktop

The ROS installation asks for configuration prompts in between the installation. Especially for selecting the timezone and keyboard language. Using DEBIAN_FRONTEND=noninteractive allows to bypass this step by letting the installer pick the defaults. And -y as before automatically switches answers to yes when prompted.

Setting up a workspace

While the above steps are enough to build a Docker Image with ROS2, it’s nice to add the following lines for convenience. The first thing that you might end up doing after a ROS installation is setting up a workspace. While this is a fairly easy task, it’s always nice to automate even that, so you can get started right away.

WORKDIR /root/dev_ws/src
RUN git clone https://github.com/ros/ros_tutorials.git -b foxy-devel
WORKDIR /root/dev_ws

The above lines make a folder called dev_ws which will serve as the colcon workspace. And also clone the ROS2 tutorials for beginners. The WORKDIR command, as the name suggests, changes the working directory of the terminal that the Docker Container is running in. Docker is smart enough that if such a directory doesn’t exist, it will make one without prompting the user.

Finally, we install rosdep and colcon. Both are essential packages for ROS2. Rosdep helps resolves errors associated with missing dependencies. Colcon is the next iteration of catkin_make and other tools that were used for building packages in ROS1.

RUN apt-get install python3-rosdep -y
RUN rosdep init
RUN rosdep update
RUN rosdep install -i --from-path src --rosdistro foxy -y
RUN apt install python3-colcon-common-extensions -y

Entrypoint for ROS2

For using ROS commands in any new terminal, we need to source the setup.bash file. To avoid the hassle of sourcing the file in every terminal, we normally add a script to the .bashrc file. A similar thing can be done for Docker Containers.

COPY ros2_entrypoint.sh /root/.
ENTRYPOINT ["/root/ros2_entrypoint.sh"]
CMD ["bash"]

The COPY command copies the entrypoint shell script that I wrote to the root of the Docker Container. This script will source the setup.bash file. The command ENTRYPOINT allows us to set the script which will run each time a container is started. Finally the CMD command is used to set bash as the default executable when the container is first started.

Conclusion

This brings us to the end of this little guide. While they might seem tricky to setup, using Docker Containers for software development saves a lot of hassle in the longer run. It gives the developer a peace of mind, knowing that even if he/she messes up the OS, it won’t damage their own system, as the OS is running inside a Container. I hope this guide helped you understand and appreciate how simple it is to setup your own Docker Image/Container. You can check out the code for my Dockerfile. The Open Source Robotics Foundation also has their own ROS Docker Images⁴, which are regularly updated on the DockerHub. If you want to save some time and are content with the default dependencies that the OSRF Docker Images have, you can always pull the image of your choice from DockerHub.

Image Sources:

• It works on my computer comic - Jeff Lofvers - Don’t Hit Save
• Docker Container & Traditional VM - Sebastian Eschweiler - Coding The Smart Way
• Dockerfile, Image and Container - Rocky Chen - Medium

After cloning the racecar¹ and racecar_gazebo² packages to the /src directory and building them using catkin_make, I launched the simulation using:

$ roslaunch racecar-env racecar_tunnel.launch

Of course things never work at the first try. I encountered 2 errors which were fixed by installing the following dependencies:

• ackermann_msgs

• effort_controllers

Now running the same environment launched Gazebo and spawned the racecar in the tunnel map.

To map the environment, I used gmapping. After setting up the launch file gmapping.launch and running it, rviz showed the warning: No map received. The terminal showed

[ WARN] [1612766930.932705394, 1106.617000000]: MessageFilter [target=odom ]: Dropped 100.00% of messages so far. Please turn the [ros.gmapping.message_filter] rosconsole logger to DEBUG for more information.

Clearly, there was some error with the odometry information. A quick

$ rosrun tf view_frames

revealed that the there was no odom --> base_link transform that is necessary for gmapping to run properly. Refer REP 105³ for the convention.

There are 2 ways of fixing this error:

1. Using the static transform publisher⁴, a transformation can be created from odom --> base_link. This will work in the case that the robot is fixed with respect to the map. But as I wanted the racecar to explore and map the environment, this approach isn’t viable.
2. Dynamically publish the relationships between odom and base_link frame. Generally, this is done using inputs from on-board sensors like encoders and lidar to estimate the robot’s location w.r.t. the map.

Point 2 is the ideal approach. But as the robot is running in simulation, a clever shortcut can be used: Instead of using sensor readings, one can use the simulator(gazebo)’s information of the robot pose for odometry. A closer look at the mit-racecar code revealed that that’s exactly what’s being done in the gazebo_odometry.py script located in the racecar_gazebo package.

Executing

$ rosnode info /gazebo_odometry_node

revealed that this node is subscribing to the /gazebo/link_states topic which provides the robot pose information. It’s also publishing to the /tf topic, which is where the map-->odom transform is being broadcast. This is in line with what we saw in tf tree above.

So I made a slight modification to the gazebo_odometry.py to configure the tf tree for gmapping. After looking at the ROS wiki documentation for the slam_gmapping package⁵, I found that for gmapping to run correctly, it needs an odom-->base_link-->laser transform. The gazebo_odometry.py node was written, (from what I understood), for navigation purposes. That’s why it transforms map-->odom, instead of odom-->base_link. So I simply changed the parent link to odom and child link to base_link in the script and voila! We now have working SLAM!

The map-->odom transform is now provided by the /slam_gmapping node. We can see the same by looking again at the tf tree:

Below is a scribd embed if you want to have a closer look at the final TF Tree.

Finally, I ran the keyboard_teleop.py script using

$ rosrun racecar_control keyboard_teleop.py

to teleoperate the racecar. Once a good map is obtained, it can be saved using

$ rosrun map_server map_saver -f mymap

With this, we come to the end of this post. The key takeaway from this post is that TF transforms are an extremely important part of ROS. It is vital that a ROS Developer be comfortable with interpreting the TF tree. To any beginner ROS users, I would recommend to always run tf view_frames node and take a look at the TF tree when implementing someone else’s package.

Next I will be implementing the ROS Navigation Stack⁶ on the mit-racecar robot. I will post here if I encounter any interesting problems.

In this project, I developed a ROS package that implements SLAM and Autonomous Navigation on a custom 2 wheeled Differential Drive robot in Gazebo. Throughout the development of this project, I learnt several new ROS concepts which are essential to understand for any beginner. In these posts, I will summarise the steps that I followed (along with relevant links) and hopefully, by the end, you would have learnt something new.

Bur first, let’s watch the final result:

To follow along, I would suggest that you install the ROS package using the instructions in the GitHub Repository¹. You can find the same here.

URDF and Sensors

We will be using Gazebo as a simulation environment for our purposes, so, we need to describe the robot model in a way that Gazebo can understand it. The Unified Robotic Description Format (URDF) comes to our aid here. URDF describes all the physical properties of a robot, like its basic blocks (links), how links move relative to one another (joints), inertial properties of the links, visual appearance in Gazebo, collision properties, etc.

Apart from that, as we are working in a simulation environment, we will need the robot to get sensor data like LIDAR point clouds, camera feed, etc. We also need a way to move the robot in Gazebo. All these are done using Gazebo plugins.²

So now, let’s look at the URDF for our robot. There are 4 files located in the ~/urdf/ folder:

• mybot.xacro
• materials.xacro
• mybot.gazebo
• macros.xacro

URDF is written in XML. And as you can see, it gets a bit complicated when dealing with many links and joints. To avoid rewriting certain blocks of code, we can use Xacro. Xacro effectively gives us shortcuts to help reduce the overall size of the URDF file which makes it easier to read and maintain. I followed the ROS Wiki URDF Tutorials³ to learn about URDF and Xacros.

The mybot.xacro file is our main URDF. It specifies all the joints, links, sensors. You can see that we are importing the other files using:

<xacro:include filename="$(find diff_drive_bot)/urdf/mybot.gazebo" />
<xacro:include filename="$(find diff_drive_bot)/urdf/materials.xacro" />
<xacro:include filename="$(find diff_drive_bot)/urdf/macros.xacro" />

Let’s look at a code snippet from mybot.xacro:

<link name='chassis'>
    <pose>0 0 0.1 0 0 0</pose>

    <inertial>
      <mass value="15.0"/>
      <origin xyz="0.0 0 0.1" rpy=" 0 0 0"/>
      <inertia
          ixx="0.1" ixy="0" ixz="0"
          iyy="0.1" iyz="0"
          izz="0.1"/>
    </inertial>

    <collision name='collision'>
      <geometry>
        <box size=".4 .2 .1"/>
      </geometry>
    </collision>

    <visual name='chassis_visual'>
      <origin xyz="0 0 0" rpy=" 0 0 0"/>
      <geometry>
        <box size=".4 .2 .1"/>
      </geometry>
    </visual>
</link>

Here, we are defining a link chassis and specifying its visual, inertial and collision properties. To describe the joints between 2 links, we use:

<joint type="continuous" name="left_wheel_hinge">
    <origin xyz="0 0.15 0" rpy="0 0 0"/>
    <child link="left_wheel"/>
    <parent link="chassis"/>
    <axis xyz="0 1 0" rpy="0 0 0"/>
    <limit effort="10000" velocity="1000"/>
    <joint_properties damping="1.0" friction="1.0"/>
</joint>

Here, the joint between left_wheel and chassis is called left_wheel_hinge and is a continuous type hinge. Meaning it rotates about its axis with no limits. Learn more about all 6 types of URDF joints here.⁴

The mybot.gazebo file contains the gazebo plugins for the differential drive motion and sensors. The materials.xacro contains all the colour RGB values that we use in mybot.xacro and mybot.gazebo. Finally, macros.xacro contains all the macros for mathematical equations used to define the robot. It’s not being used in this case because we have fixed all the values. But if you were to change the dimensions of your robot, you can use the macros.xacro file to avoid calculating the other related dimensions.

Again, to learn how to write URDF and use Xacro, the ROS Wiki tutorial³ series is a good place to start.

Gazebo and Rviz

Gazebo is an open-source 3D robotics simulator. This means that it is essentially a replacement for the “Real World”. Developers can test their algorithms on Gazebo first, iron out the bugs and then finally build and implement on a real robot. Rviz stands for ROS visualization. At any instant, several ROS nodes are publishing and subscribing messages on various topics. Some of these messages are difficult to understand by just reading the values. Rviz helps us visualize the message data. E.g., LIDAR point clouds are displayed as dots in Rviz, making it much more intuitive than seeing thousands of numbers in an array.

Let’s spawn our robot in Gazebo:

$ roslaunch diff_drive_bot gazebo.launch 

The ROS launch⁵ file gazebo.launch starts up the ROS core, Gazebo, and spawns our robot in an empty world with the House model as the robot’s environment.

You can see that LIDAR’s laser bouncing off on the walls and objects of the environment. Now let’s start Rviz:

$ roslaunch diff_drive_bot rviz.launch

This launch file sets the robot_description parameter to our robot URDF and publishes the joint and robot states. These are essential to publish because otherwise, Rviz won’t know how the robot links transform.

You can see in Rviz that the LIDAR data published on the scan topic is visualised as red dots, showing the obstacles and walls in the robot’s path.

Teleoperation

Now that we setup the URDF, Sensors and watched the robot in Gazebo and the sensor data in Rviz, its time to move the robot! For the purpose of this demonstration, I modified the turtlebot3 keyboard teleoperation node to suit our needs. To use that, execute:

$ rosrun diff_drive_bot keyboard_teleop.py 

You would now be able to move the robot around in Gazebo. Observe how the Rviz laser scan point cloud also changes as the robot moves around in the environment.

With that, this little tutorial/guide is over. I hope that you learnt something new about URDF, Sensors and how to visualise them in Gazebo and Rviz. If you have any questions/suggestions, feel free to drop them below. In the next post, I will share how I implemented SLAM and the ROS Navigation stack on the above robot.