Implementing Robot Operating

System on a Linux-based Automated

Guided Vehicle for autonomous
navigation

Bachelor Thesis
Computer Science and Engineering

Marco Maissan
0949830

Rotterdam University of Applied Sciences

Festo BV

Supervised by:
G. Maas
W. Volders

June 27, 2021

Information page

Document information
Document type Bachelor thesis
Implementing Robot Operating System on a Linux-based
Title
Automated Guided Vehicle for autonomous navigation
Date June 27, 2021

Client
Name Festo BV
Street Schieweg 62
Postal code 2627 AN
City Delft
Phone (+31) 015 251 8899

Graduate
Author Marco Maissan
Student number 0949830
Institute Rotterdam University of Applied Sciences
Major Computer Science and Engineering
Minor Data Science

Company supervisors
First supervisor J. Bastiaansen
Function Manager Innovation Unit

Second supervisor O. Fokker

Function Project Engineer

Study supervisors
First supervisor G. Maas
Function Skills teacher

Second supervisor W. Volders

Function Technical teacher

1
Preface

I hereby present my bachelor thesis named “Implementing Robot Operating System on a

Linux-based Automated Guided Vehicle for autonomous navigation”. It has been written
during the graduation process of the study of Computer Science and Engineering at the
Rotterdam University of Applied Sciences (Hogeschool Rotterdam). The project has been
executed in collaboration with Festo BV. Festo wished to gather more knowledge about
the possibilities of Robot Operating System (ROS) within their company. The idea to
integrate ROS on an automated guided vehicle was established in collaboration with Jurgen
Bastiaansen and Oscar Fokker. The final product is a proof of concept that shows the
capabilities of ROS on Festo hardware and for Festo from a business perspective.
Personally, I have always been fascinated by technology. Ever since high school, I was in-
terested in programming and other computational technologies. After high school, I decided
to study to become a software developer at Zadkine. Afterward, I was eager to gather a
deeper understanding of computer science. I started my study of Computer Science and En-
gineering at the Rotterdam University of Applied Sciences in September 2017. Meanwhile,
I obtained a great interest in the development of low-level software. During my graduation
period, I was able to apply my knowledge of both fields extensively, which I am grateful for.
This thesis is meant for two types of audiences. Firstly, it is meant for non-technical
people to get a deeper understanding of the capabilities of ROS. This thesis aims to show
which possibilities ROS can provide for business purposes. The second group is are technical
people or engineers. For them, this thesis should give insight into the possibilities of ROS
with autonomous navigation and how to integrate it on automated guided vehicles.
I want to thank Festo for giving me the opportunity to execute my final assignment at
their company. I want to thank Jurgen Bastiaansen for guiding me through the graduation
process, providing excellent feedback, and improving my personal skills from a business
perspective. I want to thank Oscar Fokker and Florèn van Olden for their great technical
guidance, support, and feedback. I am grateful for the opportunities and freedom that Festo
provided for me to execute this project. I also want to thank Gwendolyn Maas and Wouter
Volders from the Rotterdam University of Applied Sciences. They provided thorough and
helpful feedback on my work. They were always available for questions and always genuinely
cared about the progress of the project.

2
Abstract

This thesis is about the implementation of Robot Operating System (ROS) on a Linux-based
Automated Guided Vehicle for the autonomous guidance of visitors at Festo in Delft.
The automated guided vehicle is an omnidirectional robot called the Robotino. The goal
is to navigate visitors from the reception area to the eXperience Center, a 50-meter long
trajectory through the office that involves obstacles and curves. This thesis answers which
hardware and algorithmics are required for localizing, obstacle detection, and pathfinding
with ROS. After that, the thesis discusses how the architecture is implemented and in which
way the navigation goal can be set via a web interface.
The thesis is executed using multiple research methods. Explorative research was used to
determine the initial hardware situation of the Robotino. Observative research determined
what the environmental properties of the Festo office are. The localization, obstacle detec-
tion, and pathfinding options are mostly explored by literature research. Final field research
using test cases shows the capabilities and functionalities of the final product.
The environmental analysis made it clear that the Simultaneous Localization and Map-
ping (SLAM) problem must be solved. This needs extra hardware: an Nvidia Jetson Xavier
NX and a Stereolabs ZED 2. The implemented algorithm is a visual SLAM algorithm called
Real-Time Appearance-Based Mapping (RTAB-MAP). RTAB-MAP is also used to generate
a map of all static obstacles in the environment. All dynamic obstacles are detected using
the ZED 2 depth camera and the Robotino’s nine infrared bumper sensors. The pathfinding
algorithm is two-fold and consists of two ROS packages: global planner and teb local planner.
These packages generate the shortest path to a goal while also avoiding obstacles smoothly.
The project’s architecture is built using ROS launch files to distribute the computational
load between the Nvidia Jetson and the Robotino. Finally, the product is controlled via a
web interface that communicates via a WebSocket connection with the Robotino. The result
is the Robotino that can navigate customers to the eXperience Center after it has been given
a navigation command via its web interface.
Several recommendations are provided to improve the project. SLAM performance can
be increased by adding more computational resources and by placing AprilTags in the en-
vironment. The web interface could be enriched by showing a camera feed and by giving
feedback about the emergency stop. The hardware mount can be made more robust for
long-term usage. The last recommendation is to connect the emergency stop to ROS to stop
the software once the button is pressed.

3
Contents

1 Introduction 9
1.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.2 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.3 Problem statement of case study . . . . . . . . . . . . . . . . . . . . . . . . 10
1.4 Research questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.5 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2 Theoretical framework 14
2.1 System modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2 Robot Operating System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.3 Indoor navigation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3 Methodology 26

4 Localization 27
4.1 Task environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.2 SLAM hardware considerations . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.3 SLAM algorithm considerations . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.4 Hardware placement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.5 Hardware and algorithmics for localization . . . . . . . . . . . . . . . . . . . 56

5 Obstacle detection 57
5.1 The ROS Navigation Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.2 Obstacle detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.3 The hardware and algorithmics for obstacle detection . . . . . . . . . . . . . 63

6 Pathfinding 64
6.1 Planners . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
6.2 Pathfinding with obstacle detection . . . . . . . . . . . . . . . . . . . . . . . 68

7 Software architecture 69
7.1 Architecture design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
7.2 Implementation of obstacle avoidance with pathfinding and localization . . . 72

4
8 Controlling the Robotino 73
8.1 Setting navigation goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
8.2 Operating the interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
8.3 Indicating the destination . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

9 Implementation 76
9.1 Proof of concept performance . . . . . . . . . . . . . . . . . . . . . . . . . . 76
9.2 Test results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
9.3 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

10 Conclusions 79
10.1 Conclusion to main research question . . . . . . . . . . . . . . . . . . . . . . 79
10.2 Conclusion on the problem statement . . . . . . . . . . . . . . . . . . . . . . 79
10.3 Conclusion on motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

11 Discussion and recommendations 81

11.1 Comparison of ROS versus non-ROS . . . . . . . . . . . . . . . . . . . . . . 81
11.2 Recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

A Outline of environment 90

B Particle filter 91

C Mounting designs 92

D Data flow architecture 93

E Sequence diagram 94

F Web interface wireframe diagram 95

G Screenshot of web interface 96

5
Abbreviations

Abbreviation Expansion
API Application Programming Interface
AGV Automated Guided Vehicle
CPS Cyber-Physical System
CPU Central Processing Unit
CUDA (Nvidia) Compute Unified Device Architecture
DHCP Dynamic Host Configuration Protocol
EKF Extended Kalman Filter
FoV Field of View
GPU Graphical Processing Unit
HTTP HyperText Transfer Protocol
IMU Inertial Measurement Unit
IR Infrared
JSON JavaScript Object Notation
LIDAR Light Detection And Ranging
LTM Long-Term Memory
MoSCoW Must, Should, Could, Won’t
PEAS Performance, Environment, Actuators, Sensors
RAM Random Access Memory
ROS Robot Operating System
RTAB-MAP Real-Time Appearance-Based Mapping
SDK Software Development Kit
SLAM Simultaneous Localization And Mapping
STM Short-Term Memory
TF Transform Frame
TOF Time Of Flight
XML eXtensible Markup Language

6
Glossary

Robotino: An automated guided vehicle developed by the Didactic Department of Festo

Industry 4.0: The fourth industrial revolution. This includes autonomous “smart” facto-
ries that are connected via the internet.
Autonomous robotics: robotics that can make decisions (reason) on their own based on
sensory data.
Automated Guided Vehicle: Robotics vehicle that can navigate around an environment
without human intervention.
Costmap: a map that contains the places where a robot can drive and which places it
should avoid, based on its physical dimensions.
eXperience Center: Meeting room and demonstration area in Festo Delft.
Robot Operating System: Open-source robotics framework.
Holonomic robot: Robot where its degrees of freedom are equal to the directions it can
move in. For example, a car is non-holonomic because it cannot rotate without also driving
forward. A circular vacuum cleaner robot is holonomic because it can rotate and translate
in any direction individually.
Occupancy grid: A map with all static obstacles.
Odometry: The use of sensors to measure a robot’s changing position.

7
Additional documents

The following table contains all documents that are used for this thesis. They are not
included in the appendixes, but can be found as separate files in the attachments directory.

Description File
Hardware analysis of the Robotino hardware analysis.pdf
Requirements specification document requirements specification.pdf
Project’s plan of approach plan of approach.pdf
Test plan and test report testplan testreport.pdf
Code listing and code review codelisting codereview.pdf
Project manual manual.pdf
List of Nvidia Jetson ROS packages packages jetson.txt
List of Robotino ROS packages packages robotino.txt

8
Chapter 1

Introduction

1.1 Background
Festo is an internationally operating company founded in Germany. The company devel-
ops and produces pneumatic and electrical automation technology since 1925 [1]. Festo’s
product portfolio contains many sorts of pneumatics, motors and servo drives, sensors, lift-
ing/gripping technology products, and more. Festo owns several daughter companies, one
being Festo Didactic [2]. The focus of Festo Didactic is to provide equipment and solutions
for technical education.
Just like many other technological areas, the automation industry as a whole is looking
for improvement [3]. The industrial revolution started in the 18th century and has had
several major iterations. The first industrial revolution started around the end of the 18th
century, where steam engines were introduced in manufacturing processes. At the beginning
of the 20th century, steam was replaced by electricity, which has many technical advantages
compared to steam. The third industrial revolution was characterized by using electronics
to automate manufacturing processes. Computers and robotics took over many jobs. The
fourth industrial revolution, also called Industry 4.0, is the most recent change in the indus-
try. The key technology of Industry 4.0 is the use of Cyber-Physical Systems (CPS). Cyber
refers to cybernetics, which relates to adjusting system behavior based on system monitoring
[4]. Physical relates to physical machines. Implementing CPSes opens many doors in indus-
trial processes. It means that machines become intelligent, communicate with each other
and learn from their own (or others) behavior. It allows industrial machines to manage their
own internal agenda or change their behavior based on other processes. The goal of Indus-
try 4.0 is to change production processes in such a way that makes individualized customer
requirements during a fabrication process more feasible [5, 6].
One way of achieving the Industry 4.0 standards is via the integration of Robot Op-
erating System (ROS) [6]. ROS is an open-source robot operating system that provides
communication layers for hardware [7]. Some of the advantages of ROS are the following:

• Directly accessibility of hardware via driver support;

• Direct control of memory and processes;
• Allow processes to run concurrent or parallel;

9
 • Integrating artificial intelligence;
• Developing collaborative robotics;
• Allow different brands and/or types of hardware to communicate via default protocols;
• ROS is open source and free of use.
In the third industrial revolution, many of the robotic solutions were close-sourced [6]. In
contrast, many solutions in Industry 4.0 (like the usage of artificial intelligence) are open
source. Since ROS is open source as well, it provides great possibilities to integrate many
aspects of Industry 4.0, like artificial intelligence and standardized communication protocols.

1.2 Motivation
ROS is of great interest for Festo because of its many advantages. ROS enables many
possibilities in Industry 4.0. Many companies are using ROS in their automation products,
and it is becoming more popular every day. Some of the greatest technology companies are
even investing in ROS to improve and maintain ROS [8]. However, Festo has little in-house
knowledge of the capabilities of ROS. There is little experience in the Delft office, even
though it is necessary to stay updated with current innovation trends. This lack of in-house
knowledge is a reason for Festo to gather more information via a case study. This case
study will discover the potentiality of ROS on Festo hardware. It will explore areas in the
autonomous control of Automated Guided Vehicles (AGV) and the integration of intelligent
behavior.

1.3 Problem statement of case study

A case study in the area of autonomous robotics will be used to explore the potentiality of
ROS for Festo. The case study will attempt to solve one of the problems that occur in the
Delft office of Festo.
The problem is as follows. When a visitor arrives at the Festo office in Delft, they will
enter the building and approach the lobby (reception area). The visitor will state their
name and the employee of their appointment. At this point, the visitor has to wait in the
lobby while the receptionist tries to contact the employee in question. The visitor still waits
till the employee arrives. After this, the employee will guide the visitor to the eXperience
Center. The eXperience Center is an area on the ground floor meant for discussion and
experimentation. A layout of the floor can be seen in appendix A. The visitor has to wait
for the employee since visitors cannot walk through the building without guidance.
To approach this problem, the idea exists to automate the guidance process. The goal of
automating the guidance process is to eliminate the waiting times of the visitors. This will
be done by developing a Proof of Concept (PoC). The guidance process will make use of an
AGV called the Robotino. The Robotino is a product of Festo’s Didactic daughter company.
It is an omnidirectional robot containing several sensors and actuators that are controlled by
a Linux-based onboard computer. The Robotino has a diameter of 45 centimeters, and its
height is variable based on additional accessories. The Robotino provided for this project has

10
a platform that makes it approximately 80 centimeters tall. Two pictures of the Robotino
are provided in figure 1.1.

(a) Robotino base [9]

(b) Robotino provided by Festo for this project

Figure 1.1: Festo Robotino

The suggested approach for solving the problem is as follows. When a customer arrives,
the visitor states their name and the employee of the appointment. Next, the Robotino
will be at the reception area to guide visitors to a location in the eXperience Center. The
Robotino should decide on its actions in an autonomous manner. It must navigate safely
and autonomously throughout the building without the intervention of people. Besides, this
autonomous process must be done with little to no changes to the environment.
The key requirement of the PoC is that it operates using ROS. Executing the case study
with ROS allows Festo to gather new information on the area of autonomous robotics. Based
on the efficacy and final result, Festo will evaluate the possibilities of implementing ROS
within the company. In essence, the PoC will both solve a company problem and provide
valuable information for future company decisions.

1.4 Research questions

To approach the problem, it is necessary to formulate proper research questions. The answers
to the research questions will be used to develop the PoC. Hence, the research questions must
cover the topic in as much detail as follows. The main research question is as follows:

In which way can Robot Operating System be applied for controlling the Festo
Robotino to autonomously navigate to predetermined locations within the office
building?

11
This main research question can be split up into several sub-questions. The sub-questions
are the following:

• Which combination of hardware and algorithmics is suitable to be used with Robot

Operating System to localize the Robotino within the Festo office during autonomous
navigation?
• Which combination of hardware and algorithmics is suitable to be used with Robot
Operating System to detect obstacles during autonomous navigation?
• Which pathfinding algorithms are suitable to determine the path of the Robotino,
taking obstacle detection into consideration?
• In which way can obstacle avoidance be implemented in combination with the chosen
pathfinding and localization algorithms?
• In which way can the destination of the Robotino be indicated?

Sub question 1 starts at chapter 4 and is answered in 4.5. It makes use of the information
provided in the theoretical framework (chapter 2). Sub question 2 starts at chapter 5 and is
answered in 5.3. Sub question 3 starts at chapter 6 and is answered in 6.2. Sub question 4
starts at chapter 7 and is answered in 7.2. Sub question 5 starts at chapter 8 and is answered
in 8.3.

1.5 Scope
The following aspects are within the scope of this project:

• Analyzing the initial Robotino hardware;

• Software-based connection between sensors, actuators, and the navigation algorithmics;
• Using ROS packages for the autonomous navigation;
• Using the Robotino ROS API for accessing and controlling the Robotino’s sensors and
actuators;
• Adding extra hardware to the Robotino;
• Determining which extra hardware should be used;
• Determining the programming language for self-written code;
• Keeping code extensibility in mind;
• Implementing safety precautions;

The following aspects are out of scope:

• User Experience design;

• Navigation to different stories in the building;
• Writing new libraries/packages for solutions that already exist (e.g., reinventing the
wheel);

12
• Developing hardware by hand (e.g., soldering circuit boards);
• Navigating on non-smooth terrain (e.g., gravel or dirt);
• Security and software vulnerability prevention;
• Final product does not have to work in other offices than Festo Delft;
• Navigation capabilities do not have to serve any other purpose than guiding the visitors;
• It is assumed that the person stays in reach of the Robotino. It does not have to detect
human/social behavior.

13
Chapter 2

Theoretical framework

The theoretical framework contains useful information to make an educated decision about
hardware choices, software algorithms, definitions, and more. This information can be used
as a guide to understand more about autonomous navigation. It is also used in to argue and
defend project decisions.

2.1 System modeling

A system is a cooperation of multiple entities [10]. The system contains two main entities:
the Robotino and the environment. The Robotino interacts with the environment to fulfill
its purpose, which is to guide a customer from the lobby to the experience center. Building
a model of this system helps to determine which exact hard- and software is required to
fulfill this purpose. The model of the system also helps to determine which exact project
requirements are necessary and feasible. Besides, modeling the system helps to answer the
question on what autonomous means within this project.

The agent The project requires the Robotino to drive autonomously from the reception
throughout the Festo office. The project will be executed using the Festo Robotino, a
Robot that contains a combination of sensors and actuators. This follows the definition
of an agent, which is “anything that can be viewed as perceiving its environment through
sensors and acting upon that environment through actuators”, according to Russell and
Norvig [11]. Franklin and Graesser [12] discuss multiple definitions of (autonomous) agents.
Based on these formulations, they come up with one definition of an autonomous agent: “An
autonomous agent is a system situated within and a part of an environment that senses that
environment and acts on it, over time, in pursuit of its own agenda and so as to effect what
it senses in the future.”. A breakdown of this definition clarifies how it can be interpreted
for the project.
The first part of the sentence is “An autonomous agent is a system situated within and a
part of an environment...”. Based on the definitions of a system [10], this can be seen as the
coherence of interacting entities, the combination of the Robotino hardware and software.
The part of the environment in which it operates will be the lobby of Festo Delft, the way to
the eXperience Center, and the eXperience Center itself. More analysis of the environment

14
will be discussed in section 4.1. The second part is “...that senses that environment and acts
on it, over time, in pursuit of its own agenda...”. This means that the Robotino must use
its sensors during its navigation and make decisions on its sensory inputs. The agenda will
be the proposed trajectory of the Robotino toward its goal and how it will change when
obstacles occur on its path. After that, the last part describes “...and so as to effect what
it senses in the future.”. This means that the Robotino’s decisions change it’s state, and
thus change what it will sense. This means that each path can be unique and is not hard-
coded into its navigation algorithms. Franklin and Graesser [12] state that the definition
of “autonomy” is not strictly given. According to them, no real definition of this word is
necessary. When an agent makes its own decisions and pursuits its personal agenda, it can
be considered autonomous.

