This article is a follow-up of Building a Simple Autonomous Mobile Robot. In that article we’ve described the project motivation and machine learning part of the robot. The following text describes lower level of software we’ve used to control the robot and to perform map-building and localisation tasks. We’ve chosen ROS as a framework to speed up the development of our project.

One of the early attempts to build a map with hector SLAM

Robotic OS

ROS is an orchestration tool for the individual components of the robot’s business logic. Some components can run the SLAM algorithm and create an indoor map. Other components provide an already created map for localization. Components control the motors, read the laser data or create a 3D visualization of the robot in the virtual space.

Each component is software created for ROS and is called a “node”. ROS takes care of a uniform standard that all nodes should follow.

The communication between the nodes is handled by ROS. The job of the ROS developer is to set up a proper configuration for the communication. The communication takes place according to pub / sub-principle. Each node can send a message to a specific topic. Other nodes subscribe to this topic if necessary and receive the transmitted data. These data packets are called “messages” and consist of request and response.

ROS has a large developer community and offers many ready-made nodes, services, actions and messages. However, if any component is missing, developers can extend ROS to the desired functionality. Messages consist of a simple text file. The remaining entities must be programmed in Python or C ++.

In order to keep the own extensions portable and not to lose the code, there is a possibility in ROS to group ROS components in form of “packages”. The catkin build system makes creating a package easy:

1. Use catkin_create_pkg command to create a package directory with bootstrap code.
2. Move all files to the directory and if necessary group them by subdirectories.
3. Finally build with catkin_make.

Many packages are located in the Linux repository and thus only an “apt install” removed.

Individual nodes can be started either with rosrun command or via XML launch files.

Our Configuration

ROS offers the possibility of creating a master-slave relation between individual instances. The brain of our robots is powered by Raspberry Pi 3. Thus, the computing power of robots is severely limited. To minimize power consumption and reduce the number of lags, we decided to do the complex calculations on a server machine on the same network.

This configuration meets the following requirements:

• The robot can be controlled with the virtual joystick.
• SLAM algorithm creates the indoor map and locates the robot at simultaneously with the robot’s movement.
• The card can then be saved and reused.
• The sensor information such as LIDAR points or odometry is displayed graphically.

To meet the requirements, we use nodes from the following ROS plug-ins:

• joint_state_publisher and robot_state_publisher create a rigid connection between the chassis and the laser. This connection is needed to emulate the odometry.
• hector_mapping executes the SLAM algorithm and locates the robot. Our robots lack real odometry sensors and IMUs. LIDAR is the only sensor that is connected to the Raspberry. Therefore, the localization must be done exclusively with SLAM based on laser data. hector_mapping is one of the few packages that allows to do that.
• hector_geotiff creates images of the generated map and position of the robot on it.

For the calculations and visualization necessary for SLAM to function properly, the ROS algorithms must know the translation matrices of each individual coordinate system. This can be achieved either by describing every translation of coordinate systems using XML tags in the launch file or by designing a URDF model from the robot. ROS derives all necessary transformations from this model. The 3D model of our robot is described as URDF with XARCO extensions.

We start all nodes listed above at the same time with a single launch file from our own package.

Challenges and Lessons Learned

ROS Versions

First problem we’ve faced was that the ROS Melodic distribution (the lates one at the time of writing) is not compatible with the Raspberry Pi. Theoretically it could be compiled from sources, but the 1 GB of RAM that Raspberry has appeared to be a physical limitation for the compiling process. Thus, we have installed a previous version: ROS Kinetic.

Our Linux Server has had ROS Melodic running on Ubuntu 18.04 and was communicating with the robot in slave-modus. Despite the successful communication between the ROS instances, many functions didn’t work or didn’t work correctly. For instance, visualization of the URDF model was not displayed. Also hector SLAM was performing poorly even by slight rotations of the robot.

Downgrading the server back to Ubuntu 16.04 with ROS Kinetic has solved these problems. Either the ROS Melodic version needed custom configuration that we haven’t provided or ROS implicitly requires same version of master and slave.

Sensor Fusion

At the early stage of the project we have decided to use only one LIDAR sensor in our robots. Soon we’ve learned that one sensor is not enough. What makes vacuum cleaner robots and autonomous car so complex and yet effective is the fusion of different sensor data. For instance, we could not achieve decent localisation of the robot on the known map mostly due to the missing odometry. Having added a couple of IMUs and cameras in addition to the LIDAR would have resulted in much better localisation performance and would allow us to try out other algorithms like AMCL or gmapping.

Taming ROS

At first we’ve seen ROS as a silver bullet that handles basically everything that robot would need. Later we’ve found out that ROS is more like a framework than an OS in a common sense. As every framework, it blackboxes some business logic and dictates design patterns. That might help or get into the way, depending on goals and needs of your project. In order to benefit from ROS, we took a step back and invested time into learning even those concepts of the ROS that have been not obviously related to our project.

Geschrieben von Boris.