NEXT GENERATION LOW-COST AUTOMATED

GUIDED VEHICLE

Master Degree Project in Virtual Product Realization

One year Level 18 ECTS
Spring term 2020

Yevheniy Dzezhyts

Supervisors: Stefan Ericson

Examiner: Anna Syberfeldt

Abstract

Automated guided vehicles (AGVs) are the key equipment of flexible production systems and an
important means for realizing a modern logistics system that meets the demands of Industry 4.0. AGVs
are used from the mid 50th to delegate monotonous work of delivering products from the human to the
automated device. In the long run, the usage of AGVs brings huge benefits to the manufacturing
companies. But the purchase and installation of these devices significantly increase operational costs.
This fact halts small and medium-sized enterprises from adopting this technology on their shop floors.

The idea of this thesis work is to design and create a device that can be retailed at a significantly lower
price without compromising flexibility and functional properties, to be used by smaller businesses. For
this mater are used more affordable parts that can bring the cost down of a final product.

This work describes the process of developing a differential drive mobile platform under the control
of the robotic operating system. The process includes the development of a virtual model; selection of
required components and investigation of their compatibility; development of chassis, suspension, and
gear system; development of a hardware interface to interact with hardware components; configuration
of different algorithms of control, cartography, and navigation; evaluation of the device.

The research method is used in this work is design and creation due to the necessity of creating a
physical prototype. The budget specification for the project was set to 50000 SEK and the desired
payload capacity was set to 100kg. The work has resulted in the creation of a prototype of the AGV.
The cost of the project is 20595 SEK. The evaluation of a prototype resulted in a maximum towing
force of 300N. The load capacity is limited by the mobile base is 400kg. Safety sensors are not used
in this project as the device was meant to operate in a controlled environment.

The work also gives an evaluation of the Gmapping algorithm in case of using the laser scanner
(RPlidar A1) and two algorithms of navigation stack: TrajectoryPlannerROS and DWA planner. The
final prototype is evaluated to support an autonomous movement within a controlled environment.

Keywords: ROS, low-cost, AGV, AMR, autonomous navigation.

i
Acknowledgments

I would like to thank my supervisor Stefan Ericson for the great support and sharing the knowledge and my
examinator Anna Syberfelt for inspiring me with good ideas.

Skövde, November 2020

Yevheniy Dzezhyts

ii
Abbreviations list

AGV – automate guided vehicle

AMR-autonomous mobile robot

AGC- automated guided cart

SME – small and medium-sized enterprises

SLAM – simultaneous localization and mapping

VSLAM visual simultaneous localization and mapping

IT – information technology

GPU graphical processing unite

USB – universal serial bus

GPIO – general purpose input/output

CUDA – compute unified device architecture

OS – operational system

ROS robotic operational system

CNN – convolutional neural network

HDMI –high definition media interface

SD –secure digital

SSD – solid-state drive

LTS – long-term support

BMC-brushless motor controller

LIDAR – light detection and ranging

iii
Certificate of Authenticity

Submitted by Yevheniy Dzezhyts to the University of Skövde as a Master Degree Thesis at the School of
Engineering.

I certify that all material in this Master Thesis Project which is not my own work has been properly referenced.

Signature.

Yevheniny Dzezhyts

iv
Table of Contents
1 Introduction ................................................................................................................................................. 1

1.1 Motivation ........................................................................................................................................... 1

1.1.1 The interest of industry in more affordable and flexible AGVs .................................................. 1

1.1.2 The high cost of AGVs ................................................................................................................ 2

1.1.3 The conservative methods of navigation used by AGVs ............................................................. 2

1.2 Purpose ................................................................................................................................................ 2

1.3 Objectives ............................................................................................................................................ 2

1.4 Limitations........................................................................................................................................... 3

1.5 Sustainable development ..................................................................................................................... 3

2 Frame of reference ....................................................................................................................................... 5

2.1 History and the current state of AGVs ................................................................................................ 5

2.2 Locomotion.......................................................................................................................................... 5

2.3 Kinematics of a mobile robot .............................................................................................................. 6

2.4 Safety ................................................................................................................................................... 6

2.4.1 Law requirements ........................................................................................................................ 6

2.4.2 Safety devices .............................................................................................................................. 7

2.5 Robot operation systems...................................................................................................................... 7

2.6 Localization ......................................................................................................................................... 9

2.6.1 SLAM .......................................................................................................................................... 9

2.6.2 Methods of navigation ............................................................................................................... 10

3 Literature review ....................................................................................................................................... 11

3.1 Selection of the robotic operation system.......................................................................................... 11

3.2 SLAM algorithms comparison .......................................................................................................... 11

3.3 The rosserial performance with Arduino microcontroller ................................................................. 12

3.4 Alternative methods of autonomous driving ..................................................................................... 13

3.5 Evaluation of literature study ............................................................................................................ 13

v
4 Research Methods ..................................................................................................................................... 15

4.1 Design and creation ........................................................................................................................... 15

4.2 Experiments ....................................................................................................................................... 17

4.3 The choice of the strategy.................................................................................................................. 18

4.4 Execution of strategy ......................................................................................................................... 19

5 The architecture of the AGV ..................................................................................................................... 21

5.1 Equipment.......................................................................................................................................... 21

5.2 Overview of the architecture of the AGV.......................................................................................... 22

5.3 Mobile base, suspension, and chassis ................................................................................................ 23

5.4 Electric motor .................................................................................................................................... 25

5.5 Chassis and gear system .................................................................................................................... 26

5.6 Motor Controller ................................................................................................................................ 28

5.7 Computing unit .................................................................................................................................. 31

5.8 Sensors and other components .......................................................................................................... 33

6 Algorithm and software ............................................................................................................................. 34

6.1 Overview of required software .......................................................................................................... 34

6.2 Jetson Nano setup and ROS installation ............................................................................................ 35

6.3 The URDF file development ............................................................................................................. 36

6.4 ROS Control ...................................................................................................................................... 36

6.5 Hardware interface ............................................................................................................................ 38

6.6 Rosserial node and Arduino setup ..................................................................................................... 40

6.7 Gmapping .......................................................................................................................................... 41

6.8 Navigation stack ................................................................................................................................ 42

7 Evaluation .................................................................................................................................................. 44

7.1 Towing test ........................................................................................................................................ 44

7.2 Cartography test................................................................................................................................. 45

7.3 Navigation test ................................................................................................................................... 47

vi
8 Discussion.................................................................................................................................................. 50

9 Conclusion and future work ...................................................................................................................... 52

9.1 Objectives verification....................................................................................................................... 52

Investigate the required technology for the construction of a prototype of the AGV ............................... 52

Create a low-cost (under 50 000SEK) and flexible prototype of the AGV ............................................... 52

Verify the performance of a prototype with functional tests ..................................................................... 53

9.2 The implication of the work. ............................................................................................................. 53

9.3 Future studies..................................................................................................................................... 53

References ......................................................................................................................................................... 55

Appendix A: The project expenses report ................................................................................................... 58

vii
Table of Figures

Figure 1: Iteration cycle of the project design (Vijay Vaishnavi, 2004) ........................................................... 16

Figure 2: Execute of research strategy .............................................................................................................. 20

Figure 3: Equipment used in the development process ..................................................................................... 21

Figure 4: Type of wheels configuration ............................................................................................................ 24

Figure 5: Central suspension joint ..................................................................................................................... 24

Figure 6: A virtual model of central suspension joint ....................................................................................... 24

Figure 7: Complete suspension unite................................................................................................................. 25

Figure 8: Custom gearbox module .................................................................................................................... 27

Figure 9: Suspension with chassis assembly ..................................................................................................... 28

Figure 10: Ros control dataflow (S. Chitta, 2017) ............................................................................................ 37

Figure 11: Navigation stack dataflow (Marder-Eppstein, 2020) ....................................................................... 42

Figure 12: Towing test setup ............................................................................................................................. 44

Figure 13: Test objects on the map .................................................................................................................... 46

Figure 14: Map of the test environment ............................................................................................................ 46

Figure 15: Test objects for cartography test ...................................................................................................... 47

Figure 16: An example of costmap ................................................................................................................... 48

Figure 17: Conceptual setup of the mobile robotic station ................................................................................ 51

viii
Index of Tables

Table 1. Comparison of electric motors ............................................................................................................ 25

Table 2. Brushless motor controllers ................................................................................................................. 29

Table 3 Minicomputers...................................................................................................................................... 31

Table 4: Comparison of the measured objects................................................................................................... 47

ix
1 Introduction
The introduction chapter aims to guide a reader through the motivation, purpose, objectives, and
limitations of this project. It also presents the sustainability goals of the Swedish government and the
relation of the project to sustainable development.

1.1 Motivation

Nowadays, the layout of the manufacturing process is often separated into highly specialized robotic
stations which perform certain manipulation with the product. In these circumstances, the
transportation of the product between station become a key factor which affects the performance of
the entire system. Traditionally, AGVs take a big share of a such transportation system thus, for the
company to win rivalry AGVs constitute an undeniable necessity. On the other hand, due to the high
cost and complicated installation process, the technology cannot be adopted by small and medium-
sized enterprises (SMEs). Thus can be distinguished three main facts which establish the motivation
for this thesis work: the interest of industry in more affordable and flexible AGVs, the high cost of
AGVs, the conservative methods of navigation used by AGVs.

1.1.1 The interest of industry in more affordable and flexible AGVs

The experience of a few Industrial Revolutions has shown that one of the best ways to increase the
productivity of manufacturing plans and reduce production costs is to delegate part of a manufacturing
process to a machine. Nowadays, the automation concept increases its value and became a necessity
for the most of the big manufacturing companies (Hawkins, 2013).

Such high demand for automation has been encouraged the growth of the material handling field. One
of the most efficient ways of transporting materials between stations became automated guided
vehicles (AGV). AGV is a vehicle that is controlled by certain logic and can move from point “A” to
point “B” usually transporting some objects. AGVs are the key equipment of flexible production
systems and an important means for realizing a modern logistics system that meets the demands of
Industry 4.0. AGVs can be used to transport material and products between stations, and AGVs can
also be used as flexible production lines themselves.

1
1.1.2 The high cost of AGVs

A problem today is that AGVs are very expensive, which limits their usage – especially in SME
manufacturing companies. A single AGV costs around 500 000 – 1 000 000 SEK which is an
investment that is too large for many SMEs. AGVs can be used to transport material and products
between stations as well as to be flexible production lines themselves.

1.1.3 The conservative methods of navigation used by AGVs

Most of the manufactures still prefer to use conventional AGV with a predefined path. This concept
is not always suitable for SME business and in general, is against of principles of Industry 4.0.
Together with AGV, some researchers distinguish its next-generation autonomous mobile robots
(AMR). The key difference is that AMRs can offer infrastructure-free navigation capabilities. This
fact delivers huge advantages for production systems: path flexibility, scalability, product
customization, assembly line relocation, etc Thus, higher scientific attention to flexible navigation
methods might change the situation and facilitate the development of more advanced robotic systems
(Alexandra Markis, 2019).