Task environment The task environment helps to find solutions to the problems that the
agent must solve. To specify the task environment, the strategy of Russel and Norvig [11]
will be used. The task environment is described with the following four items:
• The agent’s Performance;
• The Environment in which the agent performs;
• The Actuators of the agent;
• The Sensors of the agent.
In short, this is called the PEAS description. The performance describes the desirable
qualities of the agent. Examples are safety, the shortest path, or the most cost-effective.
The environment describes where the agent operates and what can occur on its path. There
can be a variety of obstacles that could potentially change the environment. The actuators
describe what gives motion to the agent to operate within the environment and possibly
change it. The sensors could be used to determine the state within the environment or the
state of the agent’s hardware. Several properties define the task environment. According to
Russel and Norvig [11], they are the following:
Fully observable or partially observable or unobservable: The environment is fully
observable if the sensors of the agent provide access to the entire state of the environment.
All sensors must detect all relevant aspects at any given time. The environment might be
partially unobservable, for example, when some far place cannot be observed while a close
place can be observed. Unobservable environments are ones where there is simply nothing
that can be observed.
Single agent or multiagent: This is simply defined by the number of agents in the
environment. This means that all types of agents need to be determined.
Competitive or cooperative: In a competitive environment, an agent tries to outper-
form another agent. In a cooperative environment, agents work together to reach a goal.
Deterministic or stochastic: The environment is deterministic if the next state of the
environment can be determined purely based on the current state. If this is not the case, it
is stochastic. The environment is thus stochastic when for example, random obstacles can
occur.
Episodic or sequential: In an episodic environment, the agent’s current decision does
not directly change its behavior in the future. This is usually the case when tasks are repeated

15
without being influenced by the past. Sequential environments, however, are influenced by
the past. A current decision will affect all future outcomes.
Static or semi-static or dynamic: When an environment is static, it does not change
during the operating process of the agent. When the environment is dynamic, it could
potentially change (although this is not strictly necessary). An environment is semi-static
when the environment does not necessarily change over time, but the agent’s performance
does change over time.
Discrete or continuous: This distinction applies to how time is handled. If the agent
has a finite set of states within the environment, it is discrete. If the agent operates contin-
ually through time, the environment is also continuous.
Known or unknown: This refers to the agent’s knowledge of the outside world. The
environment might be unknown to the agent. It is also possible that there is already a
map of the world. This is easily confused with the fully/not/partially observable aspect. An
environment can be partially observable and known, for example, when an internal map is
present, but the entire map cannot be observed.

The results of the PEAS analysis and the task environment are given in the results section
(4.1). The result will help determine which localization types, navigation, obstacle detection,
and pathfinding can be used.

2.2 Robot Operating System

The development of software for robotics can be a difficult task. The complexity of robotics
software can be vast and usually consists of several layers. For example, code for controlling
actuators requires low-level software, while autonomous navigation is often on a higher level,
less close to the hardware. When the scale and scope of robotics increase, it usually results
in the code becoming significantly more complex [7]. Developers often start to write software
libraries and frameworks that consist of modules that can be executed independently.
Robot Operating System (ROS) is a robotics framework developed with the previously
stated problems in mind. ROS aims to provide the tools needed to make the development of
complex robotics less difficult [13]. ROS was introduced in the mid-2000s and is now widely
known and integrated into the robotics industry. Although ROS can be ran on several
operating systems, it is mostly used on Linux-based robotics.
ROS aims to follow several design goals:

• Peer to peer: provide the ability to interconnect robotics to share data;

• Tool-based: usage of small software packages that provide one and only one purpose.
Large integrated software suites are harder to maintain and are less optimal for one
specific task;
• Multilingual: ROS software can be written in many languages, like C++ and Python;
• Thin: Making software libraries use standard conventions to exchange data. This
allows for easy integration of several packages that can be connected;

16
 • Free and open source: ROS software is initially open source. It can be extended with
closed-source modules. ROS licenses allow it to be used in both commercial and non-
commercial environments.

Nodes Nodes are individual pieces of software (packages) that perform a task within ROS.
Examples are nodes for navigation purposes, connecting to a camera, or running a user
interface. The nodes can communicate with each other via messages that use a predefined
data structure. The nodes are published on topics. Other nodes can subscribe to these topics
to read the broadcasted data from other nodes.

Roscore The service that ties all ROS nodes together is called the roscore. The roscore
manages the peer-to-peer connections from one robot to another and the connection between
individual nodes. The roscore makes it possible to share data via any network interface, like
WiFi or Ethernet. When a new node appears, it registers itself at the roscore so that other
nodes can access its data. The computer that runs the roscore is called the ROS Master.

Launch files Multiple nodes can be started at once using launch files. These are XML-
like structures with a .launch file type extension. A launch file contains information on
which nodes to launch and their subscribe/publish structure. Launch files can also contain
parameters for the initialization of packages. This is a fundamental aspect of ROS that is
extensively utilized within the project.

TF One important aspect of robotics is the positioning of its hardware. ROS provides a
method to describe the positions of hardware in 3D space. This is done via the tf package.
TF is short for transform. In ROS, the connections between hardware are defined in a
tree-like structure. The root of this tree structure is some arbitrary 3D coordinate. From
this coordinate, all positions and rotations of the hardware are defined. For example, let’s
imagine three TF frames:

• A map;
• The Robotino’s location (odom);
• An accelerometer (zed camera center);

These frames are visualized in figure 2.1. The map contains the Robotino. The ac-
celerometer is mounted somewhere on the Robotino. Therefore, the relative position of the
accelerometer and Robotino are fixed in place. This is called a fixed joint. Now let’s imagine
that the accelerometer measures that it’s been translated by 1 meter in direction X. The tree
can be traversed back to change the location of the Robotino relative to the accelerometer.
The Robotino will move with the accelerometer since they have a fixed joint. This results in
the Robotino and accelerometer translating in direction X relative to the map. TF makes
it possible to configure these relative positioning trees using XML easily. It broadcasts the
positions of components on the ROS network. For this project, TF is used to determine the
Robotino location relative to its environment.

17
 Figure 2.1: TF example

ROS 1 vs. ROS 2 There are two ROS versions: ROS 1 and ROS 2 [14]. ROS 2 contains
several improvements compared to ROS 1. For example, it has more features regarding
security, real-time control, and distributed processing capabilities. It also supports newer
programming languages. Where ROS 1 supports only Linux and Mac, ROS 2 also supports
Windows. The biggest downside of ROS 2 is its lack of packages and support [15, 16]. ROS
2 is not as profoundly integrated into the robotics community compared to ROS 1. Students,
newcomers, and researchers are advised to use ROS 1, since ROS 2 does not give any real
advantages. ROS 2 is advised to be used by actual robotics companies and manufacturers
capable of developing their own nodes. A deeper understanding of ROS, in general, is
preferred when using ROS 2. For this reason, this project will rely on ROS 1.

2.3 Indoor navigation

Navigating is the process of determining the current location of an agent and determining
its path. The goal of the Robotino is to navigate through the office building, starting at
the lobby and ending at the eXperience Center. There are many types of indoor positioning
to achieve this result. However, only a few of them are suitable for the requirements of the
environment. Besides, the hardware required to solve this problem must be compatible with
the Robotino and must work with ROS.

Navigation method One of the key features of indoor navigation is to determine the
location of the agent. There exist a plethora of methods to determine an agent’s location.
Deciding which method is the most suitable is mostly determined by the environment, the
available hardware, and the restrictions of ROS. As determined in the requirements specifi-
cation document and in the environment analysis, the Robotino must adapt to a changing
environment. Objects in the environment move around frequently. This implies that the
chosen method must be adaptable; the method of mapping the environment cannot be made
permanent.
Guide-path design is one of the most important aspects of AGV design control. According
to Le-Anh and De Koster [17], there are no guidelines for selecting an appropriate type of
guide-path for the system. Guide-paths must be selected based on the specific use-case and

18
requirements specification. There is not one method to find the perfect solution. Based
on the use case, several methods come to mind immediately. For example, figure 4.1 and
figure 4.2 show that there are blue lines throughout the hallway. The lines could be tracked
to determine the path of the Robotino. However, these paths are often obstructed. This
happens when new orders arrive and are placed in the hallway, when furniture or showcase
setups are moved, or in many other situations. This makes the blue lines unreliable for
positioning.
Essentially, the Robotino must be aware by itself of its absolute location in the building.
Knowing the absolute location in the building is used when calculating the path that needs
to be taken. However, to know the absolute location means that the Robotino must be aware
of what the entire environment looks like. As will be discussed in the environment analysis
(section 4.1) , the environment is partially unobservable and initially unknown. Combining
this information means that the absolute location of the Robotino can only be determined
after a map of the location is provided.
This is supported by Fuentes-Pacheco et al. [18]. According to them, autonomous navi-
gation can be divided into three questions:

• Where am I?
• What does the world (environment) look like?
• How can I reach a given location?

The paper states that localization and mapping are directly related to each other. To make
a good map, the exact location of the agent needs to be known. To know the exact location,
a map needs to be available. This problem is known as Simultaneous Localization And
Mapping (SLAM). According to Durrant-Whyte and Bailey [19], SLAM is considered to be
the holy grail for truly autonomous robotics navigation. The SLAM problem is used to
incrementally build a map of the environment and determine the position within that map
based on distance measurements.

Simultaneous Localization and Mapping (SLAM) As mentioned in the previous

paragraph, Simultaneous Localization and Mapping is the problem of mapping an unknown
environment and determining the localization within this environment [18]. This paragraph
contains the formal definition interpretation for static environments based on Thrun et al.
[20].
The SLAM problem is most often defined in a probabilistic manner (visualized in figure
2.2). This satisfies the environment analysis, which showed that the environment is proba-
bilistic instead of deterministic. A robot (e.g. the Robotino) exists in a location xt where
t denotes a moment in time and x represents a 2D location in a X-Y plane with a rotation
 T
θ, represented by a vertical vector: x = x y θ . The path of the robot can be defined
as a sequence of locations, namely XT = {x0 , x1 , ...xT } where T represents the time of mea-
surement. Like rotary encoders or inertial measurement units, odometry provides relative
information between two points in the environment. Let ut be the movement measured by
odometry sensors between time t − 1 and t. The sequence of UT = u1 , u2 ...uT represents the
movement of the robot. Combining the odometry with the initial location x0 , the location

19
relative to the start position can be determined. This does not take any odometry measure-
ment noise into account. Lastly, let m represent the environment, containing features like
walls and objects. It is assumed that m is static. A set of measurements can be constructed
by measuring the features in m on location xt which will be stored in ZT = {z1 , z2 , ...zT }.
SLAM is the problem of recovering the environment m from XT , UT , and ZT . There are two
primary forms of describing the problem.

Figure 2.2: Visual representation of probabilistic SLAM interpretation (top down view)

The full SLAM problem The first form of the SLAM problem is the full SLAM problem.
The full SLAM problem is denoted as p(XT , m|ZT , UT ). This can be read as the following:
“What is the posterior probability of the robot’s location and environment map, given the
previously sensed environment data ZT and odometry data UT ?”. The left side of the prob-
ability statement denotes the information the robot wants, while the right side after the
vertical bar denotes the information gathered already. The main takeaway is that the full
SLAM problem seeks to recover the entire path of the robot and thus processes all data
simultaneously.

The online SLAM problem The second form is the online SLAM problem. This dis-
tinguishes itself from the full SLAM problem by recovering the robot location instead of its
traversed path. It is defined by p(xt , m|Zt , Ut ). Note that the difference is that the posterior
probability of location xt is measured instead of the entire path (XT ). Mathematical filters
are used to solve this problem. Filters allow estimating a probability distribution given the
surroundings. Many filters exist, all having different quality properties for mapping and
localization [21].

20
SLAM properties Several properties define the exact SLAM problem for a specific business-
or use case [20]. One property has been discussed in the previous paragraph, namely full
SLAM vs. online SLAM. Here, full SLAM tries to approximate the entire traveled path
of the robot, where online slam tries to approximate its current position. The next property
is volumetric vs. feature-based. Volumetric SLAM tries to map the entire environment
in high resolution based on visual sensors (e.g., lidar or cameras). Feature-based SLAM only
maps locations of features that help solve the SLAM problem. For example, it will only store
the locations of landmark objects, like plants, furniture, artwork, etc. Volumetric SLAM is
more accurate but requires more computational resources, while feature-based slam is less
accurate and requires less computation. Another distinction is topological vs. metric.
Topological maps purely show relationships between environment features. For example, it
defines that feature A is next to B and feature C is down below B. It can be compared with
building a railway station map. Metric maps show exact locations of features, similar to
what a top-down photograph would look like. Examples of this can be seen in figure 2.3.

(a) Topological map of environment (b) Metric map of environment

Figure 2.3: Two types of SLAM maps

The next distinction comes from known versus unknown correspondence. The
correspondence relates to the landmarks or features in the environment. When landmarks
have unknown correspondence, two similar-looking landmarks can confuse the robot when
determining location. Landmarks can become known when using, for example, AprilTags
(figure 2.4) or other identification methods.

21
Figure 2.4: fiducial markers (AprilTags) captured with Intel Realsense camera for SLAM
usage [22].

Small vs. large uncertainty has to do with the number of paths that a robot can
take to reach a destination. Many possible ways to reach a goal increase the uncertainty
in the path approximation of the robot. The uncertainty can be reduced when depth reg-
istration is more accurate. The loop closing problem also influences uncertainty. The loop
closing problem represents determining whether a robot has come back to a point that it
has previously explored [23]. If this is detected, a SLAM algorithm can anticipate on the
sensor inaccuracies/drift and correct its map and location. If a loop is not detected and
thus the loop is not closed, it can result in an overlapping map which would be inaccurate.
Loop closing is a difficult problem but a necessary one for good SLAM algorithms. The loop
closing problem and its uncertainty about the world are graphically represented in figure 2.5.

(b) Unsuccessful loop detection with errors un-

(a) Successful loop detection with errors corrected
corrected

Figure 2.5: Loop closing problem visualized in hypothetical environment

SLAM algorithms can sense the environment active vs. passive. Active SLAM al-
gorithms explore the environment by themselves. Passive SLAM algorithms explore the
environment by a person that controls the robot using, for example, a joystick. The ma-
jority of SLAM algorithms are passive. Whether the environment contains more robots
determines single-robot vs. multi-robot. In a multi-robot environment, the robots can

22
sense each other, share maps, or perform other mapping/localization operations. Any-time
and any-space vs. regular defines the detail and precision of the SLAM solution based
on computational resources. At an any-time and any-space system, the detail of the solu-
tion is modified based on the available computational resources. When more resources are
available, the solution to the SLAM problem is more accurate and detailed. Lastly, static
vs. dynamic relates to the environment of the robot. This is similar to described in section
4.1. In a static environment, everything stays the same. In a dynamic environment, objects
change during navigation.

SLAM paradigms There are three most common SLAM paradigms. The fundamentals
of the paradigms are relevant because they have different properties regarding computational
efficiency and real-world accuracy. These aspects need to be considered when choosing the
right algorithm for the final thesis product.
The first oldest and most influential SLAM paradigm is Extended Kalman Filter SLAM
(EKF SLAM). It dates back to the 1980s [20]. It has proven reliability, for example, with the
Voyager space mission [24]. The goal of EKF SLAM works by building a matrix containing
each state of the robot and its corresponding landmark observations [25]. New landmarks
are added to the map at every step in time, and existing landmark errors are corrected based
on new observations. The disadvantage of this paradigm is that the map with states and
locations grows exponentially when new observations are added (complexity: O(n2 )).
The second paradigm is FastSLAM. FastSLAM is a newer paradigm that has several ad-
vantages in comparison with EKF SLAM. For example, where EKF SLAM solves the problem
in quadratic time (O(n2 )), FastSLAM solves the problem in logarithmic time (O(log(n)))
and has been successful in environments with over 50.000 landmarks. The state matrix of
EKF SLAM would, in this situation, contain (5 ∗ 104 )2 = 2.5 ∗ 109 elements that need to
be updated every time step. FastSLAM works using so-called particle filters. Particle filters
are inference/learning algorithms used to estimate a state in a mathematical system from
that system’s state-space [26]. There are many particle filter implementations for SLAM, so
understanding particle filters is essential to understand modern SLAM algorithms. A visual
representation of the particle filter can be seen in appendix B. Particle filters are mathemat-
ical models used in SLAM to determine the position of a robot within a map. Notice that
this assumes that a map of the environment already exists. To estimate the robot’s posi-
tion, n particles are placed randomly within the map. Each particle is a representation of a
position and rotation xt = (x, y, θ)T , as described in section 2.3. Next, an observation of the
environment is done by the robot. A probability density map of the actual xt is generated to
determine at which location the robot might be. Next, take all n particles and place them in
the probability distribution regions. Move the robot to a new position xt+1 and do another
observation. Recalculate the probability density again until an approximation of the robot
is made.
A particle can also be seen as a guess of what the true value of a state in that system
could be. The particle filter takes many guesses and approximates a new state of the system
based on previously observed states. The technique of particle filters can be applied when the
features of an environment (e.g., objects, walls) are considered to represent the state space
of the system. In this way, particle filters can be applied for SLAM to approximate a robot’s

23
location as explained by Thrun et al. and Murphy et al. [20, 26]. As noted in the papers, a
problem arises when the number of particles and landmarks increases. This would increase
the state-space of the system exponentially. The solution is to provide each particle with
K EKF-filters for all K observed landmarks, as proposed in the original FastSLAM paper
[27]. This, however, implies that the processing time complexity is O(P ∗ K), where P is
the number of particles and K is the number of observed landmarks. The paper suggests an
approach where the complexity can be changed to O(M ∗ log(K)) by exchanging information
between particles.
The third and most commonly used paradigm is Pose Graph Optimization (PGO). PGO
has first been introduced in 1997 by Lu et al. [28]. Pose graph optimization used for the
SLAM problem suggests building a graph structure based on odometry sensor data. The
working of PGO is best explained visually. Figure 2.6a shows the trajectory of the robot
from T = 1 to T = 7. Let’s assume that the robot contains some imperfect sensor that can
sense the environment in all directions with some error. The robot senses the landmark and
moves to T = 2. Here, the robot makes a new measurement. The path between T = 1 and
T = 2 is expressed by a string or rubber band (w1) and contains a strength 0 ≤ s ≤ 1, like
described by Golfarelli et al. [29]. The robot follows a trajectory making measurements.
The further the robot is from a landmark, the more uncertain it is about its actual position.
When the robot moves back to the landmark, its position becomes more certain, which can
be seen in w6. At T = 7, the robot senses the landmark again and thus concludes that it has
come back at a previous location. However, it can be seen that the robot should be back at
T = 1, but its estimated pose graph shows that the odometry measurements do not match
T = 1 and T = 7. This happens because of the sensor inaccuracy.
The SLAM algorithm works by adjusting all poses based on the certainty expressed by
the springs. More certain springs will remain mostly in the same location, while springs
with high uncertainty will be moved around more. The final goal is to adjust the path so
that w7 is eliminated, resulting in T = 1 and T = 7 to overlap and the loop to be complete.
Some transformation needs to be found that can be applied to all estimated poses that result
in the disappearance of w7. After this optimization process occurred, the result looks like
figure 2.6b. The optimization process also shows that the detected landmark and the actual
landmark are aligned again. The transformations in measured poses can be seen in figure
2.6c, where measured trajectory and the corrected/transformed trajectories are overlapped.
The details behind the optimization algorithm are out of the scope of this thesis.