1.2 Purpose

This thesis project's purpose to investigate and suggest methods of design and build a flexible, low-
cost AGV solution that can make it possible to increase the use of AGVs in manufacturing companies,
and thereby increase flexibility and efficiency in the production systems.

The idea in the project is to make use of low cost, yet sophisticated, consumer products and implement
free software for navigation and control of the AGV. The pre-requirement is that the cost of the AGV
should not exceed 50 000 SEK, which can be set concerning the current cost of an AGV which is 10-
20 times higher.

1.3 Objectives

 Primary objectives:
o Investigate the required technology for the construction of a prototype of the AGV.
o Create a low-cost (under 50 000SEK) and flexible prototype of the AGV.
o Verify the performance of a prototype with functional tests.
 Secondary objectives:

2
 o Evaluate localization and navigation algorithms.
o Investigate general requirements for the safety of automated equipment.
o Increase awareness of Robot Operation System (ROS).

The main set of objectives of this work is related to the construction of a low-cost prototype of an
AGV. This concept can facilitate the change in material handling procedures and allow the possibility
of AGVs usage by small and middle-size businesses.

1.4 Limitations

The prototype of the AGV is to be used in a controlled environment carrying a weight that is less than
100 kilograms. Although the environment of intelligent reconfigurable manufacturing (IRMA) is
designed to be as close as possible to the production line, some safety concepts are followed in general
terms, which might be distinct from a real case scenario.

1.5 Sustainable development

Sustainable development can be defined as development that solves issues of the present and does not
compromise the abilities of the future generation to solve their issues. Humanity's activity of adapting
the planet Earth to their needs pretty often results to decrement of the resources such as air, land
natural resources. The field of engineering is one of the most important points of leverage where the
risks of new solutions and inventions must be well examined. The sustainable development dilemma
comes in several planes: social, economic, and ecological systems (Reyes, 2015).

Sustainability issues encourage socially responsible countries to react to the changing environment
and maintain the resources of the Earth. Swedish program of Sustainable Development of 2030
consists of 18 goals which come in different planes.

Social sustainability goals:

 Zero hunger
 Quality education
 Decent work
 Good health and well-being
 Reduction of inequality

3
  Gender equality
 Peace, justice, and strong institution

Economic sustainability goals:

 Economical growth
 No poverty
 Industry, innovation, and infrastructure
 Responsible production and consumption
 Partnerships
 Affordable energy

Ecological sustainability goals:

 Clean water and sanitation

 Climate actions
 Life on land
 Life below water
 Clean energy
 Sustainable cities and communities (Peter Eriksson, 2020).

The industry is responsible for creating safe, useful, ecological technology that will serve society
without compromising its future. Thus, all devices which are created in the industry must use clean
energy, be easily recyclable or consists of recycled components, free humans from monotonous tasks,
and motivate them to acquire better knowledge. AGVs or mobile robots are one of the best examples
of how humans can be freed from monotonous tasks of transporting goods from one point to another.
These devices allow personal to perform only intelligent work. On the other hand, in the case of SMEs
and their owners, smart factories can increase throughput and reduce resource utilization. Thus, it
might result in cheaper products and more competitive businesses. Furthermore, AGVs are mostly
powered by electrical energy which can be supplied by sustainable power sources.

This thesis project might include a mobile electrical power source and rare Earth materials used in
electric motors. Recycling of all electrical and electronic equipment selected for this thesis project has
to be done following the European Union, 2012. Directive 2012/19/EU (European Union, 2012).

4
2 Frame of reference
The chapter covers the theoretical framework which is used in designing and creation a prototype of
AGV. It describes the history and evolution of AGVs, locomotion, kinematics, safety aspects, robotic
operation system, and localization algorithms.

2.1 History and the current state of AGVs

The very first AGVs were developed in the 1950s by a company called Barrett Electronics. These
devices used basic logic and simple structure and were a modification of towing tractor which was
pulling trailers (Hammond, 1985).

Traditionally AGVs are considered vehicles that use conservative driving methods along a predefined
path. For a while, it was the only available method of navigation for such vehicles. In recent years
with the growth of technology and computational power were developed more sophisticated methods
of navigation. The new methods are based on the probabilistic approach of localization and can offer
dynamic path replanning. These features are required by the flexible nature of Industry 4.0. Some
researchers name the new generation of AGVs the autonomous mobile robots (AMR) which reflect
its flexible capabilities. The new approach not only adds more opportunities but also brings more risks
in the safety retrospective as not all the pathways comply with safety routines. Moreover, as ARMs
become smarter and flexible, more tasks are delegated to such apparatus. This facilitates a higher level
of automation and in the worst case turns the stuff to be replaced by the robots (Alexandra Markis,
2019).

Nevertheless, the market is fulfilled with different options of AGVs and ARMs that indicate high
demand for such apparatus. The most promising are MIR from Universal robots, ARMs from MHS
and Conveyco, etc. Some of the traditional design AGVs can be seen from Janbro, Agvegroup, Rocla.
One of the most affordable devices is MIR200 which is sold with a price tag of 257 250 SEK
(COBOTS, n.d.).

2.2 Locomotion

Wheel based robots are one of the most popular. This locomotion design comes in a great variety. The
minimum amount of wheels for the stable operation is two though it requires some special design
decisions. If more than three wheels are used in the design of a mobile robot the suspension must be

5
implemented to ensure stable contact of the wheels to the ground floor. There are four basic types of
wheels:

a) The first type is a basic wheel design with two degrees of freedom.
b) The second type is castor wheels with two degrees of freedom.
c) The third type is Swedish omnidirectional wheels with three degrees of freedom.
d) Fours type is a ball spherical wheel with 3 degrees of freedom (Siegwart Roland, 2004).

2.3 Kinematics of a mobile robot

Kinematics study can answer the question of how the mechanical system behaves. It is necessary for
creating a control system for a robot. Segward, 2004 says that the kinematics of mobile robotics is
derived from the manipulator kinematics study, as it is well-developed compare to the previous one.
The great difference between those two is that one end of a manipulator is affixed to the environment
thus, its position always constant which is not the case with a mobile system. On the one hand position
of the manipulator’s joints are always computable based on joint sensors. On the other hand, hence a
mobile robot self-containing mobile system, its position is not always compatible with conservative
methods. To calculate the position of a mobile robot one must log motion information over time and
based on the log and geometry features create a motion estimation. In the motion estimation process
data from the odometry, the source will be transformed to the odometry of the system using a global
reference plane (Siegwart Roland, 2004).

2.4 Safety

The safety problem is one of the most important factors of electrical device usage. This subchapter
reviews major law requirements and standards which are regulating design, manufacture, retailing,
and usage of AGVs.

2.4.1 Law requirements

To guaranty, the safety of personal and property and increase the accepted level of these devices by
the public, AGVs, and ARMs must comply with strict safety rules. Most of its performance is
regulated by the Machine Directive in types A, B, and C.

 A type defines general safety standards and principles of apparatus design and obligates
manufacturers to perform a risk assessment. The standard is regulated by EN ISO 12100.

6
  B type defines generic standards of application of certain types of machinery and is regulated
by standards EN ISO 11161 and EN ISO 13849.
 C type defines safety requirements for a particular machine and regulated by the standard ISO
10218 and ISO 3691-4:2020.

Moreover, all electronic devices sold in Europe must follow ICE guidelines and its subdivision EMC
certification (EN 62061). This procedure aims to guaranty a similar level of safety health and
environmental protection. It is the responsibility of the manufacture to comply with its product with
the safety requirement of EEA countries and affix CE marking on the product. Thus, the selection of
the components is not strictly limited by CE requirements but compliance of the components of the
final product will make the CE testing and certification process much easier. It worth admitting that
some types of product certification processes must involve special authorities to comply with EEA
safety requirements (Alexandra Markis, 2019).

EMC standard specifies electromagnetic field radiation pollution and resistance norms. Unwanted
electrical emission standards are specified by several directives of the European Union: 2014/30/EU,
EN 50081, EN 55032, etc. Electromagnetic immunity standards are specified by directives 50082 and
55024. In the case of electromagnetic pollution or the immunity level of selected components exits
norms allowed in EUA, components can be isolated to meet requirements. (IEC regulation link)

2.4.2 Safety devices

Most of the automated systems are equipped with several sensors that guarantee its safe operation. A
safety system must be separated from the noncritical information source and be certified with standard
EN 61508 (Alexandra Markis, 2019). In some cases, IES 61511 standard allows the usage of devices
that are not certified with EN 61508.

One of the most critical safety systems is a safety bumper. This device's purpose is to stop the robot
in case of contact with an obstacle. There are two types of safety bumpers: physical and laser safety
bumpers. The laser safety bumper is far more expensive but might require less maintenance (Iversen,
2005). The test and design technique is discussed by (Richard Norcross, 2015).

2.5 Robot operation systems

Navigation, mapping, and control algorithms are the most important parts of the software of the
custom robot. Indeed, through the history of robotics can be found many algorithms and pieces of

7
software that might suit this purpose. The only problem is to combine these bits of software in the
final piece which will manage custom robots. Through the years the robotic community was searching
for a way to combine, unify, and standardize works of different scientists in one piece of software for
open-ended collaboration. There are were several tries to reach this goal by Stanford University in the
mid-2000s and Willow Garage in 2007. Since the software was developed using BSD open-source
licenses other researchers have picked up this mission and gradually ROS became a widely used
platform. The goal of ROS is to support code reuse in robotic research and development (Anon.,
2017).

ROS is a framework that is used to create robotic applications. It does supply software tools, libraries,
and collections of the packages to assists the robot software development process. The ROS is
distributed under the BSD license that allows its use in research and commercial applications. Despite
the name which might give an illusion the ROS is not a full-size operating system but rather a
metasystem that is installed on top of regulars OS, usually Ubuntu. The most important features of
ROS are:

 Message distributions interface

 Hardware independence
 Package management
 Big amount of libraries
 Low-level hardware control
 Distributed computing
 Code recycling
 Programming language independence
 Testing tools
 Scaling
 Free and open-source (Lentin, 2018).

The ROS systems consist of ROS Master and peer-to-peer connection which process data and manage
a network. The basic elements of such a network are:

 ROS Master: the ROS master is a core service that distributes information about nodes and
topics, and performs the connection.

8
  ROS Nodes: the node is a process which performs the calculation and/or controls device,
publishes, reads topics.
 ROS Topic: the topic is a communication bus for the ROS nodes. The read and write activity
of the node is called subscribing and publishing.
 Parameter Server: the ROS parameter server hosts static information that is used by nodes,
usually configuration data.
 Messages: a ROS message is a data type. Nodes are publishing data using message data type
to the topics.
 Services: a service performs request/response activities it operates using message type
declaration.
 Bags: the bag can store information that was published on the ROS topic (Lentin, 2018).

2.6 Localization

Unlike the design of AGVs, navigation and localization methods have experienced high improvement
results. At the beginning of an AGV development process, the defined path guidance was the only
option for such a device to operate. With this approach there was not such a strong need for
localization techniques as the robot would stay always on the defined path. With prominent
localization technology and improvement of computational efficiencies the field of material handling
steps in the area of intelligent machines that do not particularly need additional structural pre-setup
and can operate in any environment. This is due development of such technology as simultaneous
localization and mapping (SLAM) and Convolutional neural networks (CNN).

2.6.1 SLAM

SLAM technique allows AGV to start in an unknown location and an unknown environment and then
to build a map of this environment. In this approach the data from a LIDAR sensor or a camera is
matched with odometer readings of a mobile robot, it allows the system to generate the map of the
environment “on the fly” and localize the mobile robot in the environment. Slam is heavily used by
Robotics and Augmented reality field. But still, the systems which build on SLAM technology would
require many ad-hoc solutions for its implementation (Milad Ramezani, 2020). The attempt to
automate the process of SLAM implementation is done by Colosi and Ramezani. (Colosi, et al., 2020).
The authors discuss the SLAM development state also proposes the usage of LIDAR sensors and
“maplab” - the framework for area mapping technic. While the most common way of environment

9
mapping in the ROS framework is the Gmapping algorithm. The other localization technic which is
discussed in the article is RTAB-Map which is a state of art in the field of vslam. VSLAM stands for
Visual SLAM. This algorithm requires a camera image to identify certain features in the mapped
environment, then position the robot by referring to the map of features. (Farzin Amzajerdian, 2011).

2.6.2 Methods of navigation

In past the most of the solutions in material handling heavily used predefined paths and simple logic.
These kinds of solutions exploit the usage of a magnetic field sensor which would measure magnetic
field exposure and send information to a controller. The controller then pulses the output signal to
motors to move along the path. The checkpoint would have a different layout which can be also
registered by a different group of sensors thus, a mobile robot would stop for a certain amount of time
or until some next event would be fired. The magnetic field can be generated by magnetic tape or
inductive wire. Also, magnetic field sensors can be substituted with an infrared sensor to detect
colored tape. This approach is discussed well by Cawood and Gorlach. The authors stated in their
work that the minimum amount of sensors are two and can be extended for better accuracy (Cawood
& Gorlach, 2015). The defined path approach includes many benefits like the simplicity of
implementation, lower cost, constant path. On the other hand, it lacks flexibility and might require
more investment in the setup phase.

Unlike the predefined path approach flexible path planning assumes that the software of a mobile
robot will calculate the needed trajectory independently. An infrastructure-free AGV requires fewer
input arguments, but trajectory generation requires more sophisticated logic thus more computational
power. The path planning technique depends a lot on application design where AGV is used. Here can
be seen major differences between on-road vehicles and robots for material handling.

The path for an on-road vehicle is predefined by the infrastructure of the road network but in material
handling premises might be no specially designed path for AGVs. This fact leads to the necessity of
generating a trajectory. One of the first successful implementations of the AGV with flexible path
generation has used the concept of polynomial spiral whose curvature is polynomial in distance.
(Kelly, et al., 2007). This concept is inspired by the Euler spiral, which is generally used to build road
networks to eliminate inertia during the driving of a vehicle. In the material handling field, the same
concept is used to smooth the trajectory curve and position the vehicle with the correct vector.

10
3 Literature review
This section describes the works of other researchers that are particularly interesting for this project.
The chapter reviews comparison of different robotic operation systems, usage of Arduino devices
within the ROS framework, comparison of different SLAM algorithms, and autonomous driving by
AI. The subsection discusses the appliance of reviewed technology to this project.

3.1 Selection of the robotic operation system

Robot operating systems: Bridging the gap between human and robot (John Kerr, 2012). In their
work, Kerr and Nickels discuss a selection process of robot operating systems that can be used by the
students to encourage the robotic development process in Trinity University Engineering. They supply
a comparison table of different robotic operating systems and passing score it each of the systems.
During the selection considered capabilities, adaptability, installation process, and level of difficulty
of usage of every ten robotic operating systems. For comparison by authors were chosen following
robotic operation systems CARMEL, RDS, MOOS, Player/Stage, ROS, Orocos, YARP, MRPT, Urbi,
Webot.

The authors state that ROS is the best choice for a robotic operating system for students without
programming skills restriction. At the end of the research Player/Stage was chosen for a students’
usage.

3.2 SLAM algorithms comparison

Implementation of SLAM algorithms in a small-scale vehicle using model-based development

(Johan Alexandersson, 2017). In their work Alexandersson and Nordin discuss a process of
developments of small-scale vehicles by using ROS. To host ROS authors use Nitrogen6_Max
embedded computer with the Lubuntu operation system. Input sensors are represented by RPLIDAR,
IMU sensor, and hall sensor on each of the back wheels. The chassis steering type is chosen Ackerman
steering. As a microcontroller is chosen STM32 board.

After constructing a physical prototype of a small-scale vehicle, the authors perform a comparison of
the three SLAM algorithms: EKF, GraphSLAM, and FastSLAM. After an algorithm investigation
authors narrowed down the scope to two algorithms GraphSLAM and FastSLAM. In the ROS
framework, GraphSLAM is represented by package Gmapping and FastSLAM by package

11
slam_karto. The algorithms have display diverse error results depending on the size of the map. In the
small map, slam_karto demonstrated an error percent of 0,0783 compare to Gmapping with 0,1983.
In the large map 0,6829 and 0,4260 respectively. Also, Gmapping demonstrated higher resource
utilization in maps of different scales. Furthermore, the authors report the unreliable performance of
the slam_karto node. In conclusion, the authors recommend using the GraphSLAM algorithm and
Gmapping node for creating a map of the environment.

3.3 The rosserial performance with Arduino microcontroller

Introducing modern robotics with ROS and Arduino, including case studies. (Zubrycki, 2014).
Zubrycki gives a good overview of ROS and discusses the process of learning the framework. The
ROS has received a lot of attention last year and is considered a highly prospective framework for the
robotic project. It is a highly customizable piece of software that can be adapted for almost any need.
Together with customizability comes its diversity and complex philosophy. Zubrycki says that the
ROS framework has a stiff learning curve and it is hard to grasp for students with low technical skills.
Nevertheless, the framework can offer several tools and online tutorials that can speed up the learning
process. According to him, some students who were involved in the ROS workshop course were able
to perform “real work” after completing online tutorials and practicing ROS with special tools.

The other point discussed by Zubrycki 2014 that ROS offers quite a dissent support for Arduino
microcontroller. It is especially important as Arduino is a highly customizable device that helps to
extend the solution with physical devices and sensor arrays. In case if challenges of learning the
framework are not critical for the project ROS and Rosserial are suggested for use in robotic projects.

Integrating Arduino-Based Educational Mobile Robots in ROS (Andre Araujo, 2013). The Authors
of this paper describe the process of creating a low budget conceptual vehicle that can be used by
rescue teams. The ROS framework is suggested for the main control system. Pereferial hardware is
suggested to be controlled by OMNI 3MD and ATmega 328 microcontroller. The authors analyze the
communication between Netbook and Arduino with a rosserial node. Unsatisfied by the performance
of the rosserial authors suggest their version of a driver (mrl_robots) for communication with Arduino
devices. After developing the driver, its performance was tested with several devices such as an
encoder sensor and ultrasonic range sonar. Furthermore, a custom algorithm was developed to avoid
collisions between two robots.

12
Overall the main outcome of this work is a custom driver which can lower the load on the serial
interface. In situations when the Arduino board is used as the main microcontroller and especially if
a wireless connection is used this driver can give a certain level of flexibility and increase the
robustness of some nodes.

3.4 Alternative methods of autonomous driving

End to End Learning for Self-Driving Cars (Bojarski, et al., 2016). The authors of this article
describe the evolution of an autonomous driving system DAVE which was first developed in 1989 by
the Defence Advanced Research Projects Agency. The initial DAVE system had demonstrated the
potential of the End to End cycle of automated driving methods. The evolution version proposed by
Bojarski et al in 2016 consists of several neural networks that record actions of a human driver and
map it to information from various sensors e.g. cameras. This approach allows CNN to learn patterns
of human driving behavior. The new implementation is named DAVE-2. The embedded device used
for training is NVIDIA DRIVE PX. Information is recorded from a steering wheel angle reader and 3
external cameras. The weights of CNN were design to minimize the mean square error from a steering
command generated by the network and the command of either a human driver or an adjustment for
the off-centered and rotated image.

The tests were performed in the simulation environment and on a road vehicles in various weather
conditions. The authors claim that 98% of the time while the test was performed the vehicle drove
autonomously.

3.5 Evaluation of literature study

As research nature always prefer several options rather than only one input, it is important to take into
account all the available robot operation systems available. In the research of Kern and Nicles 2012,
authors review the positive and negative effects of choosing one or other robotic operating systems.
Although the goal and limitations of their project are not similar to the nature of this work, some useful
data can be extracted.

The other thing to evaluate is the tendency of scientific society to develop one or the other framework.
For this matter can be reviewed the level of complexity, interest an involves of the society in a
particular technology. Furthermore, authors state that ROS would be one of the best choices for their
research, but as the targeting group is considered to have less developed programming skills the

13
preference is given to another robotic operating system (John Kerr, 2012). This limitation can be
considered as a challenge for this project as well.

The other important question is how extensible ROS is and what level of integration it can achieve
with different devices. The question was answered in the works of Zubycki, 2014 and Araujo 2013.
In their works, the authors investigate the methods of connecting Arduino microcontroller. The
Arduino has several benefits such as low-price of the device, intuitive IDE, GPIO pins with 5v output,
full support of ROS. From disadvantage is a limited connection speed reported by (Andre Araujo,
2013). After all, Arduino can be subjected to be used in this project. Its preliminary function can be
communication with the controller and reading encoder pulses.

A higher level of control includes localization within the map and navigation. The process of creating
a map and positioning a robot within the map is simultaneous localization and mapping (SLAM). The
ROS framework offers several SLAM algorithms that are discussed by (Johan Alexandersson, 2017).
In their work authors evaluate the performance of several SLAM algorithms and select GraphSLAM
as the best one.

The ROS framework provides a set of algorithms for path generation, obstacle detection, and path
execution. The algorithms are distributed through the package Navigation stack. (Sumegh Pramod
Thale, 2020). Although in recent years high interest is developed around AI navigation which is used
in autonomous cars. One of the successful implementations of autonomous driving on public roads is
described by (Bojarski, et al., 2016). The research is supported by NVIDIA and makes use of several
convolutional networks that are configured to learn a driver behavior and reproduce is it in
autonomous mode. Unfortunately, this algorithm is not implemented in the ROS and its
implementation is out of the scope of this work, but its employment can be considered in future work.