24
(a) Path according to odometry measurement (b) Path after calculating optimization

(c) Overlay of figure 2.6a and figure 2.6b. The

top graph shows the graph after optimization;
the bottom graph shows the graph based on
odometry measurement.

Figure 2.6: Pose Graph Optimization visualized

25
Chapter 3

Methodology

Research methods Several research methods have been applied to find the answers to the
research questions. Firstly, the author of this thesis used exploratory research to determine
the capabilities of the currently available hardware. The goal of this research was to figure
out which additional hardware is required for the final product. Observational research de-
termined what the environment of the Robotino looks like. This research made clear what
types of indoor navigation and obstacle detection can be used. All hardware and software
decisions were backed up by literature research and the theoretical framework (chapter 2).
The literature research determined which hardware and algorithmics will be used for local-
ization, obstacle detection, and pathfinding. After the product was built, it has been tested
using field research. The field research has been executed by performing test cases on the
final product. The result of this research is available in the test report. The types of research
are both qualitative and quantitative; the results are provided both literal and numerical.

Project strategy This project consists of two main parts: performing the research and
building the proof of concept (project implementation). Every step of implementation is
backed up by the research that applies to that specific part. After a research sub-question has
been answered, the implementation of that part can start. The next research sub-question
will be answered while implementing the previously answered question. In summary, both
research and implementation are executed simultaneously, but implementation is only done
after its research has been conducted.

Project management tools The author of this thesis used several project management
tools to ensure that the project was executed smoothly. Firstly, the project timeline was
set up using TeamGantt. This timeline has been updated frequently to give insight into the
status of the project. The Trello project manager was used to determine which tasks had to
be performed for a two-week time period. Every two weeks, a presentation has been given to
Festo about the research and implementation progress. Every software-based development
used Git version control. After every significant change, the changes were pushed to its
repository. NoMachine remote desktop was used for programming and debugging remotely
while the Robotino is navigating around the office.

26
Chapter 4

Localization

The upcoming sections till section 4.5 will answer sub-question 1: Which combination of
hardware and algorithmics is suitable to be used with Robot Operating System to localize
the Robotino within the Festo office during autonomous navigation?

4.1 Task environment

The theoretical framework (section 2.1) states that defining the task environment can be
used to determine which type of localization, obstacle detection, and pathfinding can be
used. This section shows the results of the PEAS analysis and the environmental properties.

Performance measure The first part of the PEAS analysis is the performance measure.
The performance measures are based on Festo’s wishes for this project and written in the
requirements specification document. Based on this requirements specification, the agent
contains the following performance aspects:
• It must be robust. The agent is considered to be robust when the Robotino and its
additional hardware do not loosen over time when the Robotino is operating.
• It must be fast and start operating within 10 seconds;
• It must be interoperable with an external web interface;
• It must be reliable throughout time. The agent is considered to be reliable when its
navigation and localization accuracy stays similar throughout a working day. This
means that its navigation and localization accuracy must not decrease;
• It must be modular and modifiable when extra hardware is required;
• It must be testable when the agent is finished.

Environment observation The second part of the PEAS analysis is the environment
observation. This starts in the lobby. The lobby is the place where visitors will arrive when
they visit Festo. This place is a somewhat unchanging environment, but there are many
tricky obstacles that the Robotino could encounter. There are several objects which could
be hard for sensors to detect, like chairs and tables (figure 4.1). Besides, the lobby is a wide

27
and open place with a big surface area. This is important to take into consideration when
deciding the method for indoor positioning of the Robotino.

(a) Tables and chairs in lobby (b) Wide overview of lobby

(c) Chairs and glass table (d) Floor and desk in lobby

Figure 4.1: Lobby where visitors arrive

In the hallway towards the eXperience Center and the eXperience Center itself, several
objects can influence how the Robotino navigates. There are several showcase setups that all
have a gap between the floor and the showcase (figure 4.2). These gaps are usually around
8cm vertically.

28
 (a) Showcases in the hallway (b) Random temporary objects

(c) Table in hallway (d) Desks around hallway

Figure 4.2: Obstacles that the Robotino will encounter

There are several reflective materials on the path that can influence performance (figure
4.3). Most walls have light colors (e.g., white or gray) and have a non-glossy finish. However,
there are several objects on the path where the Robotino has to navigate that are different.
For example, there are several reflecting surfaces, which could be hard to be detected by
sensors according to Koch et al. [30].

29
 (a) Metallic reflective objects (b) Mirror-like automatic sliding doors

Figure 4.3: Noteworthy surfaces

Different sensors have different ranges for which they are suited. Hence, it is necessary
to gather all the dimensions of the environment where the Robotino will operate. All di-
mensions have been measured using a Bosch GLM 50 C laser distance measure tool having
an accuracy of ±1, 5mm. The outline of the environment is added in appendix A. Primarily
the area dimensions and dimensions of objects are relevant since they influence the decisions
of the Robotino the most.

Other notable dimensions are the dimensions of objects with legs. Examples are tables,
chairs, and showcase units. These objects could be difficult to detect based on the choices of
sensors. There is a variety of tables and chairs. Some are smaller than the Robotino; others
are larger. Larger objects are worth mentioning since the Robotino could drive underneath
them, which is not desired, as per the requirements specification document. Objects smaller
than the Robotino could also be problematic since the sensors might only detect the legs of
(for example) a table but not the tabletop itself. This would result in a collision.

Actuators The third part of the PEAS analysis is the actuators of the Robotino. The
Robotino contains only one set of actuators: three omnidirectional wheels. The wheels are
mounted at the base of the Robotino. This makes the Robotino holonomic [31]. A robot is
holonomic when its controllable degrees of freedom is equal to its total degrees of freedom.
The omnidirectional wheels give the Robotino the following degrees of freedom: move in
±x direction, ±y direction, and rotate ±θ degrees around its axis. All these directions are
also controllable individually. This information is useful to define the navigation behavior
or obstacle avoidance when controlling the Robotino.

Sensors The last part of the PEAS analysis is the sensors of the Robotino. The following
sensors are present:
• Nine infrared distance sensors with a range of 30 centimeters;
• One bumper sensor around the perimeter of the Robotino;

30
 • One inductive sensor for detecting metal surfaces;
• Two optical sensors for line following purposes;
• One Inertial Measurement Unit (IMU);
• One rotary encoder for each omnidirectional wheel.

Environment definitions Based on the observation research, the environment can be

modeled based on the method proposed by Russel and Norvig [11]. As described in the
theoretical framework (chapter 2), the SLAM algorithm must be solved for localization of
the Robotino. The SLAM algorithm of choice must therefore be able to work with the
properties of table 4.1.
Observable The environment is partially observable. Several rooms are enclosed by
walls that can only be observed after entering the room. This means
that only one room can be observed at the same time.
Agents The environment is a multiagent environment. At any time, it could
be possible that both the Robotino is present and employees or visi-
tors. People could interact with the Robotino, and the Robotino makes
decisions based on the presence of people. Hence, the environment is
multiagent.
Competitive This property is hard to define since it is neither distinctly competitive
or cooperative nor cooperative. The environment, however, is closer to the competi-
tive type, since the Robotino will have to work alone to reach its goal
and outperform other agents.
Deterministic The next state of the environment cannot be determined based on its
or stochatic current state. This is mainly since the entire environment cannot be
observed at once, and interference of other agents is possible. The
environment is therefore stochastic.
Episodic or The environment is sequential since the agent’s current decisions will
sequential influence its decisions later on in the navigation process.
Static, The environment is dynamic. Other agents can appear in the environ-
semi-static or ment and even alter it while executing navigation.
dynamic
Discrete or Time is continuous in the environment; the agent does not perform its
continuous execution in discrete steps.
Known or The environment is unknown. The environment could become known
unknown after an initialization process.

Table 4.1: Environment definitions

4.2 SLAM hardware considerations

Solving the SLAM problem requires additional hardware. The Robotino’s sensors alone are
not sufficient for solving the SLAM problem. Solving the SLAM problem must be done by

31
sensing the objects in an environment and determining their location relative to the Robotino.
The only distance sensing devices are the 9 infrared sensors embedded in the bumper. They
can only sense a range between 4cm and 30cm. Besides, they can only measure a one-
dimensional distance line. This is not adequate for solving the SLAM problem.
Solving the SLAM problem requires odometry sensing devices to determine the direction
of the Robotino. The Robotino contains both rotary encoders and an IMU. The IMU is an
Inversense MPU-6000. According to the datasheet [32], the MPU is adequately accurate for
SLAM. Almost all sensors have some non-linearity in their measurements [33]. This means
that a linear acceleration or deceleration will not always register to be linear. There will
be some deviation. The gyroscope of the MPU has a non-linearity of 0.2% compared to
the hypothetical perfect linear line. The accelerometer has a non-linearity of 0.5%. SLAM-
solving algorithms always have the ability to correct errors. The current MPU is thus
sufficient to be used for odometry. The MPU also contains a temperature sensor for self-
calibration with temperature changes. The datasheet of the rotary encoder does not contain
any accuracy specification [34].

Range measurement There are several types of sensors that can be used to measure
range. However, for solving the SLAM problem, not every range sensor is sufficient. Firstly,
the sensor must be able to sense long distances. The biggest environment in which the
Robotino operates is approximately 20 by 17 meters wide and 7 meters high. The Robotino
should be able to determine its location in this environment. This means that the sensor
must be able to sense these distances. Next, several objects contain legs. Examples are
chairs and tables. These objects must be detected entirely . It should not be the case that
the Robotino drives underneath a table because its sensors didn’t detect it. Detecting these
types of objects means that the distance sensors must sense the distance in both azimuth
(horizontal) and elevation (vertical). There are also reflective surfaces, which are difficult
to deal with for some sensors. Lastly, the sensor must be able to interface with ROS and
the Robotino. This takes bandwidth, power consumption, and available ROS libraries into
consideration.
There are two main types of sensors that can sense depth for long distances in both
azimuth and elevation [35]. They are Time Of Flight (TOF) and Triangulation. Time of
flight works similar to radar. It sends out an electromagnetic wave that bounces back from
an object. The time it takes for a wave to transmit and return to the receiver is used to
determine the object’s distance. The formula for TOF is 2d = ct, where d is the distance to
the object, c is the speed of light (constant), and t is the measured time of travel. A TOF
sensor measures time t to derive distance d. There are many types of TOF sensors, all using
different wavelengths. Arguably the most famous type of TOF sensor is the light detection
and ranging sensor, also known as LIDAR. LIDAR typically makes use of lasers to measure
distance. There are three main types of LIDAR sensors:
• LIDARS that emit one single beam. They only measure the distance of one point;
• LIDARS that emit beams in a 2D plane They measure distances in a cross-section of
an environment (azimuth only);
• LIDARS that emit beams in a 3D surface. They measure distances both cross-section
(azimuth) and height (elevation).

32
Only the 3D LIDAR would be sufficient for this project because both azimuth and elevation
information are required.
Another TOF technique is to use radar. Radar works with the same principle as LIDAR
but operates in a different frequency range. Radar uses lower energy waves compared to
LIDAR. The advantages of radar are that their performance is not influenced by reflecting
surfaces, and their distance measurement accuracy is high [36]. They also work well in
dusty or rainy areas, where LIDAR would fail. They are also more robust since they do not
carry any moving components. Texas Instruments provides mmWave radars for autonomous
robotics. At the moment of writing, their radars are the only radars in this class that are
compatible with ROS.
The second type of distance sensors are triangulation depth sensors. Triangulation depth
sensors make use of two sensors to measure the angle between a point in an environment.
A fixed distance separates the two sensors. When the angle is determined between the
two sensors, the distance can be measured using trigonometric algebra. A commonly used
technique of measuring depth with triangulation is via depth cameras. Depth cameras usually
consist of a pair of two image sensors having a fixed distance in between them. A great
explanation of stereo cameras is written by Ortiz et al. [37]. Figure 4.4 shows the principles
of how stereo cameras operate. The two cameras Ol and Or have a horizontal distance apart
called the baseline B. Both camera’s have a focal length, fl and fr . Let the object L be an
arbitrary object. On the left and right images, the object appears at a different point. They
are shifted from the principle ray with a distance of xil and xir . The disparity d is the the
difference in the distances from the principle ray, d = xil − xir . With this information, the
depth of an object can be calculated by the following formula: D = fdB . When the distance
between the camera and an object gets larger, the disparity becomes smaller. A smaller
disparity results in a higher error since it will become more difficult to match the pixels and
measure the disparity. This results in a correlation: objects that are further away are less
accurately measured. Increasing the baseline distance will increase the disparity between
objects. This means that a bigger baseline will result in better range estimation.

33
 Figure 4.4: Depth estimation using stereo cameras [37]

Hardware choices All hardware choices must be made before making decisions about the
exact SLAM algorithm. The type of depth sensor is arguably the most influential factor on
which the SLAM algorithm will be used. Some SLAM algorithms are more suitable with
visual data (video streams or images), while others are more suitable for pure depth data.
For this case study, it is of importance to have a rich set of input data. There are
many types of obstacles, all having different structures and types of surfaces. Based on the
environment observation from the PEAS analysis, the conclusion is that the depth sensor
must have the following requirements:

• Must sense depth for large distances of ≥ 20m;

• Must sense in both azimuth and elevation to detect chairs and tables;
• Must detect reflecting materials;
• Must have a wide field of view;
• Must be able to differentiate obstacles from each other;
• Must have a power consumption lower than 72 Watt, preferably as low as possible to
conserve battery drainage;
• Should be compatible with ROS;

One of the requirements is that the sensor is compatible with ROS. Some sensors are
directly compatible with ROS via existing libraries and interface via USB or Ethernet con-
nections [38]. Others are not directly compatible but can be made compatible by developing
an interface with the ROS master device. One way is to use development boards, like an
Arduino, to connect the sensor and interface with the ROS master device. In essence, this

34
makes every sensor compatible with ROS. For this reason, this requirement will not be taken
into consideration when choosing a sensor. Based on the requirements, several types of depth
sensors can be discarded immediately. Any 1- and 2-dimensional sensor will not be adequate.
For example, infrared, ultrasonic, and 1- and 2-dimensional LIDAR sensors are not sufficient.
They cannot sense depth in 3D, which is one of the requirements. There are three candidate
sensors left that can sense depth in 3 dimensions:

• 3D LIDAR
• mmWave Radar
• Depth camera

3D LIDAR and depth cameras have one flaw in common. They do not work well with
reflective and transparent surfaces [36]. In the environment of the Robotino, there are two
major reflective surfaces. The first obstacle is a mirror-like automatic door at the entrance.
The second obstacle is a large metallic storage unit in the eXperience Center. If these
obstacles are not detected, the Robotino might bump into them.
3D LIDAR has three other big disadvantages. Firstly, they are expensive. The cheapest
ROS-compatible 3D LIDARS can easily exceed €2.000 [39, 40]. The second flaw is that those
cheapest versions do not have lots of elevation depth information, often only 16 horizontal
laser beams spread in an angle of not more than 20◦ . Lastly, they are power-hungry. LIDARS
often use at least 10 watts of operating power. This is because they contain mechanical parts
and powerful laser beams. An advantage is its accuracy at large distances. LIDARS are often
accurate up to several centimeters at ranges of over 150 meters.
mmWave might be sufficient, but this is not certain. In theory, mmWave has a good
range and works well with reflecting surfaces. Texas Instruments (TI) provides two suitable
mmWave sensors. However, in their specification sheet, they state “long-distance radar”
and “short distance radar”, but they do not specify any actual numbers [41]. Besides, the
datasheet shows that accuracy decreases substantially when the angle in azimuth or elevation
increases. Also, there are very few examples of the implementations of mmWave with SLAM.
Only Texas Instruments (TI) has one single example at the time of writing this thesis. Based
on the lack of information, choosing mmWave would be a risky investment.
Depth cameras have a good chance to be used to solve the SLAM problem. There
are many cameras available that also have ROS integration [38]. Many SLAM algorithms
work well with depth camera information (and visual information in general). For exam-
ple, depth cameras work excellent with algorithms that solve the loop-closing problem [20].
However, they lack reliability with reflective surfaces. Reflective surfaces might or might not
be detected. This depends on the specific implementation of the SLAM algorithm. SLAM
algorithms that use depth cameras require more processing power than LIDAR since process-
ing visual information is computationally expensive. In comparison, LIDARs simply work
with collections of 3D points in space. No visual information must be processed. Hence,
stereo cameras have a higher density of information compared to LIDAR or mmWave. The
information is summarized in table 4.2.

35
 distance Wide Diff. Low
Sensor Azim. Elev. Refl. Price
≥ 20m FoV obstacles power
Ultrasonic × × × X × × X €1-€20
IR Sensor × × × X × × X €1-€20
1D €20-
X × × × × × X
LIDAR €200
2D €200-
X X × × X X X
LIDAR €2000
3D €2.000-
X X X × X X ×
LIDAR €10.000
Depth €200-
X X X ? X X X
camera €5.000
mmWave €150-
? X X X ? ? X
radar €350

Table 4.2: Sensor type comparison.

Azim.:azimuth, Elev.elevation, Refl.:detects reflection, Diff. obstacles: differentiate individ-
ual obstacles.

Hardware investment approach There is no single sensor that works flawlessly with
all requirements. For this reason, the best decision is to start with the sensor that is most
likely to succeed. If this sensor does not fulfill the requirements, additional sensors might
be combined to make the system more reliable. Based on the sensor comparison, depth
cameras are most likely to succeed. A suitable depth camera will be used to solve the SLAM
algorithm. If the depth camera does not work properly with reflective surfaces, mmWave
sensors can be added to detect reflective surfaces.

Stereo camera comparison There are many types of stereo cameras available. Not all
of them are suitable for this project. The most important property is that the camera is
compatible with ROS. It must be able to convert an image into depth information that
ROS can use. Many stereo cameras are available for ROS. A comprehensive list of available
cameras is given on the official ROS website [38]. Each camera property is found on its
manufacturer’s official website. Table 4.3 shows a comparison of the available ROS depth
cameras. From the ROS sensor list [38], only the depth cameras are used for comparison.
All non-depth cameras are removed since they are useless for this project. Several camera-
specific requirements are taken into account. These are additional to the general depth
sensor requirements. They are as follows:

• Must interface via USB or Ethernet;

• Should have built-in odometry with sensor fusion;
• Should have hardware-accelerated depth detection;
• Should be factory calibrated;
• Should have automatic self-calibration;

36
 • Could have internal magnetometer sensor for cardinal direction orientation;
• Would have a Software Development Kit (SDK) for extra necessary development;
• Would have an active ROS community for support.

The table also compares active and passive cameras. This refers to the type of depth
perception. Active depth cameras emit an infrared (IR) light pattern, like in figure 4.5. This
pattern is projected on obstacles. This is not visible to the human eye. However, the camera
can see this pattern and calculate depth information. Passive stereo cameras do not use such
patterns but work similarly to the human eye. They simply calculate the disparity based
on pixel matching. Hence, fundamentally, the cameras work using the same principle by
calculating distance using disparity.

Figure 4.5: Depth camera that projects IR pattern [42]

Not all available sensors are in the table. Only reasonable cameras are compared. For
example, several military-grade cameras have price tags of ≥€5.000. Other cameras are
technically supported, but their libraries and hardware are deprecated, or they lack good
resolution (e.g., ≤ 50x50 pixels). These non-sensible options have been left out. Table 4.3
only shows options that have the potency to be used for this project.

37
 Fact. Self
Man. Prod. Type Ran. Res. Conn. FoV Pow. Price IMU Acc. Magn. SDK Act. Note
Cal. Cal.
AD-
640 USB 90
Analog [43] 96TOF1- A 6m 20W 715 × × ? ? × X ×
480 Eth 69.2
EBZ
DCC- 640
Ciscorp [44] A 5m USB ? 7W 1291 × × ? ? × X X
RGBD1 480
MDC 320 92
Cube Eye [45] A 6m USB 4W 255 × × ? ? × X X
600S 240 67
DUO 752
Duo3d [46] A ? USB 165 2.5W ? X X X X × X X
ML× 480
1920 70
Microsoft [47] Kinect A 4.5m USB 16W 130 × × ? ? × X X
1080 60
Azure 1024 75
Microsoft [47] A 5m USB 5.9W 800 X × ? ? × X X
Kinect 1024 65
Nimbus 352 66 Made for
Pieye [48] A 5m × ? 202 × × ? ? × X X
3D 288 54 Raspberry Pi
Real- 1280 87
Intel [49] A 6m USB ? 319 × X X ? × X X Widely used
sense 800 58
Astra 1280 60
ORBBEC [50] A 8m USB 2.4W 150 × × ? ? × X X
Pro 720 49.5
4416 110 Most extensive
Stereolabs [51] ZED 2 P 40m USB 1.9W 467 X X X X X X X
1242 70 ROS support
Lack good ROS
752 146

38
Mynt eye [52] S1030 A 20m USB 2.7W 200 X X X ? × X × Support; Only
480 122
for Ubuntu 16.04
352 60
IFM [53] O3D303 A 30m Eth 10 1510 × × ? ? × X X
264 45

Table 4.3: Comparison of depth cameras

Columns from left to right: Manufacturer, Product, Type (Active or Passive), Range, Resolution, Connectivity, Field
of View, Power usage, Price, IMU sensor, Accelerometer, Factory calibrated, Self-calibration, Magnetometer, SDK available,
Active ROS community, other notes.
Camera of choice There are two good choices for this project: the Stereolabs ZED 2 and
the Mynt eye S1030. The S1030 has two benefits that the ZED 2 lacks: being an active
camera and being cheaper. An active camera has the benefit that it works better in dim
environments. This, however, is not a real advantage for this PoC since the environment is
always brightly lit. There are also negative points. The S1030 does not seem to be very well
integrated with ROS. The website does not mention ROS support, and its library does not
seem to be maintained frequently. There is also a lack of documentation on the ROS library;
it is very sparse. The ZED 2 has the advantage that it is packed with useful sensors for
the SLAM algorithm. It contains a sensor fusion algorithm using its IMU, magnetometer,
and image data. This means that the camera can estimate its pose by performing a SLAM
algorithm internally. It contains thermal sensors to rectify the image based on its thermal
expansion properties. Besides, the camera comes pre-calibrated from the factory. The ZED
2 comes with a frequently maintained ROS library filled with several example projects. The
ZED 2 camera also has the capability to do object detection and classification using an on-
board artificial intelligence processor. This can be useful for future updates to detect, for
example, the presence of people in its navigation path. Both cameras require a PC that runs
an Nvidia CUDA graphics card for hardware acceleration. This is an addition that must be
purchased.

The final decision is to use the ZED 2 camera. Based on its sensors, capabilities, and
stable ROS integration, it is the best choice for this project.

ZED 2 requirements Several hard- and software aspects are needed to run the ZED 2
using ROS. The ROS library for the camera makes use of the ZED SDK. At the time of
writing, this SDK is at version 3.5 [54]. This version of the SDK has several requirements
and recommendations to run [55]:

• Processor: Minimum: Dual-core 2,3GHz. Recommended: Quad-core 2,7GHz or faster

• RAM: Minimum: 4GB. Recommended: 8GB
• Graphics Card: Minimum: Nvidia GPU with Compute Capability ≥ 3 and CUDA
10.2 or 11. Recommended: GTX1060 or higher
• USB: 3.0
• OS: Windows 10, Ubuntu 16.04, 18.04

The support page also specifically mentions embedded computing platforms from Nvidia,
the Jetson product range. They are as follows:

• Processor: Jetson Nano, TX2, Xavier

• RAM: 8GB
• Graphics: Nano, TX2, Xavier
• USB: 3.0
• OS: L4T (Jetpack)

39
The Robotino contains the following specifications:

• Processor: Intel i5, 2,4GHz dual core

• RAM: 8GB
• Graphics: Intel integrated graphics
• USB: 2.0
• OS: Ubuntu 20.04

It is clear that several specifications do not fulfill the requirements. The processor is only
0.1GHz above the bare minimum. This does not leave much room for other processing tasks,
like solving the SLAM algorithm. The amount of RAM is sufficient. The graphics are the
biggest problem. The integrated Intel graphics do not fulfill the requirements. The SDK
makes use of CUDA to compute depth information [56]. According to Nvidia, CUDA is
“a parallel computing platform and programming model developed by Nvidia for general
computing on graphical processing units (GPUs)” [57]. The Intel integrated graphics do not
contain CUDA and Compute Capability 3.0. Furthermore, the Robotino has USB 2.0, which
is not sufficient.

Additional required hardware To make the ZED 2 camera work, the following missing
hardware is required:

• Nvidia Graphics with CUDA and Compute Capability 3.0

• USB 3.0
• Ubuntu 16.04 or 18.04

The Robotino runs on “Robotino OS”, which is basically Ubuntu with some extra pre-
installed packages and scripts. The Robotino Wiki contains the entire history of the released
Robotino OS versions [58]. This includes Ubuntu 18.04 and 16.04. These versions can be
downloaded and installed. The Nvidia graphics and USB 3.0 compatibility is a bigger issue.
There are two options available to access USB 3.0 and Nvidia graphics, which are discussed
in the following paragraphs.

Option 1: PCI Express upgrade The first option is to upgrade the Robotino itself.
There are limited upgrade capabilities available. The Robotino contains two PCI Express
X1 slots. These can be used to insert both a graphics card and a USB 3.0 adapter. The
main problem arises with the choice of GPU. At the time of writing, only two Nvidia GPUs
are available that fit in an X1 slot. The Zotac GeForce GT 710 1GB and the Asus GT710-
4H-SL-2GD5. The cards have an identical GPU chip (the Nvidia GT 710), only the Asus
has more video memory available (2GB instead of 1GB). The ZED 2 ROS documentation
recommends at least 2GB of video memory. The Zotac and Asus cards are otherwise similar
in price and performance, so the obvious choice would be to use the Asus graphics card. It
contains 192 CUDA cores and uses a minimum of 19W of power.
The biggest problem with the available graphics cards is that there is a big lack of
information. The Nvidia website does not state the existence of this GPU anywhere. There

40
are also no drivers available or any datasheets. There is no mention of the CUDA version
and Compute Capability on both the Asus and Nvidia websites. For this reason, this would
be a tricky option. Relating to USB 3.0 PCI Express cards, there are plenty of options
available.

Option 2: Nvidia Jetson product line The other option, suggested by Stereolabs
themselves, is to use Nvidia’s embedded computing platforms: their Jetson product line.
The Jetson products are embedded compute modules. Normally, these modules are cards
that can be embedded inside robotics or other machines. Nvidia also supplies development
kits that contain these compute modules. The development kits are equipped with USB,
HDMI, WiFi, Bluetooth, Ethernet, cooling solutions, and more. Using these development
kits makes it very accessible to use these compute modules and connect them with the
Robotino. The Jetson also supports ROS. This makes it possible to do divide workloads by
executing graphical computation on the Jetson while executing other computational tasks
on the Robotino itself. In essence, they are two individual PCs that can communicate with
each other.
It is important to mention that all of the Nvidia Jetson boards require some sort of power
input. There are multiple power connectors available on the Robotino that supply 24V. This
has to be converted to a proper voltage based on the properties of the chosen board.

Comparison Because of the lack of information and support for the Asus GT710-4H-
SL-2GD5, it is not an acceptable choice. It is preferred to use one of the Nvidia Jetson
development kits. As mentioned before, the development kits contain the actual compute
modules. Table 4.4 contains a comparison of the development kits with their modules.
Dev. kit CPU GPU cores Archit. Memory Storage Power Connectivity Price
HDMI
1x USB 3.0
4-core Maxwell 2GB 2x USB 2.0
Nano 2GB 128 CUDA MicroSD max. 10W €72
1.43GHz 0.921GHz 25.6GB/s 1x Micro USB
Ethernet
WiFi dongle
HDMI
Display Port
4-core Maxwell 4GB MicroSD 4x USB 3.0
Nano 128 CUDA max. 10W €105
1.43GHz 0.921GHz 25.6GB/s M.2 1x Micro USB
Ethernet
WiFi dongle
HDMI
10W to 15W Display Port
6-core 384 CUDA Volta 8GB Micro SD Depending 4x USB 3.1,
Xavier NX €419
1.4GHz 48 Tensor 1.37GHz 52.2GB/s M.2 NVME on settings 1x Micro USB
and usage WiFi
Bluetooth
HDMI
PCIe
32GB eMMC 30W to 65W
8-core 512 CUDA Volta 32GB Ethernet
AGX Xavier Micro SD Depending on €729
2.26GHz 64 Tensor 1.37GHz 137GB/s SATA
M.2 NVME peripherals
WiFi
Bluetooth

Table 4.4: Comparison of Nvidia Jetson development kits

41
Additional hardware decision The decision is to purchase the Nvidia Jetson Xavier
NX. It fulfills the recommended system requirements for the ZED ROS Wrapper. Other
computational tasks can possibly be performed as well, depending on the amount of process-
ing power that is still available when running the ROS SDK. Computational tasks can also
be divided between the Robotino and the Jetson; the Jetson can be seen as an extension
or upgrade to the Robotino. The Nano 2GB and Nano do not fulfill these recommended
system requirements. Compared to the Nano 2GB and the Nano, the Xavier NX uses the
newer, faster, and more efficient Volta architecture. Its CPU and memory speeds are also
faster, resulting in higher computational performance. Its downside is that it consumes 5W
more power. It also costs €314 more than the Nano; however, it is no issue and well within
the financial expectations. The AGX Xavier has more cores and overall higher performance,
but this comes at the cost of 30 to 65 Watts of power and an additional €310. This extra
performance is not necessary, making it not the right choice.

Power supply The Jetson Xavier NX requires a power input of 9 to 20V and has a power
budget of 15W. The Robotino, however, supplies 24V, which is too high. For this reason, an
additional power converter is necessary. Mean Well is chosen as the preferred power supply
brand. Mean Well produces power supplies exclusively, resulting in high-quality products
with high efficiencies [59]. Their RSD-30L-12 converts 24V down to 12V with high efficiency
(90%) and a maximum of 30W, making it perfect for this project. Also, it is available in a
lot of webshops (including Festo’s direct suppliers). Extensive comparisons (similar to the
camera and compute module comparisons) of power supplies are out of this project’s scope.
The main property to compare would be the efficiency of the power supplies. This does not
directly influence the research questions of this thesis, which is focused on finding a good
combination of hardware and algorithmics for navigating the Robotino. Also, Mean Well is
well known and used at Festo and a preferred supplier for power adapters and converters.
An overview of the total combined hardware is provided in figure 4.6.

Figure 4.6: Overview of hardware

4.3 SLAM algorithm considerations

SLAM problem properties There are many sorts of SLAM-solving algorithms available.
They all have specific properties that make them suitable for specific situations. The exact
choice of algorithm depends on the properties of the specific SLAM problem for this case
study. The properties are visible in table 4.5. Detailed descriptions of each property are
available in chapter 2.3 and 2.3.

42
 Property Choice Reason
Full SLAM vs. Online Full SLAM saves the entire path, always. At some point,
online SLAM RAM will be full.
Volumetric vs. Volumetric Robotino has to deal with chairs, tables, and other diffi-
feature-based cult obstacles. These obstacles need to be mapped com-
pletely.
Topological vs. Metric Robotino needs to navigate based on exact dimensions.
metric Topological is not sufficient.
Known vs. Unknown There aren’t many objects that can “confuse” the SLAM
unknown algorithms location approximation. Hence, unknown cor-
correspondence respondence will suffice
Small vs. large Small The path of the Robotino is approximately 50 meters,
uncertainty and there are not many path options. This keeps the
uncertainty small.
Active vs. Passive There are places that the Robotino shouldn’t explore. A
passive joystick or controller should be used to build the map.
single-robot vs. Single- There is only one Robotino.
multi-robot robot
Any-time and Any-time There are limited computational resources. If possible,
any-space vs. and the SLAM solving algorithm should adapt to the available
regular any-space resources.
Static vs. Dynamic People are walking in the environment. Also, objects
dynamic could be moved around during navigation.

Table 4.5: SLAM properties of the case study

SLAM technical properties Besides the SLAM properties for this case study given in
table 4.5, more technical details are required when choosing an algorithm. These techni-
cal details are available inputs for the SLAM algorithm, the desired output(s), technical
implementations, and more.
The ZED camera ROS package outputs several sources of data [60]. According to the
website, it broadcasts the following topics:

• Left and right camera images in color, grayscale, calibration-rectified and raw;
• Camera calibration data;
• Rectified and non-rectified stereo images;
• Depth map, point cloud, confidence map, and disparity image;
• Absolute pose and odometry, the pose with uncertainty covariance, the odometry and
pose path;
• A fused point cloud map;
• IMU, atmospheric pressure and temperature data;
• Detected objects;

43
 • Other diagnostics.

In order to interface with these topics, it is necessary that the SLAM algorithm is available
as a ROS package. For example, the default Stereolabs SLAM algorithm (ZEDfu) is a
standalone application [61]. Implementations like these do not interface with ROS, making
them hard to use. These topics can be used as inputs for the SLAM algorithm. For this
reason, the SLAM algorithm must use at least one of the depth topics. It is also desired that
the chosen SLAM algorithm outputs an occupancy grid. An occupancy grid is a map of the
environment with the mapped obstacles. This occupancy grid is useful for allowing the robot
to actually navigate throughout an environment. An occupancy grid shows where obstacles
are and where free space is available. It is required that the SLAM algorithm can at least
generate a 2d occupancy grid to determine where the Robotino can drive and where obstacles
are. It is also desired that the occupancy grid can be generated in 3 dimensions. In this way,
the navigation algorithm can understand that a door (or hole in a wall) is something that
the Robotino can pass through. It will also understand that a table is an obstacle as well,
instead of driving underneath it. Besides mapping, it is also necessary that the algorithm
can be used to localize itself by outputting an estimated pose. For some algorithms, only
mapping is included without outputting a pose estimation.
According to Thrun et al. [20], several state-of-the-art SLAM algorithms work based
on visual information. This is called Visual SLAM, or V-SLAM. Non-V-SLAM algorithms
depend purely on depth data, like LIDAR or radar depth data. The advantage of V-SLAM
is that it can localize a robot in all six degrees of freedom (X, Y, Z, Roll, Pitch, Yaw).
According to the paper, V-SLAM also allows for excellent loop-closure and works well when
the robot needs to relocate after its being powered off. V-SLAM algorithms can generate
dense maps with lots of information about the environment, which helps solve the SLAM
problem. The only downside is computational performance since V-SLAM is slower than
pure depth-based SLAM. V-SLAM is the preferred method because of its superiority and
the fact that the ZED ROS package outputs both images and depth information.
Lastly, it is required that the chosen V-SLAM algorithm can be extended with an addi-
tional depth sensor. This would be the case if the ZED 2 camera cannot detect reflecting
obstacles, resulting in additional mmWave sensors. The algorithm should be able to fuse the
information from the stereo camera with the additional depth information. If the algorithm
cannot do this, an additional package must be written from scratch to realize this. The
technical requirements for the SLAM algorithm are summarized in the following list:

• Must be a ROS package;

• Must work with the camera/depth messages from the ZED ROS package;
• Must be V-SLAM;
• Must output an estimated pose;
• Should output an occupancy grid;
• Occupancy grid should be in both 2D and 3D;
• Should be able to input a non-visual sensor next to the ZED 2.

44
Algorithm comparison There are several SLAM algorithms available for ROS. A com-
prehensive comparison of several ROS-compatible SLAM algorithms has been executed by
Filipenko and Afanasyev [62]. An evaluation of different ROS SLAM algorithms is also
discussed by Kolhatkar et al. [63]. This paper also discusses different hardware platforms,
including the Nvidia Jetson series. Labbé and Michaud [64] compare several ROS algorithms
based on their available inputs and outputs. Lastly, both the ROS Wiki and Github searches
revealed a few extra SLAM implementations. All this information has been merged into ta-
ble 4.6. The approach is first to find a suitable algorithm based on the required inputs and
outputs. Then, the suitable algorithms are checked based on the previously discussed SLAM
problem properties.

Table 4.6 compares many ROS SLAM implementations. It is clearly visible that RTAB-
MAP is the only algorithm that checks all the boxes. It accepts both a stereo camera
and mmWave inputs for its algorithm. It relies on the detection of visual features in the
environment, making it a visual SLAM algorithm. It is the only algorithm that accepts
more than one sensor as input. RTAB-MAP also calculates and outputs its current pose, as
well as a 2D and 3D occupancy grid. This is highly useful for implementing a navigation
algorithm.
Conveniently, RTAB-MAP also fulfills every single one of the SLAM problem properties
from table 4.5. This can be deducted from the official RTAB-MAP paper [64]. An overview
of RTAB-MAPs properties is given in table 4.7. RTAB-MAP is also widely supported by the
Stereolabs ZED community [65, 66], which helps during development and troubleshooting.

45
 ROS Inputs ROS output topic
Visual 2D 3D
Algorithm Stereo camera mmWave Simultaneous Pose
SLAM Occupancy Occupancy
GMapping [62–64] × × × × X X ×
TinySLAM [64] × × × × X X ×
Hector SLAM [63, 64] × × × × X X ×
ETHZASL-ICP [64] × × X × X X ×
Karto SLAM [64] × × × × X X ×
Lago SLAM [64] × × × × X X ×
Cartographer [64] × × X × X X ×
BLAM [64] × × X × X X ×
SegMatch [64] × × X × × × ×
VINS-Mono [64] × × × × X X ×
ORB-SLAM [62–64] X X × × × × ×

46
PTAM [62] X X × × X × ×
S-PTAM [62, 64] X X × × X X ×
DVO-SLAM [64] X X × × X X ×
RGBiD-SLAM [64] X X × × × × ×
MCPTAM [64] X X × × X X ×
RGBDSLAMv2 [64] X X X × X X X
RTAB-Map [62–64] X X X X X X X
CoreSLAM [67] × ? × × X × ×
DPPTAM [62, 63, 68] X X × × X X X
LSD-SLAM [62, 69] X X × × × × ×
vslam [70] X X × × ? X ×
SVO [62] X X × × X × ×