14
4 Research Methods
This section describes the methodology choice and utilization. Several research methods are used in
this work: design and creation and experiments. This chapter includes a description of the methods
and selection of the research strategy.

4.1 Design and creation

Hence this project requires creating a physical prototype of the AGV the design and creation method
can be used. Traditionally the design and creation approach is seen as a problem-solving iterative
process that includes 5 steps: awareness, suggestion, development, evaluation, and conclusion. An
illustration of the methodology process can be seen in Figure 1.

 Awareness is the recognition of the problem which authors gain after study related
literature. At this phase of the research will be reviewed similar studies, studies of a theory
concerning AGV development, localization, path planning, etc., also law requirements
concerning safety.
 Suggestion, in this step ideas, might immerge from curiosity about the studied concept. At
this phase of the research will be proposed: raw physical and electrical design of a
prototype, a list of required components.
 Development, in this step the concept will be developed into the form of theory and most
probably implemented. At this phase of the research, all required components will be put
together and configured.
 Evaluation is where theories are getting examined. At this phase of the research
performance of the prototype will be evaluated. The evaluation will cover such areas as
path-planning, performance, and durability.

15
  The conclusion is the step where results are written down or implemented into a physical
prototype (Vijay Vaishnavi, 2004).

Figure 1: Iteration cycle of the project design (Vijay Vaishnavi, 2004)

According to Oates these steps are not strictly followed but instead they form an interactive cycle that
allows us to gain explicit or perhaps alternative knowledge about the problem. The research and
development methodologies are widely discussed in the literature and must not be confused with each
other.

The development method or methodology elaborates on how one would invent new knowledge
through the process of analysis, design, implementation, and testing. The research methodology on
the other hand is research strategies and data generation methods. The development research strategy

16
can be one of existing like Web Information System Development Methodology or Information
Engineering or any specific methodology for the project (Oates, 2012).

4.2 Experiments

In academic research an experiment is a strategy that examines case and effect associations, seeking
to verify or refute a connection between a factor and an observed consequence. This strategy is mainly
used in positivistic research but is a great tool to evaluate the performance of an IT artifact. For
example, in the case of using a camera in this project, the performance can be evaluated under different
lightning conditions because most of the production sides might have conditions that are different
from the testing environment. According to Oates, 2012 it is very important to define a factor that
affects has significant importance to the application and exclude all the other factors.

Such a research strategy would be characterized by the following factors:

 Observation and measurements

 A process of observation and measurement of a factor
 Verifying or refuting an association between two or more factors
 Identifying factors which have a significant effect
 Explanation and estimate
 Repetition.

When setting up an experiment the theory must be defined in advance as well as a set of variables that
will be tested. Mostly it is used in form of a prediction. For example, the picture recognition with the
camera will most probably work under normal lighting conditions and will have less impressive in the
case of poor lighting conditions. The possibility of disproving or falsification of the theory must be
also allowed. The variables must be defined as dependent and independent.

The main purpose of an experiment is to prove that only the defined factor causes a major effect on
the application. There are some ways to control variable that might affect the outcome:

 Exclude the factors from the experiment

 Hold the factors constant
 Use a random choice of subjects
 Use control groups

17
  Make the researchers and subject blind (black-box testing).

The project has good internal validity if the result is achieved due to the manipulation of the
independent variable.

External validity, on the other hand, is considered successful if results are not unique but can be
generalized and the result can be predicted for subsequent factors and in any other situation. The best
way to improve external validity is to perform a significant amount of experiments.

The positive facts of such a research strategy include:

 The strategy is well established and considered as the most “scientific” approach.
 The research strategy is considered to be the only one that can prove a causal link.
 The laboratory experiment carries a high level of precision.
 The laboratory experiment lets the researcher persist at their regular place of work.

On the other hand, the disadvantages of experiments include:

 Laboratory experiments often create non-natural conditions

 It might be challenging to control all the relevant factors
 It might be challenging to recruit an illustrative group of participants
 It might be necessary to cover the purpose of the research from participants.

By considering the good and bad sides of the experiment-based research, can be found the most
successful strategy and receive the scientifically proven result (Oates, 2012).

4.3 The choice of the strategy

A literature review is used to gain awareness and for gap spotting and generating a knowledge base
for this work. A systematic literature review of high impact articles was used in the beginning. Later
on, the snowballing approach was used to get deeper into the research field. The basic idea of these
methods assumes the utilization of the reference list of selected articles, which can be an entry point
to the research database available in the field of study (Wohlin, 2014).

One of the objectives of this work is to construct the prototype of an AGV, thus it is important to
choose the correct methodology which allows the creation of an artifact. One of the methods which

18
fall under this requirement is “Design and creation”. This methodology assumes even the case when
a particular technology is not the main focus of the research but rather a vehicle for something else.
In the case of this project, the main focus is to investigate the concept of a combination of chosen
technologies can deliver the expected result. The 5 iterative steps of design and creation strategy
facilitate knowledge contribution on every step of the research. It is important because while dealing
with edge software and consumer products the level of awareness is not the same as in the case of
usage of industrial equipment. Thus in a lot of cases products lack detailed descriptions (datasheet,
available API, etc) and information can be procured through the process of reverse engineering. In
this case, information that is received during the research process can lead to the previous phase or in
some cases to the change of the initial layout.

The complimentary research strategy can be experiments. The experiment framework can enhance the
evaluation phase of the research and supply vital instruments to enhance the research results. The
requirement for scientific research quite often is more critical thus the experiment technique has to be
chosen more carefully.

4.4 Execution of strategy

The work in the project assumes three main phases which are connected with iterative loops: suggestion,
development, and evaluation phase (see Figure 2). The project starts with the acceptance of specifications.
Then during the suggestion phase, software, hardware, and other components will be selected according to the
requirements. The phase of the suggestion starts with software selection because it is a preliminary step. In case
hardware is selected before software, the author might face compatibility issues.

The development phase is of the opposite structure compare to the previous one. Although there is a possibility
to develop a fully virtual solution and transpose it on the physical prototype, in most cases simulation software
is not reflecting real-world properties. Thus, the first step of the development phase is to combine selected
equipment and create a prototype.

The second step is to create and/or adapt software. In this step virtual and actual world properties have to be
configured to match each other. This will give an option to perform the development process in a virtual
environment and transpose it to the actual prototype after achieving the desired behavior.

The third step is an evaluation phase that consists of different testing methods. This phase is needed to verify
that the desired behavior complies with the specifications of the project. The test design can be:

 Towing test to verify that required force are generated by the device

19
 Cartography test to verify the accuracy of the map
 Navigation test to verify the ability of the robot to move autonomously.

Figure 2: Execute of research strategy

20
5 The architecture of the AGV
This chapter describes the process of development of the mechanical and electrical parts of the
prototype. The chapter consists of a description of equipment (see Figure 3), architecture, chassis,
suspension, gear system, electric motors, electric motor controllers, computing unite, and sensors
which are required for the design of a prototype of an AGV.

5.1 Equipment

Figure 3: Equipment used in the development process

21
  Jetson Nano embedded computer from Nvidia is used for hosting the ROS operation system
and communicating to the Arduino microcontroller. It contains Ubuntu 18.04, wifi, Bluetooth,
128 Cuda cores, 4 USB3 ports, HDMI and display ports.
 Arduino Mega microcontroller contains I/O ports. The most critical for the project is 6
interrupt ports and one PWM port.
 1-Q-ES Amplifier is a brushless motor controller. It offers a speed and an effort control loop.
 Rplidar is a 2D LIDAR which is capable of a 360-degree scan. The range is 12 meters.
 The converter is used to convert the voltage from a 36 volts hoverboard battery to a 5 volts
input for jetson nano. Jetson Nano requires a 4 ampers power supply if a barrel jack connector
is used.
 The hoverboard is a two wheels gyro scooter. For the project is used a battery and two motors
 Motor Stand with 4 caster wheels

5.2 Overview of the architecture of the AGV

The process of design and creation of a mobile robot or an AGV requires a set of decisions in the
mechanical, hardware, and software areas of the prototype. These decisions are influenced by the set
of requirements and specifications of the project and often interdependent. To fulfill the specification
and guarantee consistency of overall layout this work will review the architecture of the AGV in the
following order:

 Algorithms and software

 Hardware and components
 Mechanics and kinematics

As discussed above the biggest collection of algorithms for a robotic project can be found in the ROS
framework. The algorithms which state the point of interest are SLAM and path generation algorithms.
This framework is not a standalone operating system and will require the use of an arbitrary OS. The
best OS for the ROS framework depends on the selection of the ROS version and release. Although
ROS version two is more promising at the time of writing, ROS2 is still in development. Thus, the
choice of the ROS version has to be limited to ROS1. ROS release is mostly optimized for a certain
version of OS. The most stable release of ROS at the time of writing is considered ROS Melodic
Morenia which is compatible with Ubuntu Bionic 18.04 LTS