Table 4.6: Comparison of the most common ROS SLAM algorithms

 Property RTAB-MAP Fulfills Reason
require-
ment
Full SLAM vs. Online X The current pose is not based on the
online SLAM entire previous calculations. It is cal-
culated based on its current informa-
tion, not on the past.
Volumetric vs. Volumetric X RTAB-MAPs outputs are volumetric.
feature-based It outputs point clouds, as well as 3d
occupancy grids.
Topological vs. Metric X RTAB-MAP outputs realistic metric
metric maps instead of mathematical ab-
stract ones.
Known vs Unknown X RTAB-MAP uses feature matching,
unknown which is unknown correspondence. It
correspondence can, however, also use known corre-
spondence, since it supports AprilTag
detection.
Small vs. large Small X The environment has small uncer-
uncertainty tainty. Every SLAM algorithm works
with at least small uncertainty.
Active vs. Passive X RTAB-MAP does not have any auto-
passive matic exploring features.
single-robot vs. Single-robot X Although RTAB-MAP allows for
multi-robot robots to share information, this can
be disabled. It is a nice-to-have fea-
ture for possible future upgrades.
Any-time and Any-time and X RTAB-MAP allows for filtering and
any-space vs. any-space performance controlling based on the
regular available hardware. This is done via
parameter tuning.
Static vs. Dynamic X RTAB-MAP can differentiate static
dynamic and dynamic objects.

Table 4.7: SLAM properties of RTAB-MAP implementation

RTAB-MAP The RTAB-MAP algorithm is the chosen SLAM implementation. RTAB-

MAP stands for “Real-Time Appearance-Based Mapping”. It is an open-source implemen-
tation/algorithm developed by Labbé and Michaud [64]. According to their paper, one of the
goals was to make RTAB-MAP a complete navigation solution. The paper states that many
SLAM algorithms only perform mapping and localizing but do not provide anything useful
for autonomous navigation of robotics. RTAB-MAP tries to address this issue by allowing
multiple sensors as inputs and providing occupancy grids as outputs. These occupancy grids
can be used directly for the navigation of robotics.

47
 RTAB-MAP executes several steps to perform its mapping and localization [64]. First,
it retrieves depth, odometry, and hardware positioning data from a depth camera. These
data sources are synchronized based on their observation time and added in Short-Term
Memory (STM). The STM can be seen as a log file or database with previously explored
places. If this STM reaches a certain time threshold (that can be tuned via parameters), it
will move its STM to an internal Long-Term Memory (LTM) database. Next, RTAB-MAP
checks for the possibility of a loop closure. This means that it checks if a place has been
explored before. If this is true, it can perform Pose Graph Optimization (PGO) to correct for
errors. A more detailed description of PGO and loop closure are provided in the theoretical
framework (chapter 2. If RTAB-MAP is in mapping mode, any newly discovered data will be
appended to the map. Lastly, RTAB-MAP publishes the robot’s estimated location (based
on PGO and loop closure), as well as the assembled map. An overview of this process is
given in figure 4.7.

Figure 4.7: Flow chart of RTAB-MAP

According to Labbé and Michaud [64], There are several combinations of sensor data
that can be used as inputs for the RTAB-MAP algorithm. For a stereo camera, there are
two possibilities. The algorithm can use two images from each camera (stereo pair) or use a
pre-calculated depth map. When two images (stereo) are used, the RTAB-MAP algorithm
calculates a depth map from those images. The paper shows a comparison between different
combinations of inputs and outputs and their resulting performance. According to their
analysis, the fastest method is to directly feed a pre-calculated depth map instead of a
left and right stereo image. This is convenient since the ZED ROS wrapper is capable
of outputting this type of data. The ZED ROS wrapper uses the ZED SDK to generate
the depth image. This is a hardware-accelerated process that makes use of the hardware
capabilities of the Nvidia Xavier NX. RTAB-MAP also allows for an additional non-visual
depth sensor to be added. This can be LIDAR or a depth sensor that provides similar
non-graphical depth data.

48
4.4 Hardware placement
The following hardware needs to be mounted on the Robotino:

• ZED 2 stereo camera

• Nvidia Jetson Xavier NX
• Meanwell power supply

The hardware placement must adhere to the performance measures of the PEAS analysis.
This means that it must be robustly placed; it must not loosen when the Robotino is used.
It must also be built modular. The hardware must not be mounted onto the Robotino
permanently, and it must be possible to modify when necessary.

Camera placement The most influencing placement is the placement of the stereo cam-
era. The camera has a field of view of 110 degrees horizontally and 70 degrees vertically.
Inherently, any object out of this range is not detected. For this reason, the sensor has blind
spots where objects are not detected. Three examples of the placement of the stereo camera
are given in figure 4.8. To make the camera placement optimal, the following should be
achieved:

• There should be as few blind spots as possible;

• The maximum distance of a blind spot towards the Robotino should be as small as
possible;
• To detect as many obstacles on the floor on the Robotino’s path, there should not be
any blind spots.

In figure 4.8a, the camera is placed at the bottom of the Robotino. This results in a large
blind spot area and a large maximum blind spot distance towards the Robotino’s platform
and pole. In figure 4.8b, the camera is placed on top of the Robotino platform. This,
however, results in a large gap where no floor obstacles are detected. This is not practical
since some obstacle might occur that will be detected only at a 30cm distance (max. range
of IR range sensor). In figure 4.8c, the camera is placed somewhere in the middle. This is an
ideal location. It allows the blind spot of the field of view to match the maximum distance
of the IR range sensor. Where the camera FoV stops, the IR sensor takes over. This location
also ensures that the maximum distance of the blind spots towards the Robotino is as small
as possible. In conclusion, placing the camera somewhere in the middle would be ideal.
The height of the camera can be determined with some trigonometric calculations. The
field of view of the ZED 2 is 70 degrees. The distance of the IR sensor is 30cm. Hence,
the height of the camera h must be h = (30cm + ∆) ∗ tan(( 70 2
)◦ ). Here, ∆ is the additional
distance between the IR sensor and the center point of the camera. Let’s assume that the
camera will be placed 5cm closer to the center of the Robotino, relative to the bumper. Then
the height of the camera should be approximately 25cm.

49
 (a) Camera on bottom (b) Camera on top

(c) Camera somewhere in the middle. Camera

FoV edge matches IR sensor for full ground cov-
erage on direct path.

Figure 4.8: Some examples of stereo camera locations on Robotino. Light grey = FoV, dark
grey = blind spot.

50
Vibration analysis The placement of the camera is also influenced by one other factor,
namely the vibration of the Robotino. Based on some experiments prior to this thesis, it was
immediately clear that the omnidirectional wheels of the Robotino are not smooth at all.
The platform and base shake significantly while driving the Robotino around with a wireless
game controller. This vibration issue caused worries. When the vibrations pass on to the
camera, it can cause motion blur/unclear images. Motion blur is known to be an issue and
one of the weak points of V-SLAM [71]. For the RTAB-MAP algorithm and ZED 2 specific,
several articles are addressing the issues of motion blur [64, 72–74]. Also, the source code of
RTAB-MAP has several lines of code that reject blurry images to be used for its algorithm
[75].
RTAB-MAP makes use of feature matching. When RTAB-MAP is in mapping mode,
it takes pictures of its environment and stores its approximate location. Next, when the
algorithm is put in localization mode, it will take pictures and tries to match them with
its previously stored pictures to determine its location. This process is disturbed and less
accurate with blur. The ZED 2 does not have any specifications on optical- or software
stabilization. For this reason, it is preferred to minimize the vibrations of the stereo camera.

Experiment An experiment was executed to analyze the vibration of the Robotino. For
this experiment, an iPhone 12 Mini was used as a measuring device. An app called “Vi-
bration” by Diffraction Limited Design LLC [76] was purchased to measure vibrations. The
app can measure g-force and vibration frequency at high sampling rates over a period of a
maximum of 40 seconds. This iPhone was mounted firmly using tape at three locations on
the Robotino: on the base, at the middle of the pole, and on top of the platform. Next, for
each mounting location, the following route was driven:

1. Driving forward combined with steering right;

2. Driving forward combined with steering left;
3. Driving backward combined with steering right;
4. Driving backward combined with steering left.

This covers most possibilities of driving directions, including accelerating and decelerating
four times. The direct vibrations can be seen in figure 4.9a, 4.9b and 4.9c. The distribution
of the vibrations is visible in figure 4.9d, 4.9e and 4.9f. It is clearly visible that there is a
correlation between height and the amount of vibration. Also, the distribution plot shows
that there are way more shocks with high forces at higher locations. The ideal distribution
graph would have a peak at x = 0, meaning that there are only measurements of 0 g-
forces. In conclusion, the camera should be placed as low as possible to the Robotino base
to minimize vibrations.

51
 (a) Vibration at platform (b) Vibration at middle of pole (c) Vibration at the base

(d) Vibration distribution (e) Vibration distribution (f) Vibration distribution

at platform at middle of pole at the base

Figure 4.9: Vibration analysis of Robotino on at different places

Camera placement decision Based on the camera placement analysis, the camera should
be placed somewhere in the middle of the pole. However, based on the vibration analysis,
the camera should be placed as low as possible to the ground. To get the best of both worlds,
the camera will be placed on top of a stabilizer at a location similar to the middle of the
pole. In accordance with Festo and the graduation instructors, mounting the hardware is
done by building a prototype. This means that the final product is still open to improvement
and does not have to be perfected. This is because the main goal of the internship is about
hardware and software with ROS, and not so much about mechanical design.

Design At the front of the Robotino, there is a hole where additional hardware can be
placed. This space is unused by any other hardware and can be utilized for custom compo-
nents. This makes it the ideal location for mounting all hardware components.
The design consists of several layers, each containing a hardware component. These layers
are specifically designed to fit one of the components. The designs of the layers can be seen
in figure C.1 of appendix C. One of the layers contains screw holes to mount the Mean
Well power converter. Another layer contains the mount for the Nvidia Jetson. Important
for this layer is that it must be easy to place and remove the Jetson. This makes it easy to
debug and experiment without having the Jetson fixed in place semi-permanently (which is
the case for the power converter). On top will be a wire rope stabilizer, which is discussed

52
in the following paragraph. Each layer is stacked on top using stand-off screws. The stand-
off screws can be bought in various lengths, making it possible to adjust the height of all
components with centimeter precision. The camera is mounted using a 1/4-20 UNC screw,
which is fixed in place to the stabilizer using a custom milled aluminum bolt.

Stabilizer A wire rope stabilizer, also known as a wire rope vibration isolator, is used
to reduce vibrations that might occur at the camera [77, 78]. This type of stabilizer is
commonly used for photography. It has the following advantages:
• It does not require electricity;
• The stiffness and vibration absorb rate can be adjusted;
• The position of the camera can be adjusted;
• The rotation of the camera can be adjusted.

Figure 4.10: Professional wire rope stabilizer [77]

For this reason, wire rope stabilizers give lots of freedom of adjustment. It is also preferred
compared to camera gimbals, which require electricity. Steel cables are used to build the wire
rope isolator. Festo supplied steel cable with a thickness of 2mm. The optimal configuration
was found using experimenting and trial-and-error. The following observations were made:
• Using multiple cables (or thicker cables) increases stability, but also increases vibration;
• Short cables are stiffer and increase z-axis (vertical) vibration;
• Longer cables reduce vibration the best.
The final design of the wire rope stabilizer can be found in appendix C, figure,C.1d and C.1e.
The best configuration found was to use ten steel cables with a length of approximately 20
centimeters. The exact length can be adjusted to fix the rotation of the camera.

53
Prototype The final prototype is built and put in place using silicone gel vibration ab-
sorbing pads. All bolts and nuts are secured in place using split washers. Also, a ball head is
added to adjust the angle more precisely and to place the camera a bit higher. The prototype
of the mounting apparatus is shown in figure 4.11.

(a) Hardware configuration (without camera ball (b) Hardware mounted on Robotino with silicone
head) gel pads camera ball head

Figure 4.11: Hardware mount prototype

The prototype is tested for vibrations using the same method described in the previous
experiment. The results of the mounted hardware are compared to the “vibration at middle
of pole” (figure 4.9b) and “vibration distribution at middle of pole” (figure 4.9e). The results
of the stabilizer compared to these graphs are shown in figure 4.12. It is directly clear that
the stabilizer is effective. It significantly reduces vibrations on all axis. The maximum forces
of the vibrations are reduced to approximately 50%.

54
(a) Vibration at middle of pole height without (b) Vibration at middle of pole height with sta-
stabilizer bilizer

(c) Vibration distribution at middle of pole (d) Vibration distribution at middle of pole
height without stabilizer height with stabilizer

Figure 4.12: Vibration analysis of Robotino at different places

Emergency stop The Robotino needs to navigate people. Therefore, adequate safety
features must be present. The main safety function is that the Robotino can be stopped
easily by an emergency stop (e-stop). Festo provided an emergency stop for this project
that must be used. It consists of two Telemecanique ZBE-102 switches that are normally
closed. When pressed, the switches will open, and any present current will stop flowing. The
switches are IEC/EN 60947-5-1 and EN/IEC 60947-1 certified, meaning they are suitable for
emergency switches. The two switches are coupled to the actual button that someone would
press in case of an emergency. The button itself is brandless; no article number is available.
The emergency stop must be mounted at an easily accessible and visible place. The
best place for this is at the Robotino’s platform. The platform is the highest point of the

55
Robotino. It is not necessary for someone to bend over to stop the Robotino from driving.
The emergency stop can either be mounted on top of the Robotino or mounted inside the
platform’s pole. The provided emergency stop button fits perfectly inside the pole, making
it an elegant and robust place to mount the e-stop. A prototype of the mount for the e-stop
will be made using a 3D printer with PETG filament. PETG is the filament that is provided
and available at Festo. The benefit of this filament is that it is strong and flexible. This
makes it suitable for the e-stop since it should withstand a punch without breaking. For
this PoC, there will not be any filament comparisons. PETG is provided by Festo, and
comparisons of filament types are not in the scope of this project.

Figure 4.13: Emergency stop prototype

4.5 Hardware and algorithmics for localization

The first research sub-question states: Which combination of hardware and algorithmics is
suitable to be used with Robot Operating System to localize the Robotino within the Festo
office during autonomous navigation?

The PEAS analysis was used to give insight into the performance requirements, envi-
ronment observation, the currently available actuators, and sensors. Using this analysis, it
became clear that the Robotino needs additional hardware to fulfill the localization task.
In conclusion, combining the RTAB-MAP SLAM implementation with a depth camera is
suitable for localization or the Robotino. The RTAB-MAP algorithm will use the data from
the ZED 2 depth camera as an input. The ZED 2 camera is connected to a stabilizer to
reduce motion blur. This increases the accuracy of the mapping and localization algorithm.
The ZED 2 will be connected to an Nvidia Jetson Xavier NX powered by a Mean Well RSD-
30L-12 converter. Additionally, the algorithm might be extended using mmWave radar, if
necessary. The safety of the Robotino during navigation is increased by adding an emer-
gency stop. The emergency stop disconnects the flow of electricity, which guarantees that
the Robotino will stop when the button is pressed.

56
Chapter 5

Obstacle detection

The following sections will answer the second sub-question: Which combination of hardware
and algorithmics is suitable to be used with Robot Operating System to detect obstacles during
autonomous navigation?

5.1 The ROS Navigation Stack

The major component for ROS navigation is called the navigation stack [13, 79, 80]. In
essence, the navigation stack takes in sensor input and odometry and outputs the velocity
commands to reach a goal. In reality, this is more complex than it seems. The navigation
stack depends on localization algorithms, sensor input, obstacle detection, path planning
algorithms, motor controls, and more. Detecting obstacles is one part of the implementation
of the navigation stack. The basic structure of the navigation stack is given in figure 5.1.
An introduction to the navigation stack is necessary to understand how obstacle detection
and pathfinding will be integrated.

Figure 5.1: Default ROS navigation stack setup [81]

As can be seen in figure 5.1, the ROS navigation stack relies on a ROS package called
move base [82]. This package takes several messages as inputs and sends velocity commands
to cmd vel as outputs. The diagram shows that move base consists of several other parts:

57
 • A global and local planner;
• A global and local costmap;
• Recovery behaviors.

These items are discussed in the next paragraphs.

5.2 Obstacle detection

Mapping obstacles One of the requirements is that the Robotino should not drive un-
derneath objects with legs, like tables and chairs. At the same time, it must also drive
through a doorway without detecting the upper roof as an obstacle. To detect these obsta-
cles properly, RTAB-MAP makes use of two techniques [64]. The first technique is to set
a maximum obstacle height. The maximum obstacle height determines the height limit at
which obstacles are mapped. Any obstacle above this height is not considered an obstacle.
This is necessary; otherwise, the ceiling or doorways would be considered to be an obstacle.
This maximum obstacle height can be set to, for example, 2 meters. This means that the
Robotino can drive at any place where a 2-meter tall person could walk. This parameter
can be changed based on the currently available static obstacles in the Festo environment.
To detect obstacles with legs, a technique called 3D projection is used [64]. This method
takes a 3D object and then uses trigonometric mathematics to project it onto a 2D plane.
Combining this technique with the maximum obstacle height makes sure that tables and
chairs are detected as obstacles entirely. An illustration of this 3D projection on a 2D plane
is provided in figure 5.2.

58
 Figure 5.2: Generating 2D occupancy grid by projecting 3D obstacles on a 2D plane

Costmaps The move base package contains two costmaps: a local and a global costmap.
A costmap tells which places the robot can use to drive and which places the robot should
avoid [13, 80, 83]. The costmaps are build based on the physical dimensions of the robot. The
length and width of the robot are used to determine which places can be used for navigation,
and which ones to avoid. This should not be confused with the occupancy grid, which is
created by RTAB-MAP. An occupancy grid shows in which places it detected an obstacle.
It does not tell where the robot can actually drive. Where the robot should and shouldn’t
drive is calculated by a cost function. It defines which places are free, which places might
be occupied and which places are most definitely occupied. Costmaps are managed by the
costmap 2d package.
The move base package works with a local and global costmap. The global costmap
shows all the static obstacles and is based on the output of a map server. As described by
Labbé [64], RTAB-MAP makes use of a service called OctoMap to distribute its occupancy
grids within ROS [84]. This map can be fed into move base to generate the global costmap.
This can be seen in figure 5.1. Global costmaps are predefined and generally do not change
after initialization. In summary: the occupancy grid of RTAB-MAP shows where static
obstacles are and is created and served by OctoMap. The global costmap is created based
on this map and determines where the robot can drive based on its physical dimensions.
As described in figure 5.1, there also exists a local costmap. The local costmap is used
to show all dynamic obstacles. These are obstacles that are suddenly present in front of
the robot. Dynamic obstacles are generally smaller in size and can move around. At Festo,
dynamic obstacles are, for example, people, tools, or chairs. The local costmap is updated

59
with a configured frequency. The local costmap uses direct sensor input, compared to the
global costmap, which uses map server data.

Layers Each costmap consists of several layers [83]. Each layer can be used to configure the
behavior of the costmap. The first layer is the Static Map Layer. According to the manual,
the static map layer represents the occupancy grid generated by the SLAM algorithm, which
is generated by RTAB-MAP and OctoMap for this project. The most important values to
configure for this layer are:

• Which map server topic to subscribe to;

• At which cost value an object is actually mapped as an obstacle;

The next layer is the Obstacle Layer. This layer tracks dynamic obstacles in either 2D or
3D. The obstacle layer accepts point clouds, which is the message type output of the ZED 2
stereo camera. Also, the IR distance sensors can be used to detect nearby obstacles in 360
degrees around the Robotino. This is possible if the IR sensors are made available in point
cloud or laser scan message types. The most important values to configure are the following:

• The topics of the sensors to subscribe to;

• Expected sensor data publish frequency;
• Sensor data types;
• Minimum and maximum obstacle height;
• Obstacle distance from the sensor;
• Sensor range;
• If the local costmap can update the global costmap;
• Filtering of point cloud data.

The Inflation Layer determines the “rate of occupancy” of a cell on the map. This is
determined by the inflation radius and the cost scaling factor. The inflation radius is the
radius from the robot in which to apply the move base cost scaling formula. The cost scaling
factor determines how strictly it will detect something as an obstacle or as free space. This
value is inverse. For example, a high-cost scaling factor results in less strictness. This means
that higher cost scaling could result in the Robotino bumping into objects.
The Range Sensor Layer is used to configure additional range sensors. It is similar to
the Obstacle Layer, except its message type is different. The range sensor layer is primarily
used for IR sensors or ultrasonic sensors. This could potentially be used with the Robotino’s
built-in infrared distance sensors. This would allow the robot to detect obstacles in all 360
degrees.
The last layer is the Social Layer. It detects whether there are people present. It can be
used to change behavior based on social interaction with people. This layer will not be used
for this project.

60
Costmap hardware Access to sensor data is only done with the local costmap. As
described in the previous paragraph, the local costmap makes use of the obstacle layer.
The ZED 2 publishes a point cloud, which is one of the message types that can be used for
obstacle detection.
The ZED 2, however, only has a field of view of 110 degrees horizontal and 70 degrees
vertical. This means that there is no obstacle detection behind the Robotino. Based on the
PEAS analysis, it is known that the Robotino also contains nine infrared distance sensors
placed around its base. By integrating them, the Robotino can detect nearby obstacles in
all directions where the ZED 2 might not detect these obstacles. The PEAS analysis also
discusses the necessity for detecting shiny surfaces. The IR sensors work well with shiny
surfaces, where the ZED 2 might lack in-depth detection performance.
According to the wiki [83], there are three data types that are allowed to be used with
the obstacle costmap: PointCloud, PointCloud2 and LaserScan. When using the Robotino
IR sensors for obstacle detection, the information must be published as one of these message
types.
After an obstacle is detected, it is put on location in the local costmap. However, this
obstacle might disappear. For example, a person might appear in front of the Robotino and
then walk away. To detect if an obstacle is still present at its current position, an additional
costmap layer called Spatio-Temporal Voxel Layer is used [85]. This package checks if an
object is still present after a certain period of time. If this is not the case, it will remove
the obstacle from the costmap. This technique will be used for both the IR sensors and the
ZED 2.

Custom Robotino node To integrate the IR sensors in the local costmap, a custom
node will be written. It will be written in C++, since this language has the best support for
generating point cloud data. This node gathers the infrared sensor data from the Robotino
daemon via its web-based API. Utilizing this existing API is determined to be within the
scope of this project. The node receives data in a range between 0 and 30 centimeters. If
no obstacle is present, the Robotino daemon still returns 30 centimeters. As a result, the
costmap thinks that obstacles are at least always present at 30 centimeters away. To solve
this problem, the incoming data will first be parsed and modified. If the obstacle is equal
to 30 centimeter, its value will be made invalid (std::numeric limits<float>::quiet NaN()).
The Spatio-Temporal Voxel Layer will treat the invalid values as empty space. In this way,
obstacles will be removed from the local costmap when there aren’t any obstacles present
anymore. The custom package is described in figure 5.3.

61
 Figure 5.3: Flow chart for custom IR sensor PointCloud2 publisher.

The node itself is fairly simple and consists of only two classes: Robotino and RobotinoN-
ode. The RobotinoNode class manages the subscriptions and publishing functionality of the
node. The Robotino class manages the HTTP GET and POST requests. Besides receiving
IR data, this class is also used to send navigation commands to the drives of the Robotino.
This works by sending a horizontal vector with velocities in [x, y, θ] directions. This process
is shown in the flow chart in figure 5.4a In this way, one class handles the incoming and
outgoing data with the Robotino daemon. The structure of the class is given via a Class
Diagram in figure 5.4b.

(a) Flow chart for controlling the

Robotino drives (b) Class diagram of the Robotino node.

Figure 5.4: Robotino node architecture

Filtering The ZED 2 registers depth in an FoV of 110 degrees horizontal by 70 degrees
vertical. This means that the floor is also visible in the FoV. As a result, the floor is also
registered as depth. The local costmap interprets every detected depth point within a certain
region as an obstacle, making the floor an obstacle as well. To mitigate this issue, the point
cloud must be edited using the so-called VoxelGrid Filtering [86]. The filter can be used
to limit the maximum distances in the X, Y, and Z planes. The Z plane (height) will be
cut off to prevent the floor from being seen as an obstacle. The X plane (distance from
the camera to obstacle) is also cut off since the local costmap will only need data for a few
meters (instead of the maximum 40 meters of the ZED camera).

62
5.3 The hardware and algorithmics for obstacle detec-
tion
The second sub-question was: Which combination of hardware and algorithmics is suitable
to be used with Robot Operating System to detect obstacles during autonomous navigation?
In conclusion, detecting obstacles uses the global and local costmap that are part of
the ROS navigation stack. These costmaps determine where obstacles are and where free
navigation space for the Robotino is present. The global costmap determines where static
obstacles are, while the local costmap determines where local dynamic obstacles are. The
ZED 2 stereo camera (used for SLAM) can be used for the local costmap. This will be
extended by integrating the Robotino IR distance sensors to get 360-degree local obstacle
information. VoxelGrid filters are applied to ensure that the floor is not detected as an
obstacle. The result can be seen in figure 5.5

Figure 5.5: 1 = local costmap, 2 = depth camera reading, 3 = RTAB-MAP occupancy grid,
4 = global costmap, 5 = actual obstacle.

63
Chapter 6

Pathfinding

The following sections will answer the third sub-question: Which pathfinding algorithms are
suitable to determine the path of the Robotino, taking obstacle detection into consideration?

6.1 Planners
Planners are the pathfinding algorithms that determine the path of the robot [82]. They are
part of the move base package. The move base package supports any planner that is based
on the so-called nav core. The nav core is a set of coding contracts (C++ interfaces) that
must be implemented. For this reason, there are three options available:

• Use the default pathfinding algorithms;

• Use another open-source nav core-based alternative;
• Develop a nav core-based pathfinding algorithm from scratch.

Eventually, there are two algorithms required; one for finding a path in the local costmap,
and one for finding a path in the global costmap. The local costmap planner changes its
path based on the obstacles that are currently present. If a random object appears, the
local planner will try to avoid this obstacle. The global costmap planner tries to find a path
within the entire map. This is often done only once per given navigation goal.

Planner requirements The requirements for the planners are based on the requirements
specification document, which are:

• The pathfinding algorithm must find the shortest path from its location to its final
destination;
• The robot shall calculate its path within 10 seconds;
• The pathfinding algorithm must determine a path that takes the dimensions of the
Robotino into consideration.

Finding the shortest path between two points means that a non-heuristic pathfinding algo-
rithm must be implemented. A heuristics pathfinding algorithm is a approximation of the

64
shortest path, but does not guarantee the actual shortest path. For example, a heuristics
pathfinding algorithm might simply return the first path that it finds, which is not neces-
sarily the shortest path. A non-heuristic pathfinding algorithm gives mathematically-proven
the shortest path. Also, it is necessary that the planner adheres to the PEAS analysis. More
specifically, it should have support for holonomic and omnidirectional robotics.

Default algorithms The default global planning algorithm that is used with move base
is navfn [82, 87]. It is designed specifically with circular robots in mind, making it a good fit
for the Robotino. The algorithm is based on Dijkstra’s pathfinding algorithm, which tries
to find the shortest path between two points [26]. As mentioned by a forum discussion [88],
Dijkstra is a good choice for global pathfinding for the following reasons:
• Compared to heuristics, it does not settle for the first possible path. It will always find
the shortest path;
• Even though finding the shortest path is computationally expensive, it only has to be
done (approximately) once to find a path to a goal.
The default local planning algorithm that is used with move base is
base local planner [82, 89]. The algorithm is described to work as follows:
• Generate a sample of a velocity in directions x, y, and θ;
• For each sample, simulate what would happen if the robot were to navigate that sample
in real life;
• Generate a score for all samples. Discard illegal samples (like ones that collide with
objects);
• Execute the velocity commands that contain the highest score based on the simulation.
The algorithm works with any shape of a robot, as long as its shape is defined within the
costmap parameters.

Alternative open-source algorithm There is not a lot of information available about

alternative global planners. There are no research papers found with comparisons available.
The only two sources found are the Robotics Knowledgebase and search results on the ROS
Wiki. According to the Robotic Knowledgebase and the nav core Wiki page [90, 91], there
are three major global planners: carrot planner, navfn (already discussed) and global planner.
A search on the wiki also showed the sbpl lattice planner [92, 93]. Carrot planner is known
to be a straightforward planner. It tries to move to a goal in a straight line. There is no
actual pathfinding algorithm implemented. For this reason, the carrot planner works well
in outdoor areas or inside one room only. It relies on the local planner to make obstacle
avoidance algorithms. For this reason, carrot planner is not advanced enough to be used as
a global planner. Next, Sbpl lattice planner works by generating short sequences of possible
paths and sticking them together until a good-enough path is found [93]. In this way, it is not
computationally expensive, but also does not guarantee to find an optimal path. It is easy
to integrate constraints for the robot which can be used to find a good path and makes it
works especially well with robotics that are non-circular (e.g. of self-driving cars). Therefore,

65
the sbpl lattice planner can also be used for non-navigation goals, like generating paths for
the movement of robotic arms. It is worth noting that the package is experimental and not
officially listed on the nav core page. The last global planner is the global planner package
[94]. This package is an extension of the navfn package and allows for more functionality.
According to the Robotino Wiki nav core page [91], there are five local planners available.
They are base local planner (already discussed), dwa local planner, eband local planner,
teb local planner and mpc local planner.
The dwa local planner functions exactly the same as the base local planner [95]. Ac-
cording to the ROS wiki, the only difference is in its parameter tuning. Dwa local planner
allows for parameters to be dynamically re-configurable, and more parameters are available
to be tuned. Especially, dwa local planner has more flexible y-axis tuning, which is use-
ful for holonomic robots (like the Robotino). Lastly, the wiki states that dwa local planner
is mainly a rewrite of base local planner to make it easier to understand and implement.
Eband local planner works with the principle of elastic bands. A visual representation would
be to imagine elastic/rubber bands attached to the Robotino that pull it forward to its
goal, and sideward when obstacles appear [96]. This visual representation is shown in figure
6.1. The elastic band approach usually generates smooth navigation commands compared
to other planners. eband local planner works with holonomic robots exclusively, making it a
good fit for the Robotino. teb local planner is a minor extension of eband local planner and
contains performance optimizations compared to eband local planner [96]. One advantage
is that it generally performs better than eband local planner when random obstacles appear
in the local costmap. It is fairly new compared to eband local planner. The last local plan-
ner is mpc local planner. According to Rösmann et al., this planner is specifically targeted
at complex kinematic and dynamic models that require high computing performance [97].
Rösmann states that there is no real benefit to use this planner compared to the other plan-
ners, except for planners that requires very complex path planning. Examples are the path
planning for e.g. robotic arms. For this reason, mpc local planner is out of the scope for this
project.

Figure 6.1: Planner comparison, non-elastic band versus elastic band

66
Self-built algorithm The final option is to build a planning algorithm by hand. Most
importantly, the self-built planning algorithm implements the nav core::BaseGlobalPlanner
C++ interface for global planners and nav core::BaseLocalPlanner for local planners. Any
pathfinding algorithm can be implemented as long as these interfaces are used.

Recovery behavior The last part of pathfinding algorithms is the recovery behavior se-
quence [82]. The move base package allows a sequence of recovery behaviors to be executed
when the robot senses that it’s stuck. After each type of recovery behavior, the robot tries to
make a new navigation plan. If all recovery behaviors are executed, and all of them fail, the
robot thinks its stuck and it will stop its operations. Just like the global and local planners,
the recovery behavior must adhere to the nav core::RecoveryBehavior C++ plugin.
According to the ROS Wiki [82], there are two recovery behavior packages available. The
default recovery list is as follows:

1. conservative reset (package: clear costmap recovery);

2. rotate recovery (package: rotate recovery);
3. aggressive reset (package: clear costmap recovery);
4. rotate recovery (package: rotate recovery);
5. give up.

The clear costmap recovery package works by referencing the global costmap when the
robot seems to be stuck. Based on the global map, the package tries to traverse in different
directions to clear out space to find a new path. The rotate recovery package simply turns
the robot around to see where navigating space is available. This normally happens after
the conservative reset has been executed. If the robot still perceives itself as stuck, the
clear costmap recovery is executed again, but it is given a bigger radius to clear out and
explore. This radius can be defined via ROS parameters. It is worth noting that there are
no other recovery behaviors recommended or mentioned for the navigation stack at the time
of writing. There are also no sources found that indicate any possible improvements in the
default setup.

Decisions For the global and local planners, the decision is to use an existing open-source
algorithm. Several of the algorithms are highly optimized and specially designed for holo-
nomic robotics, like the Robotino. For this reason, it is hard to argue to build planning
algorithms from scratch with the assumption that they will outperform the existing algo-
rithms. This is also not realistic given the timeframe of this thesis project. Lastly, it is
preferred that the algorithms do not make use of a heuristics function. That is, the path
should not be approximated, but the shortest path should be calculated. On a local level, it
is desired that obstacle avoidance is done efficiently and smoothly. This combination makes
for a pleasing and natural guidance experience without having the Robotino making sharp
and shocking turns.
For the global planner, the global planner package will be used. This package allows for
a non-heuristic global pathfinding algorithm to be used. The package also provides plenty of
parameters that can be tuned to optimize the navigation experience. For the local planner,

67
the teb local planner will be implemented. This package uses the elastic band approach,
making sure that obstacles are avoided smoothly. It has several performance optimizations
compared to eband local planner. It also works excellent with holonomic robotics. For the
recovery behavior, the default sequence will be used. No better options have been found
online and in literature, and the current sequence seems to be sufficient for this case study.

6.2 Pathfinding with obstacle detection

The third sub-question states: Which pathfinding algorithms are suitable to determine the
path of the Robotino, taking obstacle detection into consideration?
In conclusion, there are many options available to implement the pathfinding algorithm.
It is clear that three algorithms are required: a global planner, a local planner, and a
sequence of recovery behaviors. The path through the global costmap will be determined
by global planner. The local costmap shows all dynamic obstacles. The path in the local
costmap is determined by teb local planner. This is shown in figure 6.2. The package’s
algorithm uses the elastic band approach to determine the smoothest path around local
obstacles. When the Robotino is stuck, the recovery sequence will try to clear a path and
find a new way to reach its goal. This sequence moves the Robotino to previously explored
places and rotates it to find new ways to reach its goal.

Figure 6.2: Local and global planner implemented and visualized.

68
Chapter 7

Software architecture

The following sections will answer the fourth sub-question: In which way can obstacle avoid-
ance be implemented in combination with the chosen pathfinding and localization algorithms?
This question relates to the architecture of all components. Right now, all decisions for all
packages are made. However, they all need to be tied together to function properly.

7.1 Architecture design

Implementing the navigation stack is the same as the implementation of obstacle avoidance
with pathfinding and localization. In essence, this means that figure 5.1 needs to be changed
to contain all chosen algorithm packages. Based on figure 5.1, the navigation stack requires
the following inputs:

• TF transformations
• Odometry source
• A map server
• Sensor sources

Its outputs are velocity commands. The actual high-level architecture (based on figure 5.1)
is shown in figure 7.1. It is high-level since it only shows all elementary packages and
configurations. This is the configuration of the move base package for this project. It takes
several data sources as an input. The inputs result in the actual velocity commands from
the teb local planner. These navigation commands are sent back to the robotino node, which
handles the motor movement. More detailed architecture configurations are discussed in
further paragraphs.

Distributed computing Firstly, the entire navigation stack was implemented on the
Nvidia Jetson. This includes all packages, like the planners, costmaps, RTAB-MAP, ZED
wrapper, and the self-made Robotino node. At this point, it was immediately clear that
this was too much computational load. The system became unresponsive and was prone to
crash. For this reason, it was essential to divide computational loads between computers.

69
 Figure 7.1: High-level architecture of obstacle avoidance, pathfinding and localization.

The product contains two computers; the embedded PC in the Robotino and the Nvidia
Jetson. ROS makes it possible to distribute computational loads across the local network
to all ROS-enabled devices. If several ROS devices are connected to the local network, they
will automatically broadcast their data to all available devices.
The Nvidia Jetson will be used for running the zed ros wrapper because of its Nvidia
CUDA-capable graphics card. According to the hardware requirements of the ZED SDK,
the Jetson is sufficient for this task. However, the processor does not leave much room for
other tasks. Based on the htop Linux system monitoring tool, the zed ros wrapper takes
approximately 85% of all available computing resources, with spikes in the upper 90’s. For
this reason, it is necessary to offload other tasks to the Robotino.
The Robotino will be used to perform localization with RTAB-MAP. According to Labbé
[64], RTAB-MAP can already run with only a single processor core. All packages related to
the move base can be configured to perform with the available system resources. Parameter
files can be used to set, for example, the resolution of the costmap, the maximum path length
calculation of the teb local planner, and more. The Jetson will be used for all preprocessing
tasks related to graphical computations. This includes the zed ros wrapper, as well as depth
filtering packages.

Network configuration A good network configuration makes it possible to send and

receive ROS data on the local network between machines. Several steps are required to
make this work. Firstly, each device must be configured with a static Internet Protocol (IP)
address. Next, one must define which device is the ROS master (covered in chapter 2). The
choice is to use the Robotino as the master. The Robotino will also run the robotino node,
which controls motor movement. For this reason, it is not preferred to let the movement
commands depend on a network connection. Rather, the movement commands are executed
on the same computer that runs the ROS master. If some network failure occurs, or if
the Jetson crashes (for whatever reason), it will not directly affect the safety of the robot’s
movement operations.

70
 Both the Robotino and Jetson are connected to the Festo wireless enterprise network.
The devices receive their IP address via Dynamic Host Configuration Protocol (DHCP).
Because of the dynamic IP addresses, it is difficult to use the wireless network for sharing
data. Wireless networks also introduce more latency compared to wired networks. The
Robotino and Jetson are also equipped with gigabit ethernet. Ethernet is generally more
stable and has less latency. Using the ethernet port also makes it easier to set static IPs in
the ROS configuration. Hence, the Robotino and Jetson will be connected via ethernet with
static IPs. An overview of the network connection is visible in figure 7.2.

Figure 7.2: Network configuration

Launch files ROS can create all connections between nodes by creating launch files [13].
Launch files can start multiple nodes at once and set parameters and routing of topic data.
Two launch files are created to create the distributed computing architecture: one for the
Robotino and one for the Jetson. The Robotino launch file starts all parts of the navigation
stack. This launch file contains an additional parameter that defines if the robot will be
localizing itself or if it is creating a map. The Jetson launch file starts all graphical-related
nodes, like the ZED ROS wrapper and the voxel filters. Normally, launch files are started with
a command similar to the following: roslaunch [node name] [launchfile name] [parameters].
This can be lengthy to type and easy to forget. For this reason, the launch files are executed
by simple shell scripts. They are the following:

71
 Script name Device Command
startmapping.sh Robotino roslaunch robotino mapper mapper.launch mapping:=true
startlocalizing.sh Robotino roslaunch robotino mapper mapper.launch mapping:=false
startpreprocessing.sh Jetson roslaunch robotino preprocessor preprocessor.launch

Resulting architecture Connecting all packages results in a complicated architecture.

Most importantly is how data flows from package to package, between the Robotino and
the Jetson. The resulting architecture is given in the data flow diagram. Because of its
complexity and size, it is provided in appendix D, figure D.1. Each launch file starts with
several nodes that depend on each other. These dependencies can be expressed in a se-
quence diagram. This diagram shows the lifetime of the nodes and how they exchange data
throughout time. The sequence diagram is provided in appendix E, figure E.1.

7.2 Implementation of obstacle avoidance with pathfind-

ing and localization
The fourth sub-question was: In which way can obstacle avoidance be implemented in com-
bination with the chosen pathfinding and localization algorithms?
The implementation of obstacle avoidance with pathfinding and localization is the con-
figuration of the navigation stack. This requires several ROS packages to be connected and
share information. To achieve better performance, the computational loads are distributed
between the Robotino and the Nvidia Jetson. The resulting architecture is visible in ap-
pendix D, figure D.1. The architecture is started by executing the appropriate scripts for
mapping, localizing, and preprocessing. This sequence is expressed in appendix E, figure
E.1.

72
Chapter 8

Controlling the Robotino

The following sections will answer the fourth sub-question: In which way can the destination
of the Robotino be indicated?

8.1 Setting navigation goals

The navigation stack is responsible for generating the appropriate velocity commands to
reach a navigation goal. To set a navigation goal, the nav stack package subscribes to a
topic called move base simple/goal.

Interface functionality According to the requirements specification document, the Robotino

must be controlled via a web-based interface. The reason for a web-based approach is that
it works on all devices and is easy to integrate. It allows for lots of flexibility and extension
of its functionality. Web interfaces can be used on many devices, like smartphones, tablets,
and laptops. Another rationale behind a web interface is that it does not require a ROS
installation to work. It is not necessary to install the entire ROS suite on the receptionists’
devices.
For the proof of concept of this case study, there are not many requirements given.
Primarily, the interface must simply connect to the Robotino and set a navigation goal.
Also, the interface must be web-based and should be easy to use and understand. No further
requirements were given for the interface. The convenience of a web-based system allows
easy modification and extension in the future as per Festo’s wishes. For this project, the
web interface consists of the following basic functionality:

• Insert the Robotino IP address;

• A connect button with a connection status;
• Options to fill in the locations of the Robotino;
• Buttons that start the navigation of the Robotino;
• The robot’s current location

73
Interface design The only design requirement is that it must be simple to use and easy
to understand. Therefore, as little functionality as possible is embedded into the design. It
contains only a few user interface elements and only one single page. The design contains four
location options by default. A wireframe diagram design of the interface is given in appendix
F, figure F.1. The design will make use of the open-source Bootstrap HTML library for its
modern aesthetics [98]. For dynamic changes in the user interface, the open-source jQuery
library will be used [99]. This can be used to, for example, add the extra navigation buttons
to the user interface dynamically.

Communication The web interface and the hardware are two individual systems that
are connected to the network. Somehow, these two systems need to communicate with each
other to share information. ROS contains a collection of open source tools for developing
web-based interfaces, called the Ros Web Tools (RWT) collection [100, 101]. The tools that
will be used for the interface need to meet the following criteria:

• It must be able to read TF transformation topics to show the robot’s location relative
to the map;
• It must be able to send messages of the type geometry msgs/PoseStamped for a navi-
gation goal on the map;

One of the key packages of the RWT is the Rosbridge. Via this package, ROS can
communicate with external non-ROS applications [102, 103]. Rosbridge exposes several
aspects of the ROS system to any non-ROS program. It supports JSON to send robot data
to external applications, as well as receive JSON that ROS can use. To send and receive this
JSON data, it creates a WebSocket. A WebSocket creates a persisting connection between
the robot and the interface. This makes it possible to send and receive data with low latency
and little overhead [104].
Rosbridge only creates the WebSocket connection. Another package is responsible for
the actual data communication between the web interface and the robot. This package is
called roslibjs. Roslibjs makes it possible to subscribe and publish to ROS topics via the
WebSocket [100, 102]. By giving it the connection details of the Rosbridge (IP address and
port number) of the WebSocket, it can create a direct connection. The JavaScript library
can easily be integrated into any HTML website.
As previously described, the requirements are that it can read TF transformation topics,
as well as geometry msgs/PoseStamped messages. This is possible with both the Rosbridge
and roslibjs. Both packages support all standard message types, as well as TF topics.

8.2 Operating the interface

Several steps are required to use the interface. First, the IP address of the Robotino must
be acquired. This can be done using nmap, a network scanning tool [105]. This tool can
be used to scan devices that have an open connection to port 4000. Port 4000 is used for
NoMachine to develop and monitor the Robotino. Therefore, scanning for devices with port
4000 will find the IP address of the Robotino. The IP address must be filled in the correct

74
field of the web interface. The connect button will create the connection to the WebSocket
on the Robotino.
After the connection is made, the custom Javascript code automatically subscribes to the
TF topic that broadcasts the location of the Robotino. To determine the navigation goals
of the Robotino, it can be moved to a certain goal. When the Robotino is at that goal, its
locations can be written down in the empty location fields. If the goals are semi-permanent,
the goals can simply be inserted in the HTML file as a default value. Next, the only step is
to hit the drive button, and all further operations start automatically.

Improvements It might be useful to host the website on a dedicated local server in the
Festo building to improve the interface. This could be useful to store the location data in a
database. It also makes other functionality possible, like logging features or user authenti-
cation.

8.3 Indicating the destination

The fifth sub-question was: In which way can the destination of the Robotino be indicated?
The location indication is done via a web interface. This allows a flexible, dynamic website
that works on almost any device that can run a browser. The design is based on the wireframe
given in appendix F, figure F.1. A screenshot of the implemented result is provided in
appendix G, figure G.1. The RWT toolkit provides all necessary tools. Communication with
the robot is done via a WebSocket connection created by the Rosbridge. To communicate
with this WebSocket, the roslibjs package will be integrated into the HTML website.

75
Chapter 9

Implementation

9.1 Proof of concept performance

One of the first steps of this thesis was to execute the PEAS analysis. This analysis has
been used to analyze the performance, environment, sensors, and actuators of the agent.
This analysis greatly influenced the choices of this project (e.g., the answers to the research
questions). The analysis also introduced several performance aspects. This section reflects
on these aspects.
The first performance measure is that the Robotino and its additional hardware must
not loosen when the Robotino is navigating. This has been implemented successfully. The
hardware mounts are sturdy while navigating and do not loosen when driving around. This
has been achieved by implementing vibration absorption and securing bolts and nuts with
split washers, as discussed in the results section 4.4. The next performance measure is that
the Robotino must start navigating within ten seconds after a command is given. This is
achieved successfully by the global planner and the teb local planner package. Following up,
the Robotino has been made interoperable via the web interface. This is achieved using
the WebSocket connections that allow the outside world to connect with the Robotino.
The Robotino has also been proven to be reliable throughout time. When the Robotino is
started up, it stays reliable, and its localization and navigation performances do not decrease
throughout a working day. Its accuracy also stays similar. Another requirement was that
the hardware must be modifiable. Hardware can easily be exchanged, and no objects are
fixed in place permanently. New 3D designs for additional hardware can easily be printed
and added to the proof of concept. The last performance measure was that the agent must
be testable. This measure has also been fulfilled; its results are shown in the next sections.
In conclusion, the proof of concept fulfills all the important performance measures that
have been set at the beginning of this project. The concept has been proven to work at the
Festo office. Two images of the implementation are provided in figure 9.1.

76
 (a) Robotino in reception area (b) Robotino driving in hallway

Figure 9.1: Robotino results

9.2 Test results

The proof of concept has been built based on the answers to all sub-questions. This im-
plementation has been optimized and tweaked to achieve properly functioning localization,
obstacle detection, and pathfinding. The resulting proof of concept has been tested. The
results can be found in the separate test report. This section summarizes the test report.

Requirements specification Almost all requirements from the requirements specification

have been implemented in the proof of concept. Three requirements (with MoSCoW priority:
Could have) that have not been implemented are:

• Emergency stop stops the ROS software when pressed;

• Adjusting to a customer walking speed automatically;
• Slow speed when people are detected.

These requirements have not been implemented due to a lack of time.

All other requirements have been mostly implemented successfully. This means that the
Robotino navigates as expected in most circumstances. There are a few edge cases that make
the navigation behavior difficult. Firstly, the Robotino will bump into an obstacle slightly
in some exceptional cases. This happens when an obstacle is out of the field of view from
the ZED camera and not in the IR sensor range. This can possibly be solved by integrating
extra IR depth sensors or mmWave sensors around the perimeter of the Robotino to increase
its angular depth resolution. Another edge case is that the Robotino will not always detect
the transparent door at the reception when a lot of sunlight is present. The door, however,
opens automatically, so this is not an issue that needs attention. Lastly, the Robotino will

77
sometimes lose track of its location when the environment has been drastically changed. It
is necessary to map the environment while dynamic obstacles (like toolboxes and chairs) are
not present. Otherwise, the dynamic obstacles will be mapped in the static costmap and
mess with the localization accuracy if they move around afterward.

9.3 Scope
Determining the scope for this project was one of the first steps before starting the project.
All items of the scope have been fulfilled.
The first item was to analyze the initial Robotino hardware. The results of this are
visible in the separate hardware analysis document. Next, working on the software-based
connections between sensors and actuators with navigation algorithmics is represented by
the entire proof of concept. The following item of the scope is to allow usage of the Robotino
ROS API. This is used for the custom-made Robotino node that controls the IR sensors and
omnidirectional drives. This node is written in C++ using object-oriented programming to
keep code extensibility in mind. Determining and adding extra hardware is done by extensive
literature research and physically mounting the Nvidia Jetson, Stereolabs ZED 2, and the
power supply onto a stabilized structure. The next item was to keep code extensibility in
mind. The safety precautions are implemented by adding an emergency stop to the Robotino
that cuts off power to the omnidirectional drives when it’s pressed.

78
Chapter 10

Conclusions

10.1 Conclusion to main research question

The main question can be answered based on all sub-questions and the results of the test
cases. The main research question states: In which way can Robot Operating System be ap-
plied for controlling the Festo Robotino to autonomously navigate to predetermined locations
within the office building?
The Robotino is a Linux-based autonomous guided vehicle. ROS can be installed directly
onto this platform. Autonomous navigation involves several aspects. The environment is
dynamic, which means that the SLAM problem must be solved. Solving this problem results
in a map of the environment and the location of the Robotino on this map. For this algorithm,
additional sensors are required. The Robotino is extended with a Stereolabs ZED 2 depth
camera for determining depth in azimuth and elevation. The exact implementation of the
SLAM problem is done by using RTAB-MAP. This mapping algorithm determines its location
by tracking features in the environment while also building the map. To move autonomously,
the Robotino must detect obstacles. This is done by implementing local and global costmap.
The local costmap uses the depth camera and the nine IR bumper sensors surrounding the
Robotino to detect dynamic obstacles. The global planner package is used to find a long-
distance path, while the teb global planner is used to avoid dynamic obstacles smoothly.
Giving navigation goals is done via a web interface that connects with the Robotino via
roslibjs and Rosbridge. The result is a properly working, safe, and stable autonomous guided
vehicle that can guide customers from the reception area to the eXperience Center.

10.2 Conclusion on the problem statement

The goal of the proof of concept was to provide a solution to a problem. The problem was
related to the waiting time for visitors when they arrive at the Festo office. Visitors are not
allowed to walk through the building by themselves. This problem has been solved with this
proof of concept. The Robotino can guide people from the reception area to the eXperience
Center.
As discussed in the previous chapter, there are a few edge cases that prohibit smooth
navigation. Based on these cases, several recommendations should be implemented before

79
the proof of concept is actually implemented in a real environment with actual visitors.
These recommendations are provided in the next chapter.

10.3 Conclusion on motivation

As described in the motivation of section 1.2, the motivation behind the case study was to
gather more knowledge about ROS. This has been accomplished. Festo has gathered many
new aspects about ROS that were not known yet. Autonomous navigation of automated
guided vehicles was a completely new field. Festo now knows about the different types
of hardware that are necessary for autonomous navigation in dynamic environments. It
also knows which aspects to take into consideration when determining a SLAM algorithm
implementation. Also, new information is now available about the technical aspects of ROS.
For example, it was unknown that distributed computing is possible and fairly straight-
forward to implement. Festo now also knows more about the different elements needed to
implement the navigation stack.
Prior to this project, it was unknown if the ROS world could integrate with Festo hard-
ware. The findings of this thesis and the proof of concept indicate that this is most certainly
possible. Festo wants to innovate, keeping the fourth industrial revolution (Industry 4.0) in
mind. ROS allows flexible connectivity with all kinds of hardware, including Festo hardware.
If Festo is willing to invest in ROS, it has good potency to become useful within the company
for all sorts of robotics solutions.

80
Chapter 11

Discussion and recommendations

11.1 Comparison of ROS versus non-ROS

The integration of ROS with Festo also raises the question of how it compares to other
platforms. Extensive research on this question was out of the scope of this project. However,
the author of this thesis could come up with several conclusions.
ROS has many open-source packages available that can be installed within minutes,
without any costs. For each package, many developers can provide feedback or improve
these packages. There are many implementations available for all sorts of robotics problems.
If ROS was not used for this project, these implementations might have had to be built from
scratch. Also, software packages for specific problems might need to be bought as closed
source proprietary software.
It is also necessary to be critical of open-source software. Proprietary software has its
place in the robotics industry as well. It usually comes with guarantees and promises of its
stability and functionality. If there are any issues, a simple phone call can potentially solve
the problem. This is not the case with ROS, which strongly depends on its community to
keep it alive and provide support.
For each project, Festo should determine what the best choice is. Neither proprietary nor
open-source is a one-size-fits-all solution. Based on the requirements of a specific project,
Festo should determine if ROS is the right solution for that project. This can be done by
doing a proper requirements analysis. For example, for projects requiring utmost reliability,
one might wish to use proprietary hard- and software. ROS might be the best solution
available for highly flexible and interconnecting robotics or Industry 4.0.

11.2 Recommendations
To improve the performance of the Robotino, there are several recommendations.

ROS 1 vs. ROS 2 The theoretical framework contains information on why ROS 1 was
used for this project. The reasons are that ROS 1 is more mature and better suited for
developers that are new to ROS (which is the case for the author of this thesis). If Festo
wants to continue with ROS, the company should consider switching to ROS 2 soon. ROS

81
1 has an expected end of life in May 2025. Besides, ROS 2 has several advantages that can
benefit industrial environments (like security, control techniques, and distributed computing
options).

Automatic door opener When the Robotino navigates to the eXperience Center, it must
pass through a door. These doors are not automatically opened when someone approaches.
For the Robotino, this means that it simply stops navigating as soon as it reaches the door
since it cannot open it by itself. The recommendation is to add an automatic door opening
mechanism for uninterrupted navigation.

Computational limitations The computation limitations do not leave much room to

spare. The Nvidia Jetson Xavier NX could be upgraded to the more powerful Jetson AGX
Xavier. This makes it possible to perform RTAB-MAP in higher quality, which results in
better localization and mapping [64]. The downside would be that the AGX Xavier consumes
much more power. It might be possible to add more battery capacity so that the Robotino
will last longer.

Localization improvement On very few occasions, the Robotino loses track of its loca-
tion. This means that it will head towards a wall or simply drive where it should not drive.
This behavior is not desired. RTAB-MAP makes it possible to use AprilTags for localiza-
tion. Placing these tags around the office could result in better performance. This was not
implemented because of a lack of time. The advice is to find out which locations are difficult
for localization and add an AprilTag at these places.

Interface improvement The web interface can be improved by adding more features.
For example, roslibjs makes it possible to display the ZED 2 camera feed in the browser. In
this way, the receptionists can see exactly where the Robotino is at any given time. This
would make for a good improvement. The recommendation is to send a signal when the
Robotino thinks it’s lost or stuck at the door.

Hardware mount The hardware mount is mostly 3D printed and not very robust. To
make it more robust, the enclosure can be improved by using different materials and/or
constructions. This will improve the longevity of the mounting module for long-term usage.

Emergency stop Currently, the emergency stop only shuts down the power supply to the
motors after it’s been pressed. The software, however, continues to operate. The advice
is that the software also shuts down when the emergency stop is pressed. In this way, the
Robotino does not continue its operations after the button is released back in its normal
position.

82
Bibliography

[1] Festo figures, data, facts. [Online]. Available: https://www.festo.com/group/en/

cms/10250.htm.
[2] “The festo group,” Festo Company 2020, Jul. 2020. [Online]. Available: https://www.
festo.com/net/SupportPortal/Files/466579/Festo_Company_2020_EN.pdf.
[3] C. Klingenberg and J. Antunes, “Industry 4.0: What makes it a revolution,” EurOMA
2017, pp. 1–11, 2017.
[4] Cybernetics. [Online]. Available: https://www.britannica.com/science/cybernetics.
[5] S. Vaidya, P. Ambad, and S. Bhosle, “Industry 4.0–a glimpse,” Procedia manufactur-
ing, vol. 20, pp. 233–238, 2018.
[6] Z. Gao, T. Wanyama, I. Singh, A. Gadhrri, and R. Schmidt, “From industry 4.0
to robotics 4.0 - a conceptual framework for collaborative and intelligent robotic
systems,” Procedia Manufacturing, vol. 46, pp. 591–599, Jan. 2020. doi: 10.1016/j.
promfg.2020.03.085.
[7] M. Quigley, K. Conley, B. Gerkey, J. Faust, T. Foote, J. Leibs, R. Wheeler, and
A. Y. Ng, “Ros: An open-source robot operating system,” in ICRA workshop on open
source software, Kobe, Japan, vol. 3, 2009, p. 5.
[8] Ros-industrial. [Online]. Available: https://rosindustrial.org/.
[9] Robotino® mobile robot platform for research and training, 2021. [Online]. Avail-
able: https : / / www . festo - didactic . com / download . php ? name = Brochure % 20 -
%20Robotino%20EN.pdf&c_id=1100&file=brochure_robotino_en.pdf.
[10] System definition. [Online]. Available: https://www.merriam-webster.com/dictionary/
system.
[11] S. Russell and P. Norvig, Artificial Intelligence: A Modern Approach, 3rd. USA: Pren-
tice Hall Press, 2009, isbn: 0136042597.
[12] S. Franklin and A. Graesser, “Is it an agent, or just a program?: A taxonomy for au-
tonomous agents,” in Intelligent Agents III Agent Theories, Architectures, and Lan-
guages, J. P. Müller, M. J. Wooldridge, and N. R. Jennings, Eds., Berlin, Heidelberg:
Springer Berlin Heidelberg, 1997, pp. 21–35, isbn: 978-3-540-68057-4.
[13] M. Quigley, B. Gerkey, and W. D. Smart, Programming Robots with ROS: a practical
introduction to the Robot Operating System. ” O’Reilly Media, Inc.”, 2015, pp. 156–
160.

83
[14] Y. Lin, Sep. 2019. [Online]. Available: https://www.theconstructsim.com/infographic-
ros-1-vs-ros-2-one-better-2/.
[15] D. Thomas. [Online]. Available: http : / / design . ros2 . org / articles / changes .
html.
[16] V. Mazzari, May 2021. [Online]. Available: https://blog.generationrobots.com/
en/ros-vs-ros2/.
[17] T. Le-Anh and M. De Koster, “A review of design and control of automated guided
vehicle systems,” European Journal of Operational Research, vol. 171, no. 1, pp. 1–23,
2006.
[18] J. Fuentes-Pacheco, J. Ruiz-Ascencio, and J. M. Rendón-Mancha, “Visual simultane-
ous localization and mapping: A survey,” Artificial intelligence review, vol. 43, no. 1,
pp. 55–81, 2015.
[19] H. Durrant-Whyte and T. Bailey, “Simultaneous localization and mapping: Part i,”
IEEE Robotics Automation Magazine, vol. 13, no. 2, pp. 99–110, 2006. doi: 10.1109/
MRA.2006.1638022.
[20] S. Thrun and J. J. Leonard, “Simultaneous localization and mapping,” in Springer
Handbook of Robotics, B. Siciliano and O. Khatib, Eds. Berlin, Heidelberg: Springer
Berlin Heidelberg, 2008, pp. 871–889, isbn: 978-3-540-30301-5. doi: 10.1007/978-
3-540-30301-5_38. [Online]. Available: https://doi.org/10.1007/978-3-540-
30301-5_38.
[21] M. Filipenko and I. Afanasyev, “Comparison of various slam systems for mobile robot
in an indoor environment,” Sep. 2018. doi: 10.1109/IS.2018.8710464.
[22] Introduction to intel realsense visual slam and the t265 tracking camera. [Online].
Available: https://dev.intelrealsense.com/docs/intel-realsensetm-visual-
slam-and-the-t265-tracking-camera.
[23] P. Newman and K. Ho, “Slam-loop closing with visually salient features,” in proceed-
ings of the 2005 IEEE International Conference on Robotics and Automation, IEEE,
2005, pp. 635–642.
[24] C. Vassallo, W. Tabib, and K. Peterson, “Orbital slam,” in 2015 12th Conference on
Computer and Robot Vision, 2015, pp. 305–312. doi: 10.1109/CRV.2015.47.
[25] J. Solà, Simulataneous localization and mapping with the extended kalman filter, Oct.
2014. [Online]. Available: http :/ / www .iri . upc .edu / people /jsola / JoanSola/
objectes/curs_SLAM/SLAM2D/SLAM%5C%20course.pdf.
[26] K. Murphy and S. Russell, “Rao-blackwellised particle filtering for dynamic bayesian
networks,” in Sequential Monte Carlo Methods in Practice, A. Doucet, N. de Freitas,
and N. Gordon, Eds. New York, NY: Springer New York, 2001, pp. 499–515, isbn:
978-1-4757-3437-9. doi: 10 . 1007 / 978 - 1 - 4757 - 3437 - 9 _ 24. [Online]. Available:
https://doi.org/10.1007/978-1-4757-3437-9_24.
[27] M. Montemerlo, S. Thrun, D. Koller, and B. Wegbreit, “Fastslam: A factored solution
to the simultaneous localization and mapping problem,” Nov. 2002.

84
[28] F. Lu and E. Milios, “Globally consistent range scan alignment for environment map-
ping,” Autonomous robots, vol. 4, no. 4, pp. 333–349, 1997.
[29] M. Golfarelli, D. Maio, and S. Rizzi, “Elastic correction of dead-reckoning errors in
map building,” in Proceedings. 1998 IEEE/RSJ International Conference on Intel-
ligent Robots and Systems. Innovations in Theory, Practice and Applications (Cat.
No.98CH36190), vol. 2, 1998, 905–911 vol.2. doi: 10.1109/IROS.1998.727315.
[30] R. Koch and M. Kühn, “Detection of specular reflections in range measurements for
faultless robotic slam,” Dec. 2015, isbn: 978-3-319-27145-3. doi: 10.1007/978- 3-
319-27146-0_11.
[31] Robot platform: Knowledge: Holonomic vs. non-holonomic, 2021. [Online]. Available:
http : / / www . robotplatform . com / knowledge / Classification _ of _ Robots /
Holonomic_and_Non-Holonomic_drive.html.
[32] Mpu-6000 datasheet, 2019. [Online]. Available: https://product.tdk.com/info/
en/documents/catalog_datasheet/imu/MPU-6000-Datasheet1.pdf.
[33] [Online]. Available: https://aesensors.nl/assets/uploads/2016/05/Understanding-
Linearity.pdf.
[34] Incremental encoder. [Online]. Available: https : / / ip . festo - didactic . com /
InfoPortal/Robotino3/Hardware/DriveSystem/EN/IncrementalEncoder.html.
[35] R. B. Fisher and K. Konolige, “Range sensors,” in Springer Handbook of Robotics, B.
Siciliano and O. Khatib, Eds. Berlin, Heidelberg: Springer Berlin Heidelberg, 2008,
pp. 521–542, isbn: 978-3-540-30301-5. doi: 10 . 1007 / 978 - 3 - 540 - 30301 - 5 _ 23.
[Online]. Available: https://doi.org/10.1007/978-3-540-30301-5_23.
[36] D. Barrett and A. Alvarez, “Mmwave radar sensors in robotics applications,” Tech-
nical report, Texas Instruments, Tech. Rep., 2017.
[37] L. Ortiz, E. Cabrera, and L. Gonçalves, “Depth data error modeling of the zed 3d
vision sensor from stereolabs,” Electronic Letters on Computer Vision and Image
Analysis, vol. 17, Apr. 2018. doi: 10.5565/rev/elcvia.1084.
[38] W. Navaraj, Sensors - ros wiki, Mar. 2021. [Online]. Available: http://wiki.ros.
org/Sensors.
[39] 3d lidar 360º, 2021. [Online]. Available: https://www.roscomponents.com/en/47-
3d-lidar-360.
[40] M. Toa, How to choose the right proximity sensor for your design needs, Oct. 2019.
[Online]. Available: https://e2e.ti.com/blogs_/b/analogwire/posts/how-to-
choose-the-right-proximity-sensor-for-your-design-needs.
[41] C. Kumar, 60ghz mmwave sensor evms, 2020. [Online]. Available: https://www.ti.
com/lit/ug/swru546d/swru546d.pdf?ts=1622963016926.
[42] Panjekm, D435 projector fails to turn on using set option - issue 1512 - intelre-
alsense/librealsense, Apr. 2018. [Online]. Available: https://github.com/IntelRealSense/
librealsense/issues/1512.

85
[43] Ad-96tof1-ebz. [Online]. Available: https://www.analog.com/en/design-center/
evaluation - hardware - and - software / evaluation - boards - kits / ad - 96tof1 -
ebz.html.
[44] Cis co., ltd. [Online]. Available: https://www.ciscorp.co.jp/product/detail_
en.html?rec_id=164&amp;group_flag=70.
[45] Meerecompany. [Online]. Available: http://cube-eye.co.kr/en/.
[46] Duo mlx. [Online]. Available: https://duo3d.com/product/duo-minilx-lv1.
[47] 3d camera survey - ros-industrial. [Online]. Available: https://rosindustrial.org/
3d-camera-survey.
[48] Manuel, Pieye eshop: Nimbus 3d kamera: Online kaufen, Mar. 2020. [Online]. Avail-
able: https://shop.pieye.org/Kameras/Nimbus-3D-Kamera.html.
[49] Introducing the intel® realsense™ depth camera d455, May 2021. [Online]. Available:
https://www.intelrealsense.com/depth-camera-d455/.
[50] Astra series, Mar. 2021. [Online]. Available: https : / / orbbec3d . com / product -
astra-pro/.
[51] Built for the spatial ai era. [Online]. Available: https://www.stereolabs.com/zed-
2/.
[52] [Online]. Available: https : / / www . mynteye . com / products / mynt - eye - stereo -
camera.
[53] O3d303 - 3d camera. [Online]. Available: https://www.ifm.com/nl/nl/product/
O3D303.
[54] Zed sdk, Apr. 2021. [Online]. Available: https://www.stereolabs.com/developers/
release/.
[55] Recommended specifications for zed sdk. [Online]. Available: https://www.stereolabs.
com/docs/installation/specifications/.
[56] Can i use the zed without cuda? [Online]. Available: https://support.stereolabs.
com/hc/en-us/articles/207776845-Can-I-use-the-ZED-without-CUDA-.
[57] Cuda zone, May 2021. [Online]. Available: https://developer.nvidia.com/cuda-
zone.
[58] Robotino os, Nov. 2020. [Online]. Available: https : / / wiki . openrobotino . org /
index.php?title=Robotino_OS.
[59] [Online]. Available: https://www.meanwell.com/index.aspx.
[60] Getting started with ros and zed. [Online]. Available: https://www.stereolabs.com/
docs/ros/.
[61] Oct. 2020. [Online]. Available: https://www.stereolabs.com/blog/positional-
tracking-3d-reconstruction-and-more-with-zed-camera/.
[62] M. Filipenko and I. Afanasyev, “Comparison of various slam systems for mobile robot
in an indoor environment,” Sep. 2018. doi: 10.1109/IS.2018.8710464.

86
[63] C. Kolhatkar and K. Wagle, “Review of slam algorithms for indoor mobile robot with
lidar and rgb-d camera technology,” in Innovations in Electrical and Electronic Engi-
neering, M. N. Favorskaya, S. Mekhilef, R. K. Pandey, and N. Singh, Eds., Singapore:
Springer Singapore, 2021, pp. 397–409.
[64] M. Labbé and F. Michaud, “Rtab-map as an open-source lidar and visual simultane-
ous localization and mapping library for large-scale and long-term online operation,”
Journal of Field Robotics, vol. 36, no. 2, pp. 416–446, 2019.
[65] M. Stereolabs, Stereolabs/zed-ros-examples, Jan. 2020. [Online]. Available: https :
/ / github.com /stereolabs/ zed- ros - examples/blob /master/ examples/zed _
rtabmap_example/README.md.
[66] F. Stereolabs, [question] mapping + point cloud · issue 572 · stereolabs/zed-ros-
wrapper, Jun. 2020. [Online]. Available: https://github.com/stereolabs/zed-
ros-wrapper/issues/572.
[67] Guneycan, Guneycan/coreslam, Aug. 2015. [Online]. Available: https : / / github .
com/guneycan/CoreSLAM.
[68] Alejocb, Alejocb/dpptam, Feb. 2017. [Online]. Available: https : / / github . com /
alejocb/dpptam.
[69] J. Engel and P. D. D. Cremers, Informatik ix chair of computer vision artificial in-
telligence, Mar. 2016. [Online]. Available: https://vision.in.tum.de/research/
vslam/lsdslam?redirect=1.
[70] LizMurphy, Vslam, Dec. 2012. [Online]. Available: http://wiki.ros.org/vslam.
[71] H. Zhang, B. Liu, C. Shen, H. Zhou, and S. Liu, “Research on v-slam methods,”
in 2019 IEEE International Conference on Mechatronics and Automation (ICMA),
IEEE, 2019, pp. 1055–1060.
[72] Help center, Oct. 2019. [Online]. Available: https://support.stereolabs.com/hc/
en-us/articles/213074149-ZEDfu-Best-Practices?mobile_site=true.
[73] EdwardNur, Why such a bad map using a depth camera? May 2019. [Online]. Avail-
able: https://answers.ros.org/question/317195/why-such-a-bad-map-using-
a-depth-camera/.
[74] Stereolabs, 2021. [Online]. Available: https://www.stereolabs.com/docs/video/
camera-controls/.
[75] m. Introlab, Introlab/rtabmap, May 2021. [Online]. Available: https://github.com/
introlab/rtabmap/blob/8c336e1e3929e3e1e331b4f7f1b1f151ff70c983/guilib/
src/ExportCloudsDialog.cpp.
[76] Jun. 2013. [Online]. Available: http://www.dld-llc.com/Diffraction_Limited_
Design_LLC/Software.html.
[77] Wire rope isolators: Vibrostop en, May 2021. [Online]. Available: https : / / www .
vibrostop.it/en/products/wire-rope-isolators/.

87
[78] Camera gimbal stabilizer wire rope vibration isolator all metal design, May 2021. [On-
line]. Available: http : / / fluid - meter . sell . everychina . com / p - 109727495 -
camera - gimbal - stabilizer - wire - rope - vibration - isolator - all - metal -
design.html.
[79] FabriceLarribe, Navigation, Sep. 2020. [Online]. Available: http://wiki.ros.org/
navigation.
[80] F. Furrer, M. Burri, M. Achtelik, and R. Siegwart, “Robot operating system (ros):
The complete reference (volume 1),” Cham: Springer International Publishing, 2016.
[81] J. S. Gill, Setup and configuration of the navigation stack on a robot, Jul. 2018.
[Online]. Available: http://wiki.ros.org/navigation/Tutorials/RobotSetup.
[82] nickfragale, Move base - ros wiki, Sep. 2020. [Online]. Available: http://wiki.ros.
org/move_base.
[83] NickLamprianidis, Costmap 2d - ros wiki, Jan. 2018. [Online]. Available: http : / /
wiki.ros.org/costmap_2d.
[84] A. Hornung, K. M. Wurm, M. Bennewitz, C. Stachniss, and W. Burgard, “OctoMap:
An efficient probabilistic 3D mapping framework based on octrees,” Autonomous
Robots, 2013, Software available at http://octomap.github.com. doi: 10.1007/
s10514-012-9321-0. [Online]. Available: http://octomap.github.com.
[85] S. Macenski, D. Tsai, and M. Feinberg, “Spatio-temporal voxel layer: A view on
robot perception for the dynamic world,” International Journal of Advanced Robotic
Systems, vol. 17, no. 2, 2020. doi: 10.1177/1729881420910530. [Online]. Available:
https://doi.org/10.1177/1729881420910530.
[86] I. Yanokura, Voxelgrid filtering, Sep. 2014. [Online]. Available: http://wiki.ros.
org/pcl_ros/Tutorials/VoxelGrid%5C%20filtering.
[87] jihoonl, Navfn - ros wiki, Oct. 2014. [Online]. Available: http://wiki.ros.org/
navfn.
[88] 130s, Why navfn is using dijkstra? edit, Feb. 2012. [Online]. Available: https : / /
answers.ros.org/question/28366/why-navfn-is-using-dijkstra/.
[89] NicolasVaras, Base local planner, Apr. 2019. [Online]. Available: http://wiki.ros.
org/base_local_planner.
[90] Jekyll and M. Mistakes, Apr. 2020. [Online]. Available: https://roboticsknowledgebase.
com/wiki/common-platforms/ros/ros-global-planner/.
[91] C. Roesmann, Mar. 2020. [Online]. Available: http://wiki.ros.org/nav_core.
[92] M. Guenther, Sbpl lattice planner, Sep. 2018. [Online]. Available: http://wiki.ros.
org/sbpl_lattice_planner.
[93] M. Likhachev. [Online]. Available: https : / / www . cs . cmu . edu / ˜maxim / files /
tutorials/robschooltutorial_oct10.pdf.
[94] T. Schwörer, Wiki, Feb. 2021. [Online]. Available: http://wiki.ros.org/global_
planner.

88
 [95] J. Mota, Oct. 2020. [Online]. Available: http://wiki.ros.org/dwa_local_planner.
[96] B. Cybulski, A. Wegierska, and G. Granosik, “Accuracy comparison of navigation
local planners on ros-based mobile robot,” in 2019 12th International Workshop on
Robot Motion and Control (RoMoCo), 2019, pp. 104–111. doi: 10.1109/RoMoCo.
2019.8787346.
[97] C. Rösmann, A. Makarow, and T. Bertram, “Online motion planning based on nonlin-
ear model predictive control with non-euclidean rotation groups,” CoRR, vol. abs/2006.03534,
2020. arXiv: 2006.03534. [Online]. Available: https://arxiv.org/abs/2006.03534.
[98] J. Thornton and M. Otto, Bootstrap, 2021. [Online]. Available: https://getbootstrap.
com/.
[99] 2021. [Online]. Available: https://jquery.com/.
[100] R. Toris, J. Kammerl, D. V. Lu, J. Lee, O. C. Jenkins, S. Osentoski, M. Wills,
and S. Chernova, “Robot web tools: Efficient messaging for cloud robotics,” in 2015
IEEE/RSJ International Conference on Intelligent Robots and Systems (IROS), IEEE,
2015, pp. 4530–4537.
[101] R. Toris, J. Kammerl, D. Lu, J. Lee, O. C. Jenkins, S. Osentoski, M. Wills, and S.
Chernova, Robotwebtools, 2021. [Online]. Available: http://robotwebtools.org/
index.html.
[102] J. Lee, “Web applications for robots using rosbridge,” Brown University, 2012.
[103] GvdHoorn, Rosbridge suite, 2021. [Online]. Available: http : / / wiki . ros . org /
rosbridge%5C_suite.
[104] M. Ubl and E. Kitamura, Introducing websockets: Bringing sockets to the web - html5
rocks, Oct. 2010. [Online]. Available: https://www.html5rocks.com/en/tutorials/
websockets/basics/.
[105] G. Lyon, “Nmap: The network mapper–free security scanner,” Nmap. org, 2016.

89
Appendix A
Outline of environment

Figure A.1: Caption

90
Appendix B
Particle filter

Figure B.1: Explanation of particle filter

91
Appendix C
Mounting designs

(c) Custom milled bolt for

(a) Foot (b) Mount for stabilizer cable camera mount

(d) Wire-rope stabilizer bottom (e) Wire-rope stabilizer top

(f) Jetson mount (g) Mean Well mount

Figure C.1: All designs for the mounting of the hardware.

92
Appendix D
Data flow architecture

Figure D.1: Project data flow architecture design

93
Appendix E
Sequence diagram

Figure E.1: Project sequence diagram

94
Appendix F
Web interface wireframe diagram

Figure F.1: Wireframe design for web interface

95
Appendix G
Screenshot of web interface

Figure G.1: Implemented interface in browser

96