22
(http://wiki.ros.org/melodic/Installation/Ubuntu). Thus, hardware for hosting ROS Melodic has to be
compatible with this version of OS.

ROS system layout allows using several machines connected by one network. That means that level
of autonomy of the mobile robot can be selected by the system architect from a variety of choices.
The higher level of autonomy is an advantage for mobile robot solutions as it can eliminate problems
with networks and increase the range of applications. On the other side, this will limit the computing
power of the solution as mobile computers that can host Ubuntu Bionic are less powerful and/or more
expensive.

There are several options for mobile computers that can be used in residential and industrial
environments. The industrial environment has a higher set of requirements expressed in the IEC 62061
standard. As the scope of this work considers safety only in general terms the range of options will
not be limited only by the industrial environment.

Other components are electric motors, motor controllers, microcontrollers, distance sensors, and
cameras. The selection of these components will be review in depth in further chapters.

Mechanics and kinematics parts of the mobile robot development are represented by the choice of the
mobile base, chassis, transmission, and methods of applying a force of electric motors into kinematics.
The maximum weight of the object which can be transported by the AGV prototype is set to 100kg
by the limitation section of this work.

5.3 Mobile base, suspension, and chassis

As was mention in previous chapters, a mobile robot can be designed from scratch or be a modification
of existing equipment. As the original goal of this project is to transfer a model of the engine assembly
between the robotic station the selected structural base has to be compatible with engine housing. The
equipment which fits this purpose is a typical motor stand. The maximum payload of a selected motor
stand is 450 kilograms, which covers the requirement of this project. Some motor stands are equipped
with caster wheels and can be used to transport an engine in a workshop. On the selected model of the
engine stand one pair of wheels has only one degree of freedom and must be replaced with another
pair of wheels. The possible wheel configuration can be seen in Figure 4.

23
 Figure 4: Type of wheels configuration

A and C options require servo drives thus increase the cost of the project. Option D will require
four separate electric motors which can take a payload of at least fifty kilograms. Thus, the best
option is the B option with two drive wheels and four support wheels. This type of chassis is often
named differential. Although this type of chassis is quite reliable and easy to implement, the final
solution will require to add suspension for the better contact of the wheels to the floor.

For suspension to guaranty permanent contact to the floor, it needs to share weight between two
wheels. If wheels are connected with the same link, this link has to be always parallel to the floor.
One way of sharing payload is to add an extra joint that will position the chassis according to with
relief of the floor. An example of such a joint can be seen in Figure 5 and 6.

Figure 5: Central suspension joint

Figure 6: A virtual model of central suspension joint

For better grip chassis must be well attached to the floor. This can be achieved by adding springs
between the chassis and the base. An example of the final suspension block can be seen in Figure 7.

24
 Figure 7: Complete suspension unite

This kind of suspension is efficient if the floor surface change in linear movement, not more than
twenty millimeters. Thus, this setup will cover most of the factory floors. In case if the floor has
major changes of the surface or the robot aims to drive over an obstacle type D suspension will be
more appropriate, because it does not require additional suspension. But in this case, AGV will not
be capable to take a higher payload or motor shafts have to fall with required payload specifications.

5.4 Electric motor

The mobility nature of a robot dictates the necessity of using an electric motor compatible with the
mobile power source. The motor in consumer electronics is presented by two groups of brushed and
brushless electric motors. Each of the groups has its advantages and disadvantages, some of the most
critical characteristics vied in Table 1. Comparison of electric motors.

Table 1. Comparison of electric motors

Type of the motor Advantages Disadvantage

Brushed Can be used with a more simple Luck of encoder

controller

Some solutions implemented

with inbuilt gearbox

Brushless Higher torque Need more expensive

controller which will modulate
Presence of encoder
pulses for each phase

25
The motor selection for this product was limited by the price category of such devices. The best option
in regards to the safety and standards compliance might be industrial units from Nanotech, Regal,
Cyber-motor Wittenstein, or any other where supplier guarantees compliance to the safety norms.
Unfortunately, the price of all the mentioned products is outside of the budget of this project.

The other choice for the drive unit is electric motors which are used in consumer devices such as
products as electric bikes, electric scooters, hoverboards, and wheelchairs. Most of them are CE
marked thus, can be sold on the territory of the European Union. These motors are sold at significantly
lower prices than industrial solutions and available from local retailers either as a component or part
of the product.

For this thesis project was selected two 36v 250 watts brushless DC motors from a hoverboard. The
motor is well spread and sold at a lower price than industrial solutions. It consists of 30 permanent
magnet poles, thus has enough torque to move a weight of fifty and more kilograms on the flat surface.
Moreover, the pair of these motors will be able to move more than a hundred kilograms. Also, this
motor is equipped with an encoder.

The liability point of such a motor is its maximum speed which is much higher than expected in
industrial applications. Also, the payload must include not only the carried weight of an AGV but also
its mass. The maximum speed of this motor is 3.89 m/s which must be reduced to 1.3 m/s which is
required by industry. Also, its low spinning resistance will make difficult accurate movements.
Therefore, the custom-made transmission was made to increase the torque of the motor and reduce
maximum speed.

5.5 Chassis and gear system

Chassis design and structure mostly will be affected by the type of electric motor and its mountings.
For this project, two hoverboard motors were selected as the main driving force. The default
maximum speed of such motors is 3.89 which must be lower by 3 times to meet the norms of an
industrial application. On this point several options of gear systems can be used:

 Gearbox module (planetary gear)

 Pulley system
 Sprocket
 Cogwheel

26
To reduce speed, the driving gear must be smaller than the driven gear. The reduction ratio can be
calculated by division of the size or number of teeth of the driven gear and the drive gear. If the
gearbox consists of several gears, they must be multiplied to know the actual ratio. To follow
budget requirements can be used sprockets from bicycle cassette. Each cassette usually consists of
8 sprockets which can be used to construct two or more gear sets. Then redaction ration can be
calculated by formulas:

Ration = GearSet1 x GearSet2

sizeOfSprocket1
𝐺𝑒𝑎𝑟𝑆𝑒𝑡1 =
sizeOfsprocket2

sizeOfSprocket3
𝐺𝑒𝑎𝑟𝑆𝑒𝑡2 =
sizeOfsprocket4

The final prototype of a gearbox module can be seen in Figure 8.

Figure 8: Custom gearbox module

27
 Sprockets are usually named starting from driver to driven sprocket. For calculation of the ratio
can be used size of the sprocket or number of teeth. The current setup guarantees a reduction ratio
about 3 times and an increase of torque of the same amount.

Complimenting AGV with a gear system will affect its chassis as the motor needs to be displaced
from ground level. To attach the motor and gear system needs to be created four extra mounts and
wheels have to be supplied with sprockets. It is recommended to acquire sprockets with service
holes because their material usually is hardened and will require special tools to drill extra holes.
The final chassis setup can be seen in Figure 9.

Figure 9: Suspension with chassis assembly

5.6 Motor Controller

Mostly brushless motors consist of 3 phases. Though application they require to use of a brushless
motor controller (BMC). A BMC will trigger the correct phase based on encoder reding to guarantee
the correct rotation of the motor. The selection of BMC is an important step of the project because it
has to be compatible with battery power and brushless motor specifications. BMCs differ in terms of
implementation and I/O options. Most of BMC allows analog input to execute functions of the
controller. Though, some devices allow serial bus communion.

Thus, the choice of BMC mostly depends on the requirements and availability of devices in a
particular case. Options of BMC can be used within the project presented in Table 2. Brushless motor
controllers.

28
 Table 2. Brushless motor controllers

Name Firmware I/Os Price

Hoverboard controller Encrypted, requires If based on STM32 10-50USD

revision support serial data
communication,
analog I/Os

Universal e-bike Encrypted, requires If based on STM32 10-50USD

controller revision support serial data
communication,
analog I/Os

Odrive Unlocked, requires Serial data 110USD

revision, opensource communication,
examples are available analog, and digital
I/Os can control two
motors

Maxon 1-Q-EC Locked, does not Analog I/Os 250USD

Amplifier DEC 50/5 require revision,
functions are
controlled with a
physical switch

Although an Odrive controller looks more appropriate for this project but based on availability option
and features array the Maxon motor controller was selected for prototype implementation because of
its industrial design and “ready to use” implementation. This controller has several analog and digital
inputs and outputs e.g. enable/disable, direction, brake, speed, and AUX. According to the datasheet,
this controller typically does not need special EMC and EMI shielding though the final product
(controller, motors, power source) does.

29
The benefits of Maxon 1-Q-EC Amplifier DEC 50/5

 It offers speed control, current control, or open-loop speed control. This variety of control
functions will benefit in the future application of the ROS controller.
 The controller’s inputs are protected from continuous overvoltage up to 50v.
 The protective function will stop the motor movement if the drive shaft is blocked for longer
than 1.5s.
 The brake function can be connected to an external safety device e.g LIDAR or emergency
stop button to guaranty the safety stop of a mobile robot.

The disadvantages of such a choice are:

 This model of the controller does not have a CAN interface so another device has to be used
to send a voltage signal to the controller's inputs e.g PLC or any other microcontroller.
 The brake function is deactivated when input is not wired or the applied voltage is greater than
2.4 volts, this causes unwanted behavior especially with Arduino. While the Arduino board is
at boot state a motor will start rotating.

The choice of the Maxon controller assumes to use the device which can produce analog or digital
outputs to trigger the execution of functions of the controller and extract encoder data. Brushless
motors usually are equipped with quite precise encoder sensors that are required for the controller to
operate. That means that signal produced by the encoder can be monitor by any external device with
analog input. In the selected motor 30 magnetic poles are connected in 3 outputs. To receive quite
detailed odometry data, two outputs are enough. Also, it’s important to ensure that all signals are
registered by the monitoring device. For that reason, the monitoring device has to interrupt the scan if
the input is registered.

The device which can accomplish this purpose can be found in the Arduino family e.g. Arduino Mega.
Some PLCs have this function as well. Thus, an appropriate monitoring device must carry two or more
(depends on the level of precision required by the application) interrupt ports and some of the
communication ports e.g. serial or CAN bus.

In this project, Arduino Mega is selected as a monitoring device due to its wide connectivity options.
Generally, Arduino is positioned on the market as a microcontroller board. It supports serial bus
communication and other logical features. What is significant it consists of several inputs and outputs

30
ports that can be configured for digital and analog signals as well as an interrupt signal. This device
can be configured to act as a ROS unite which simplifies its integration to ROS infrastructure. On the
Arduino Mega board pins, 1,2,18,19,20,21 can be configured as interrupt though can be set up to read
the encoder data. This data can be converted to odometer readings as well as indicate the direction of
the movement. Arduino offers several ways to register interrupt signal:

 HIGH – smallest precision

 CHANGE – middle precision
 RISING- highest precession.

The direction is calculated by comparing the sequence of the signals on each motor. The minimal
setup requires one interrupt port and one input port per motor. In case if high precision of encoder
data is required by an application must be used a higher number of interrupt ports. In the worst case,
a higher number of interrupt ports or complicated interrupt routing might affect the performance of
the board.

5.7 Computing unit

The executions of localization, navigation, object recognition require more computing power than can
be offered by a microcontroller or PLC. Furthermore, the ROS framework would require a full-size
OS for stable performance. The other constraints in choosing a computing unite are its portability and
power consumption, as the device is to be located on a mobile base. Thus, to maintain a balance
between computing power and energy consumption the mini-computers might be one of the best
options for a choice of computing unit for this project. Some of the most suitable minicomputers are
listed in Table 3 Minicomputers.

Table 3 Minicomputers

Name Operation ROS Industrial GPU Price USD

System Compatible Design

Jetson Nano Ubuntu 18.04 Yes No Yes 104

B01

31
 Raspberry PI Raspbian Yes No No 73
4
Ubuntu Mate
18.04

PR100102 Raspbian Yes Yes No 305

Jetson TX2i Linux Yes Yes Yes 1260

MIC-710AI Linux Yes Yes Yes

MIC-710AIX
MIC-720AI
MIC-730AI

The PR100102 module can be used in several projects except for the projects which require high
computing power e.g. image, sound recognition. The pc is equipped with certain protection for an
industrial environment. Jetson TX2i might be the best option but its price cannot be used in this
project. It doubles the performance of Jetson Nano according to specifications and is implemented in
industrial design. MIC devices from Advantech are the same solutions from Nvidia wrap in a
protective case for an industrial environment. The disadvantage of these devices might be an outdated
operating system and higher price e.g. MIC-720AI is supplied with Ubuntu 16.04. The use of these
devices requires further investigation.

The Jetson Nano B01 was chosen as the main computing unite because of its decent performance and
lower cost. According to the user guide of Jetson Nano developers kit, it complies with:

- Electromagnetic Compatibility Directive 2014/30/EU

- Low Voltage Directive 2014/35/EU
- RoHS Directive 2011/65/EU.

The device is CE marked for the European Union market and FCC marked for retailing in the United
States. Furthermore, the Jetson Nano module is equipped with 128 CUDA cores which can be used
for image and voice recognition projects. It is usually used with a caring board which is equipped with
general-purpose input-output (GPIO) pins, four USB type 3 ports display and HDMI ports, etc. A
detailed list of features can be found on NVidia's web page.

32
The system which is used for this computer is Ubuntu 18.04 LTS which offers a variety of packages
with ARM support. The system is run from an SD card, but the best performance level is achieved
with the use of an external SSD drive which is plugged into a USB type 3 port. In our experience, SD
card performance was not reliable and data often got corrupted.

5.8 Sensors and other components

The use of SLAM algorithms requires input from a LIDAR. LIDARs utilize light to send and receive
a reflection signal from the object. Therefore, this technology is fast and precise and can work in any
lighting condition as it does not require an external light source. LIDARs allow to generate 2d or 3d
map of the environment, thus, it is often used in solution which requires automated guiding. (Farzin
Amzajerdian, 2011) The implementation which benefits from this technology can be seen in space,
industrial and consumer fields.

The industrial solutions typically require more financial investments but tend to be more reliable.
Also, the same type of device can be procured with lower resource utilization. A good example is
Rplidar A1 from Slamtec. This sensor offers a bigger operational distance of 12M and is sold at a
significantly lower price. Thus this sensor is chosen to be used as an input for Gmapping algorithm.

33
6 Algorithm and software
This section describes the software development process of a ROS project. The section includes an
overview of the software, setup of the main computing unit, URDF file development, hardware
interface development, installation and usage of ROS Control, Gmapping, and Navigation algorithms.

6.1 Overview of required software

Nowadays, it is hard to find other pieces of software for robotics that would be contributed by others
as much as the ROS framework. That means the framework can offer a lot of generic software and
algorithms which are critical for the performance of a robot. Thus, ROS was selected as the main
framework for this work.

ROS framework consists of packages and “roscore” module which manages connections between
nodes through topics. Topics can be compared with a database that is continuously populated with
data and nodes are functions that perform certain tasks. The packages can be viewed as modules they
can be custom written or offered by the community. ROS community mostly uses GitHub to host its
packages.

Typically, ROS packages share the following structure:

 include/package_name: this folder contains C++headers

 msg/: this containing Message (msg) types
 src/package_name/: this folder contains source files, especially Python source that are
exported to other packages.
 srv/: this folder containing Service (SRV) types
 Config/: this folder contains (YAML) type files used for configuration of the package or script
 Launch/: this folder contains (launch) type file which uses for automated execution of the
modules
 scripts/: this folder contains executable scripts
 CMakeLists.txt: CMake build file (see catkin/CMakeLists.txt)
 package.xml: Package catkin/package.xml.

34
 A package can be created with the command cantkin_create_pkg (packageName) (dependencies)
but in many applications, a user of the framework might not need to create a package but instead
to reuse somebodies' work. After creating or cloning the packages or any changes in the C++ code
user must run the catkin_make command which will compile all the changed packages into source
code.

Linux environment supports two ways of installation of existing packages: git clone <web address
of git repository> or apt-get install ros-<name of ROS distribution>-<name of the package>. The
preferable method is to use a version of the package from the repository if no changes need to be
made into source code.

The process of configuring a custom robot will require the following packages:

 Navigation
 Gmapping
 Ros_control
 Hardware_interface
 python_serial
 Rplidar.

Also ROS native packages like:

 Gazebo
 Rviz
 Rqt_tools(rqt_gui, rqt_graph).

6.2 Jetson Nano setup and ROS installation

The jetson nano embedded computer is supplied without any installation system. As many others
embedded computer, there is no ROM located on its board instead, operational system and all other
data are stored on SD card which is then inserted into the board. Thus, the first step is to flash the
operating system onto the SD card and install it. The version of the jetpack (operation system for
Nvidia devices) is chosen r32.3.1. The process of preparing the SD card and installation of the system
can be seen on the NVIDIA official web page (https://developer.nvidia.com/embedded/learn/get-
started-jetson-nano-devkit).

35
After installation and evaluating the performance of OS the ROS framework needs to be installed.
The best way to install the ROS framework onto jetson nano is to use the installation script from
JetsonHacks (https://www.jetsonhacks.com/2019/10/23/install-ros-on-jetson-nano/). The script will
install the framework and configure the catkin workspace. Later on, all the custom packages will be
located inside the catkin workspace folder.

Catkin workspace performs compiling of the packages written in C++ programming language with
catkin_make command. This command is equal to the installation command in ROS1. In ROS2
packages have to be additionally installed in the system. After every execution of the “catkin_make”
command, it is recommended to source the bash file from the dev folder. This action will allow the
ROS system to know about newly installed packages.

To test the installation process the “roscore” needs to be started. If the ROS master starts well the
installation process is successful. If an architecture of the system assumes a multifunctional machine
setup the bash file needs to be edited where the IP address of the master and slave machines have to
be updated manually.

6.3 The URDF file development

The URDF file is an XML file that specifies a description of the robot which is used by the different
simulators to create a virtual model of a robot. The URDF files come in two forms: normal URDF and
xacro macros. Both types are usually parsed with no problems by different simulators as well as by
Rviz visualization tool. The xacro macros file allows a significantly simplify robot description. The
example of the file can be used from any skeed or differential drive robot with an update of geometry
shapes.

After development, the URDF or xacro file of the robot can be evaluated in Rviz or gazebo simulator.
The detailed tutorial of the development process of the URDF file can be found on the Roswiki
webpage. This work has used the Robot arm 6 DOF project by Parambeer Singh Negi as a starting
point for developing URDF files (https://github.com/parambeernegi/robot_arm_ros.git).

6.4 ROS Control

Ros_control package is a collection of controllers that are used to control a robot. Out of a variety of
controllers for this project, diff_drive is most relevant. This controller can manage motion two- and

36
four-wheels robot. This setup matches the physical representation of the robot which is designed in
the section above. The command flow of ROS control can be seen in Figure 10 (S. Chitta, 2017).

Figure 10: Ros control dataflow (S. Chitta, 2017)

ROS Control package works with Controller Manager which knows about robots' assets and can
switch controllers on demand. There are several types of controllers offered by ros_control packages:
effort, joint states, position, velocity, joint trajectory, differential drive, etc. The choice of controller
depends on the type and purpose of controlled equipment. To operate the controller needs to know
about the hardware interface.

37
The current application is quite limiting the choice of controllers as the navigation stack works with a
differential drive controller. The “diff_drive” controller will be selected as the main controller for
controlling the AGV. The controller out of the box can offer PID control module and transpose robots’
motion to the motion of the wheel. It expects angular and linear speed command of the base and
transposes it to the angular speed of the wheels. The command goes to hardware_interface which
communicates to the robots’ hardware directly.

To configure diff_drive controller is used YAML type file where are defined radius of the wheels,
separation from the base, name of the joints, and quaternion. A template of the “.yaml” file can be
found on the controllers’ info page of the GitHub repository. The file needs to be loaded to the param
server before the controller execution. The best way to load the .yaml file and execute the controller
in the ROS environment is to use the launch type file. Launch type files can consist of several nodes’
executables and are used for automation of the tasks.

6.5 Hardware interface

The hardware interface is a piece of software where methods of communicating with the robot are
specified. The main part of the hardware interface is a control loop that executes read and write
functions. The read function takes input from the robots’ hardware, the write function sends a
command to the robots’ hardware. The methods of control of the robot’s hardware are unique and
usually custom for every robot, that is why this part of the code must be modified to suit the project.
In our case Arduino module can be configured as a ROS node and all communication can be done
through the topics. This fact allows a much more simple and more general implementation of the
hardware interface. Although there are some limits of the bandwidth of rosserial described by (Andre
Araujo, 2013), the current robot configuration is considered within the limits.

For the starting point of developing a custom hardware interface in the ROS framework, can be used
ros_control_boilerplate from the PickNikRobotics. This approach will speed up the development
process as the hardware interface does not have to be developed from scratch.

One of the biggest advantages of “ros_control_boilerplate” package is the implemented joint position
interface of type velocity. This is the major requirement for the operation of diff_drive controller. The
bonus part of the supplied example for “rrobot” with config and launch files. Also, this software
package consists of tools that will take care of renaming code samples to any given name of a custom
robot but this process can be performed manually.

38
The only part where changes have to be implemented is the main control loop and be more concrete
“read” and “write” function. The “read” function assumes the process of getting information from the
robot and the “write” function will generate a command to the robot’s hardware. In the current setup,
the per which will receive the command is the Arduino microcontroller.

Generally, the “read” and “write” function expects low-level protocol use such as serial or CAN bus
protocol. In the current setup as Arduino configured as ROS node, it is enough to publish command
to the ROS topic called “commander” which will be read by Arduino.

The “write” function

For this purpose, the “write” function has to be configured to publish the command. The command
which is expected by Arduino microcontroller is Int32MultiArray, where zero elements are
responsible for the left wheel and the first element to the right wheel respectively. The command is a
type of velocity command for each wheel in rad/s which has to be transformed into a PWM signal
with the formula:

255
𝑃𝑊𝑀_𝑐𝑜𝑚𝑚𝑎𝑛𝑑 = 𝑗𝑜𝑖𝑛𝑡_𝑣𝑒𝑙𝑜𝑐𝑖𝑡𝑦_𝑐𝑜𝑚𝑚𝑎𝑛𝑑_[𝑗𝑜𝑖𝑛𝑡_𝑖𝑑] ∗
max⁡_motor_angular_speed⁡

The rest of the calculation including PID values and transmission of the motor’s angular speed to the
robot’s angular and linear speed will be done automatically by diff_drive controller.

The “read” function

The “read” function setup is a bit more challenging as after subscription to a topic a ROS node will
be executed when information on the topic is published with a callback. Also, a subscription has to
happen in the main loop of the node. In the current setup, the Arduino microcontroller is configured
to publish two topics “/lfwheel” and “/rfwheel”. Information is published with the desire rate for each
topic. It is wise to remember that increment of the frequency might affect the performance of rosserial
thus, must be set as low as possible for the stable performance of the system.

The joint_position defined in radians thus, ticks from encoder must be converted to radians with the
formula:

𝑑𝑎𝑡𝑎_𝑓𝑟𝑜𝑚_𝑒𝑛𝑐𝑜𝑢𝑑𝑒𝑟 ∗ 𝑡𝑖𝑐𝑘_𝑝𝑒𝑟_𝑟𝑒𝑣𝑜𝑙𝑢𝑡𝑖𝑜𝑛
𝑗𝑜𝑖𝑛𝑡_𝑝𝑜𝑠𝑖𝑡𝑖𝑜𝑛_[𝑗𝑜𝑖𝑛𝑡_𝑖𝑑] =
2𝜋

39
6.6 Rosserial node and Arduino setup

The rosserial is a set of tools for communication with devices that support serial communication. Its
usage in the ROS framework is straightforward. The library needs to be installed on the device
connected to the Arduino with the following command:

$ git clone https://github.com/ros-drivers/rosserial.git

$ catkin_make

or

$ sudo apt-get install ros-indigo-rosserial-arduino

$ sudo apt-get install ros-indigo-rosserial.

Arduino IDE has to be configured with the rosserial library as well. The default installation offers a
decent amount of data types. In this case, if default data types are sufficient for the project it is enough
to copy ros_lib from the rosserial repository on GitHub (https://github.com/ros-
drivers/rosserial/tree/noetic-devel/rosserial_arduino/src/ros_lib). Otherwise, libraries can be
generated to include custom datatypes. To run rosserial it's enough to make the device accessible with
chmod command or edit user rules and add the user to the dialup group. After solving the permissions
rosrun the node.

chmod 666 /dev/ttyACM0

rosrun rosserial_python serial_node.py /dev/ttyACM0

It is wise to mention that chmod 666 is not potentially safe and can be used only for testing purposes.
After the node is run should be seen ROS_INFO messages about which topics have been subscribed
or published. It is possible to subscribe or publish topics simultaneously. The only limit is the
publication rate. In case if some faster device (e.g. PS4 wireless controller) is publishing to nodes that
are subscribed by Arduino, rosserial will demonstrates malfunctioning performance.

40
6.7 Gmapping

At the time of writing Gmapping node is the most popular and reliable SLAM algorithm. It requires
input from a laser scanner or point cloud to be published in the system. The manufacture of SLAMTEC
Rplidar A1 which is used in this project offers ROS node for publishing laser information. It can be
download from the manufactures website and installed into the system with the catkin_make
command. The permission for this device has to be also solved similar to the Arduino device. After
installation and execution of the node /scan topic should be populated with light detection and ranging
sensor (LIDAR) readings. The result of the operation of LIDAR should be seen in Rviz. It is very
important to position the scanner the same way as it is positioned in real life. To change transform
LIDAR messages into a correct position can be used robot_setup_tf package from navigation tutorials
(https://github.com/ros-planning/navigation_tutorials.git). The broadcaster node must be configured
with the correct position of the scanner in the quaternion coordinate system:

tf::Quaternion(x, y, z, w)

where w value is usually set to 1 indicating no rotation.

After /odom /tf and /scan topics have been configured correctly, the Gmapping library has to be
installed:

apt install ros-melodic-gmapping

To run the gmapping node needs to be created a launch file. An example of a launch file can be
acquired from the gmapping GitHub page ( https://github.com/ros-
perception/slam_gmapping/blob/melodic-devel/gmapping/launch/slam_gmapping_pr2.launch).

The main parameters which must be set to use gmapping node are:

<arg name="scan_topic" default="/scan" />

/scan is the name of the topic where published informtain from the sensor

<arg name="base_frame" default="chassis"/>

base_frame is the name of a base link

<arg name="odom_frame" default="odom"/>

41
odom is a name of odom frame

After launching the node with “roslaunch” command the system will be populated with a /map topic.
The best way to evaluate accuracy of a map is to display it in rviz.

6.8 Navigation stack

The navigation stack is distributed within the package called navigation. It manages planning. The
command flow of this module can be seen in Figure 11 (Marder-Eppstein, 2020).

Figure 11: Navigation stack dataflow (Marder-Eppstein, 2020)

The navigation stack is a collation of packages that aim to identify obstacles and construct the path of
the robot. The packages are split depending on the purpose, the minimum configuration of the
navigation stack is:

- Global costmap. The purpose of the global costmap is to identify obstacles in the global frame
from the provided map. The obstacles are going to affect the global path planning process.
- Local costmap. The local cosmap package inserts obstacles into the local costmap from the
input source e.g. LIDAR. The obstacle from the local costmap will affect the performance of
the local planner.
- Global planner. The purpose of a global planner to construct a global path for the robot from
its current position to the goal.

42
 - Local planner. The purpose of a local planner to construct the local path from the current
position to the desired point along the global path.

Requirements:

- The robot must be running ROS.

- The robot must be equipped with a differential or holonomic type of chassis.
- The robot must be equipped with a laser that is mounted horizontally.
- The robot must be configured to accept velocity commands.

Limitations: the navigation stack was developed on the square robot therefore navigation of the big
rectangular robot might be challenging in the closed space environment.

The navigation package requires to transform(/tf) and odometry (odom) messages. It also needs the
goal which can be generated through Rviz and the map server with the loaded map. Additionally, it
can use sensor data such as LaserScan(2d) or PointCloud(3d). After computing the path of a robot, it
can command the controller with the topic “/cmd_vel“.

To start working with the navigation stack the package has to be installed or cloned from the
repository. For the starting point, it is suggested to reuse the example configuration “.yaml” files and
launch file. After setting all the parameters global and local costmaps can be viewed in Rviz, together
with a global and local path. The goal is given to the robot through the Rviz as well by the goal
definition tool.

The navigation package needs the map to operate. The map can be provided by the Gmapping
algorithm or with the map server and AMCL localization module. In the first case, the robot will start
in an unknown environment and explore it while updating the map. In the second case, the AMCL
module will need a position estimation of the robot, and while the robot moves the AMCL module
will reduce an error between real and estimated position.

43
7 Evaluation
This section includes description of several tests which are used for evaluation of the prototype of an
AGV. It includes towing test, cartography test, and navigation tests. The tests are performed in control
environment of the IRMA project.

7.1 Towing test

The first towing test is organized in a controlled environment. During the test, AGV is hocked to the
scale and the scale is hocked to the trolley loaded with the engine block. The setup of the towing test
can be seen in Figure 12.

Figure 12: Towing test setup

The force needed to overcome the friction of a trolley is measured as 120N. The friction of the caster
wheel is 0.03. Then the weight of the trolley with the engine can be calculated by the formula:

44
 𝐹
𝑚=
𝜇

F - the force which needs to be overcome to start the movement

µ - the friction coefficient of the wheels.

The calculated weight of the trolley with the engine is 4000N. During the towing test has been noticed
some friction problems due to the low weight of AGV and the surface of the floor.

The second test was set up so, that the caster wheels of the trolley were blocked. The purpose of the
second test was to evaluate the maximum towing capacity of the device. The AGV has shown 200N
towing force when unloaded and 300N loaded with 1000N weight. During the second towing test has
been noticed similar problems with friction, when motors were not stacked but instead kept spinning.

The third test was designed to measure stopping distance. The AGV was attached to the engine with
a hard link. The test has shown that the braking distance of a powertrain was within 10 cm after
decelerating from a maximum speed of 0.7 m/s. During the test, the friction problem was not that
significant.

7.2 Cartography test

The grid mapping algorithm from the package of Gmapping was used for building a map of the
environment. ROS environment allows using of Gmapping in virtual simulator e.g. Gazebo as
“hokuyo_scaner” or a real environment with rplidar.

The success of the cartography test in a virtual environment mostly depends on the coherence of
URDF model settings of the diff_drive controller. After configuring controller settings Gmapping
algorithm has shown a high score and the map was pretty accurate.

The cartography test of the real environment depends not only configuration of the controller but also
on the accuracy of input sensors. In the case of this project, the odometry source is received from
encoders of the motors, and laser data is received from rplidar. The map of the environment can be
seen in Figure 13.

45
 Figure 13: Test objects on the map

Figure 14: Map of the test environment

The map can be edited to avoid the robot from entering non-desired zones. The thicker lines which
can be seen in Figure 14 are a good example of how certain areas can be excluded from the robot path.
To evaluate the accuracy of the map will be viewed two objects from the testing environment: the

46
robot controller and engine block on the trolley. Objects can be viewed in Figure 15.

Figure 15: Test objects for cartography test

Both objects are measured with a ruler. After they are measured on the map with the Rviz measuring
tool. The result of the measurement can be seen in Table 4: Comparison of the measured objects.

Table 4: Comparison of the measured objects

Real measurement in Virtual measurement in Difference in

Name of the
meters meters meters
object
0,445 0,508 0,063
Robot controller
0.960 0.994 0,034
Engine block

7.3 Navigation test

Navigation tests are performed in the test environment with several different obstacles to simulate
the layout of the shop floor. Although, simulations have shown great results while performing
navigation in Gazebo, with or without prebuild map. The test in the actual environment was
performed by using a pre-built map. During the test, the goal was set with the goal tool of Rviz, and
the process of navigation was the view in Rviz. Special interest during the test was given to general

47
path guidance (global_path), local and global costmaps. The process of navigation can be seen in
Figure 16.

Figure 16: An example of costmap

The colored markings on the map are representing an array of obstacles that are registered by the
navigation algorithm. The actual obstacle marks are displayed inside of colored marks. Furthermore,
some areas around the obstacle are marked as not acceptable for the path planner, to avoid collisions.

During the navigation test were used two algorithms:

 TrajectoryPlannerROS
 DWA local planner.

The navigation test of the robot was to drive to the position within the UR10 robot range and return
to the approximately same position as the starting point. Due to the characteristics of the test track the

48
preferred behavior for the robot was forward and backward movement. Although, this kind of
behavior was not possible to demonstrate with the default local planner.

The DWA local planner was able to navigate the robot in both directions by setting minimal velocity
to a negative value. The planner demonstrated good performance in a virtual environment but in an
actual environment when minimum velocity command was less than minimum robot velocity the
DWA planner was not able to reach the goal without executing recovery behavior.

The recovery behavior is a set of instruction tend to localize or find an alternative path to a goal. While
executing recovery behavior robot will rotate in one place several times despite obstacle presence.
The recovery behavior is not potentially safe and can be disabled in local planner settings.

49
8 Discussion
The outcome of this thesis project is a fully functional prototype of an AGV which accepts a load of
400kg and supports autonomous navigation. One of the most important questions of this project is
how to scale the current prototype for industrial use. This opens not only the reproduction issues but
also compliance with safety regulations and standards. To answer these questions project requires a
more in-depth investigation of safety rules which affect the category of such mobile devices. Despite
the prototype demonstrates strong functional performance and can move to the desired position
autonomously, the CE certification might be challenging. The main challenges are:

- Motors are parts of another device and require EMC recertification, the Arduino board lacks a
CE compliance certificate but very likely to pass the EMC test in compliance with EN 62061.
- A safety assessment must be done to follow the norms of the Machine Directive and its
subsection B (ISO 12100:2010) and C (ISO 3691-4:2020).

The prototype is designed to operate in a controlled environment thus, these challenges are outside of
the scope of this work. But to make this device accessible by SMEs, a separate study has to be
conducted. Only after procuring the required certification, the prototype can be converted into the
product.

Moreover, on example of this project can be seen how the open-source concept is encouraging the
development of new technology. During the project, we could utilize a lot of the algorithms which are
implemented by other researchers. It gives a big advantage when technology does not have to be
developed from the start. Of course, redistribution of the algorithms must meet certain conditions
defined by the 3-Clause BSD License.

Although the purpose of the research was to create a prototype of AGV, however within the research
process it has become clear that the prototype of AGV can be converted into the mobile base for the
industrial robot. The ROS framework includes support for some UR robots and due to the
implemented localization technique, the prototype can be complemented with a robotic arm or any
other manipulator to convert AGV into a mobile robotic station. Indeed, pick and place or any
operations which require a high level of precision will need additional input sensors such as depth
camera, Kinect, or web camera. Also, the installation of an industrial robot will require to comply

50
with the power source requirements of UR robots. The conceptual setup of the manipulator on the
mobile base can be seen in Figure 17.

Figure 17: Conceptual setup of the mobile robotic station

51
9 Conclusion and future work
The objectives of this work were to investigate the technology which is necessary to create a prototype
of low-cost AGV; to create a prototype; evaluate the performance of the prototype. This section
describes a more detailed evaluation of the objectives and results.

9.1 Objectives verification

In this section of the work, objectives are compared to the acquired results. Each objective is related
to a particular section of the work.

Investigate the required technology for the construction of a prototype of the AGV

The objective is presented in the process of building a theoretical framework. The key technology
required is reviewed and proposed for use in this work: electronic parts, input sensors, ROS
framework, and required packages. This objective is presented in chapters 2 and 3 of this work.

Create a low-cost (under 50 000SEK) and flexible prototype of the AGV

The parts and examples of their combination are described in chapter 5 of this work. The mechanical
structure is presented in form of images and 3D models. This chapter resulted in the creation of a
physical prototype.

Chapter 6 of this work demonstrates an example of a ROS framework implementation process. This
part of the development process resulted in creating a hardware interface software that can be reused
by the other researchers in case of a similar setup. Also acknowledged the necessary packages and an
example of their configuration for the operation of an autonomous mobile robot. The major outcome
phase resulted in the installation and configuration of OS, ROS, hardware_interface, rosserial,
ros_control, gmapping, navigation, and other packages.

After investigation of the possibility of creating a prototype of an AGV and actual implementation,
we can conclude that a powerful and flexible solution can be created with a budget limit of 50 000
SEK. Furthermore, according to the expense report in Appendix 1 the development of the current
prototype has utilized 20595 SEK that is 41 percent of the requested budget.

52
Also, the prototype demonstrates better performance than required by specifications as it can drag
objects which are heavier than 100kg and stop within 10cm breaking distance. The device can generate
a map of the environment thus, performing automated navigation.

Verify the performance of a prototype with functional tests

The verification process is described in section 7 of this work. During this phase of the work, different
tests were conducted to verify the performance of the prototype: towing test, cartography test, and
navigation test. The tests verify the ability of AGV to produce a towing force of 300 N, map an
environment, and perform autonomous navigation.

9.2 The implication of the work.

The work has resulted in the creation of low-cost and flexible AGV thus, it can be one step towards
more affordable automation technologies that can be used by SMEs and bigger companies to rearrange
their workflow and deliver more affordable products. Also, the work demonstrates the successful use
of the ROS framework and open-source software which can encourage other researchers to employ
the framework and complement it with their knowledge.

The prototype which is created can be used for additional experiments on the evaluation and
development of various algorithms. For example, further plans are the evaluation of Rtap algorithm
and integration of the device with a cloud service.

9.3 Future studies

Based on the discussion section, more detailed research needs to be done in the safety field on how to
harmonize the prototype with safety requirements without elevating budget specifications. Also, the
current prototype needs to be equipped with a vision system that will benefit the safety issue and
increase flexibility.

During the research and development process, we have found that the current solution can be used not
only as an AGV but also as a mobile platform for a robot manipulator. This fact can facilitate the
development of mobile robotic stations which are required by Industry 4.0. However further
investigation needs to be conducted in order to facilitate the usage of AGV as a mobile robotic station
based on the requirements of Industry 4.0.

53
Moreover, we have reviewed in depth the process of developing a custom mobile robot within the
ROS framework. During the research, we were able to reuse many parts of the robot software from
other projects which facilitated a faster development process. Furthermore, the adaptation of the
hardware interface can be used by other developers in projects with a similar setup and the Arduino
microcontroller. Therefore, future collaboration and cooperation between projects and scientists in
this field could improve and accelerate the process of creation AGVs accessible for SMEs.

Additionally, a usability study needs to be performed on the methods of interaction of a human with
a mobile robot. This study can result in developing methods of easy goal definition which lack most
of the AGVs and mobile robots.

Furthermore, the system of a prototype needs to be integrated with the control system of the IRMA
project. This will allow the AGV to accept goal definition through the cloud thus, more advanced
algorithms on optimization and automation can be used.

Even though research on AGV has been done since 1950th, still many questions remain uncovered.
Also, the constant technology change requires continuous improvement on structure, methods of
navigation, localization, flexibility to bring automated guided vehicles to the bigger mass.

54
References
Alexandra Markis, M. P. D. K. M. R. V. S. M. B., 2019. Safety of Mobile Robot Systems in Industrial
Applications, s.l.: ResearchGate.

Andre Araujo, D. P. M. S. C. R. P. R., 2013. Integrating Arduino-Based Educational Mobile Robots

in ROS, s.l.: ResearchGate.

Anon., 2017. ROS.org | History. [Online] Available at: https://www.ros.org/history/

[Accessed 25 10 2020].

Bojarski, M. et al., 2016. End to End Learning for Self-Driving Cars, Holmdel: NVIDIA Corporation.

Cawood, G. J. & Gorlach, I. A., 2015. Navigation and locomotion of a low-cost Automated Guided
Cart. s.l., Proceedings of the 2015 Pattern Recognition Association of South Africa and Robotics and
Mechatronics International Conference, PRASA-RobMech.

COBOTS, n.d. Begagnat - AMR. [Online] Available at: https://cobots.se/produkt-

kategori/begagnat/begagnat-amr/
[Accessed 21 11 2020].

Colosi, M. et al., 2020. Plug-and-Play SLAM: A Unified SLAM Architecture for Modularity and Ease
of Use, s.l.: arXiv.

European Union, 2012. Directive 2012/19/EU of the European Parlament and of the Council of 4 July
2012 on waste electrical and electronic equipment (WEEE). Oficial Journal of the European Union,
pp. 88-110.

Farzin Amzajerdian, D. P. L. P. G. H. R., 2011. Lidar Systems for Precision Navigation and Safe
Landing on Planetary Bodies, Hampton: NASA Langley Research Center.

Hammond, G., 1985. AGVS AT Work. Springer-Verland Berlin Heidelberg New York Tokyo: IFS
(Puglications) Ltd, UK .

Hawkins, W. M., 2013. Automating Manufacturing Operations : The Penultimate Approach. New
York: Momentum Press.

55
Iversen, W., 2005. Laser Scanners for Obstacle Avoidance. [Online] Available at:
https://www.automationworld.com/products/control/news/13303092/laser-scanners-for-obstacle-
avoidance
[Accessed 1 10 2020].

Johan Alexandersson, O. N., 2017. Implementation of SLAM algorithms in a small-scale vehicle using
model-based development, s.l.: Linköpings universitet.

John Kerr, K. N., 2012. Robot operating systems: Bridging the gap between human and robot, s.l.:
ResearchGate.

Kelly, A., Nagy, B., Stager, D. & Unnikrishnan, R., 2007. An Infrastructure-Free Automated Guided
Vehicle Based on Computer Vision, s.l.: EEE Robotics & Automation Magazine.

Lentin, J., 2018. Learning Robotics Using Python : Design, Simulate, Program, and Prototype an
Autonomous Mobile Robot Using ROS, OpenCV, PCL, and Python, 2nd Edition. eBook: Packt
Publishing.

Marder-Eppstein, E., 2020. Navigation. [Online] Available at: http://wiki.ros.org/navigation

[Accessed 24 10 2020].

Milad Ramezani, G. T. E. I. a. M. F., 2020. Online LiDAR-SLAM for Legged Robots with Robust
Registration and Deep-Learned Loop Closure, s.l.: s.n.

Oates, B. J., 2012. Researching Information Systems and Computing. s.l.:SAGE Publications Ltd.

Peter Eriksson, I. L., 2020. The Global Goals and the 2030 Agenda for Sustainable Development.
[Online]
Available at: https://www.government.se/government-policy/the-global-goals-and-the-2030-Agenda-
for-sustainable-development/
[Accessed 24 10 2020].

Reyes, D., 2015. Sustainable Development: Processes, Challenges and Prospects. New York: Nova
Science Publishers, Inc..

Richard Norcross, R. B. J. F., 2015. Automated Guided Vehicle Bumper Test Method Development,
s.l.: Intelligent Systems Division, Engineering Laboratory.

56
S. Chitta, E. M.-E. W. M. V. P. A. R. T. J. B. D. C. B. M. G. R. M. L. a. E. F. P., 2017. ros_control: A
generic and simple control framework for ROS. The Journal of Open Source Software.

Siegwart Roland, N. I. R., 2004. Introduction to Autonomous Mobile Robots. Cambridge: Mass : MIT
Press.

Sumegh Pramod Thale, M. M. P. P. V. T. P. k., 2020. ROS based SLAM implementation for
Autonomous. Navi Mumbai, Ramrao Adik Institute of Technology.

Vijay Vaishnavi, B. K. S. P., 2004. Desing sience research in information systems, s.l.: s.n.

Wohlin, C., 2014. Guidelines for Snowballing in Systematic Literature Studies and a Replication in
Software Engineering, Karlskrona: Blekinge Institute of Technology.

Zubrycki, I., 2014. Introducing modern robotics with ROS and Arduino, including case studies, s.l.:
ResearchGate.

57
Appendix A: The project expenses report

Equipment Quantity Retailor Price SEK

Hover Board 1 XXL 2499

Jetson Nano 1 Elfa 1329.0
Jetson Nano case 1 Digi-key 310
8265NGW with wifi antenna 1 HiTech 300
Wireless controller 1 Teknikdelar.se 548
Engine trolley stand with worm drive 1 Biltema 3040
Castor wheel 2 Biltema 180
Aluminum Profile 3 RS 684
Project Box 1 RS 520
Arduino Atmega 1 Elfa 379,14
DCDC nödstopp etc 1 Elfa 1785
Lidar 1 Elfa 2026,66
Flex cabel 1 Elfa 295
Motor controllers 2 6700

Total 20595,8

58