LOCALIZATION PROJECT, ROBOTICS NANODEGREE PROGRAM, UDACITY 1

Udacity Robotics Software Nanodegree:

Localization Project
Wisnu Prasetya Mulya

Abstract—This paper examines the implementation of AMCL and move base ROS packages and the parameters tuning of them to
navigate to a goal position. Two simulated robots are being the subjects of this paper: one whose properties are specified by Udacity
and one that is made personally by the author. The results show that with certain parameter values, both robots could navigate into the
goal position with the specified goal’s XY and yaw tolerance of 3%.

Index Terms—Robot, IEEEtran, Udacity, LATEX, Localization.

1 I NTRODUCTION The notion has given a birth to the subject of local-

ization in the robotics field. Localization is the process of
T HE primary task of this paper is to examine the im-
plementation of two ROS packages, the AMCL and the
move base, on the subject robots and to elaborate the role of
determining the current position and orientation of robots
by the means of filtering the errors resulting from natu-
each essential parameters for the packages to function and ral randomness and innate noises of the sensors. Several
how to fine tune them in order to successfully overcome the prominent localization algorithms have been discovered to
challenge of navigating the subject robots to a goal position tackle the challenge effectively, but in this paper, the author
and orientation, which is specified by Udacity. focuses only on the implementation of the Monte Carlo
There are two simulated robots that are the subject in this Localization (MCL) algorithm, since several parameters of
paper: the one constructed by following Udacity guideline, this algorithm can be adjusted according to the performance
which will be referred to as udacity-bot throughout the rest of the processing unit of the robots.
of the paper, and the one constructed personally by the Further, alongside the MCL implementation, a naviga-
author, which will be referred to as custom-bot throughout tion stack will be implemented as well in order to move
the rest of the paper. the robots towards a goals position specified by Udacity.
The parameters of the udacity-bot are tuned indepen- The navigation stack will move the robots’ base towards
dently, while the custom-bot adapts the working parameters the goal position and orientation, which would take into
from the udacity-bot and only differ in parameters pertain- consideration the robots’ odometry and sensors.
ing to its dimension. Also, several parameter specifications
for the udacity-bot are adapted from the ones illustrated 2.1 Kalman Filters
in the packages’ documentations and from the working
parameters in the work of Kaiyu Zheng [1]. Kalman Filters are localization algorithms which use Gaus-
AMCL and move base packages are used to perform sian distribution assumption in filtering noises from the
localization and navigation stack respectively and their im- inputs. Also, aside from assuming that the state variables
plementation in navigating the robots towards the goal posi- are normally distributed, it assumes that they are linear.
tion and orientation requires fine tuning of their parameters. It works in producing accurate approximations, since it
This is an arduous task without a proper understanding of assigns weights to the sensor inputs based on their standard
each parameter’s role and how to adjust them differently for errors (variance of the Gaussian distribution).
different robot. Choosing different values randomly for the Further, the drawbacks of only covering for normally
parameters and examining how each affects the localization distributed and linear states are improved in the Extended
and the navigation of the robot will take a considerable Kalman Filters. It works by performing the similar steps
amount of time. Therefore, an examination on this task as in the regular Kalman Filters, but it approximates the
becomes important, so that the results will guide for a quick non-linear states by using Taylor Series to approximate the
setup of the parameters of both packages. locally linear function of the states.

2 BACKGROUND 2.2 Particle Filters

The challenge in determining robots position and orien- Particle Filters, such as the MCL, are localization algorithms
tation is substantial, since first, the real world has innate which filter randomly generated particles in a given known
random properties, such as uneven ground and random air map by assigning Bayesian probabilities to each particle in
resistance, and second, the sensors installed on the robots determining how accurate their position and orientation are
have their own noises that would affect the accuracy of the with regards to the known map and the robot’s inputs of its
measurement data collected. surrounding.
LOCALIZATION PROJECT, ROBOTICS NANODEGREE PROGRAM, UDACITY 2

2.3 Comparison / Contrast TABLE 1: Udacity-bot Model Design

Even though both Kalman Filters and Particle Filters serve

Property Value
the same purpose, they differ in their performance based on Chassis
the assumptions about the states that are to be approximated Shape Box
and the capability of the processing unit of the robot. Ana- Dimension 0.4 x 0.2 x 0.1
Mass 15
lyzing their benefits and disadvantages is therefore crucial Caster Radius 0.05
in determining which algorithm to pick for the localization Caster mu 0
task and for future reference. Caster mu2 0
The followings are the characteristics of the Kalman Caster slip1 1.0
Caster slip2 1.0
Filters, including its benefits and disadvantages: Back Caster Position (X,Y,Z) -0.15, 0.0, -0.05
Front Caster Position (X,Y,Z) 0.15, 0.0, -0.05
• Assumes Gaussian distribution for the state variables Wheels
• More efficient than Particle Filters Shape Cylinder
• More complex in implementation than Particle Filters Length 0.05
Radius 0.1
• Memory and resolution cannot be controlled Mass 5
RPY 0.0, 1.5707, 1.5707
Also, below are the characteristics of the Particle Filters, Joint Type Continuous
including its benefits and disadvantages: Joint Axis Y
Joint Damping 1.0
• Assumes any distribution for the state variables Joint Friction 1.0
Left Wheel Joint Origin (X,Y,Z) 0.0, 0.15, 0.0
• More simple to be implemented than Kalman Filters Right Wheel Joint Origin (X,Y,Z) 0.0, -0.15, 0.0
• Memory and resolution can be controlled Camera
• Less efficient than Kalman Filters Shape Box
Dimension 0.5 x 0.5 x 0.5
Mass 0.1
Joint Type Fixed
3 S IMULATIONS Joint Origin (X,Y,Z) 0.2, 0.0 0.0
Hokuyo Rangefinder
The two robots that are being the subject in this paper are Shape Mesh File
built in simulation. Specific details regarding their models, Joint Type Fixed
packages used, and the parameters used in the AMCL Joint Origin (X,Y,Z) 0.15, 0.0, 0.0
Differential Drive Controller
and move base packages are elaborated in the following Update Rage 10
subsections. Wheel Separation 0.4
Further, the specification of the machine of which the Wheel Diameter 0.2
simulation is conducted is as follow: Torque 10

• Machine: Mid-2014 Macbook Pro Retina 13-inch with

macOS 10.13.3 3.1.2 Packages Used
• Virtual Machine Software: VMware Fusion Pro 10.1.1 There are two ROS packages used for this robot:
• Virtual Machine Image: Linux 4.8.0-58-generic
Ubuntu 16.04.2 LTS with 2 processor cores and 4MB • AMCL
memory • move base

3.1.3 Parameters
3.1 Benchmark Model The parameters of the packages are elaborated in Table 2.

3.2 Personal Model

(a) udacity-bot model (b) udacity-bot wireframe

Fig. 1: Udacity-bot Model (a) custom-bot model (b) custom-bot wireframe

Fig. 2: Custom-bot Model

The benchmark model of the robot whose configurations
are being specified by Udacity is called the udacity-bot in
The second robot model, which is made by the Author,
this paper. The udacity-bot has a box base, two wheels, two
is called the custom-bot in this paper. As shown in Figure 2,
casters, a camera, and a Hokuyo laser rangefinder.
the custom-bot has a cylinder base, two spherical wheels,
two casters, a camera, and a Hokuyo laser rangefinder.
3.1.1 Model design Thus, the custom-bot only differs in its base and wheels
The udacity-bot configurations is elaborated in Table 1. from the udacity-bot.
LOCALIZATION PROJECT, ROBOTICS NANODEGREE PROGRAM, UDACITY 3

TABLE 2: Udacity-bot Packages’ Parameters TABLE 3: Custom-bot Model Design

Property Value Property Value

AMCL Chassis
Odom Model Type diff-corrected Shape Cylinder
Minimum Particles 20 Radius 0.2
Maximum Particles 100 Length 0.1
Transform Tolerance 0.3 Mass 15
Laser Model Type likelihood field Caster Radius 0.05
laser z hit 0.95 Caster mu 0
laser z rand 0.05 Caster mu2 0
Odom alpha1 0.001 Caster slip1 1.0
Odom alpha2 0.001 Caster slip2 1.0
Odom alpha3 0.001 Back Caster Position (X,Y,Z) -0.1, 0.0, -0.05
Odom alpha4 0.001 Front Caster Position (X,Y,Z) 0.1, 0.0, -0.05
move base Wheels
Controller Frequency 5.0 Shape Sphere
Maximum X Velocity 1.0 Radius 0.05
Yaw Goal Tolerance 0.04 Mass 5
XY Goal Tolerance 0.03 RPY 0.0, 0.0, 0.0
Sim Time 4.0 Joint Type Continuous
Meter Scoring True Joint Axis Y
Path Distance Scale 2.0 Joint Damping 1.0
Obstacle Range 2.5 Joint Friction 1.0
Ray Trace Range 3.5 Left Wheel Joint Origin (X,Y,Z) 0.0, 0.1, -0.05
Transform Tolerance 0.3 Right Wheel Joint Origin (X,Y,Z) 0.0, -0.1, -0.05
Inflation Radius 1.75 Camera
Global & Local Update Frequency 5.0 Shape Box
Global & Local Publish Frequency 5.0 Dimension 0.5 x 0.5 x 0.5
Global & Local Resolution 0.02 Mass 0.1
Global Width & Height 5.0 Joint Type Fixed
Local Width & Height 1.0 Joint Origin (X,Y,Z) 0.2, 0.0 0.0
Hokuyo Rangefinder
Shape Mesh File
Joint Type Fixed
3.2.1 Model design Joint Origin (X,Y,Z) 0.15, 0.0, 0.1
Differential Drive Controller
The custom-bot configurations is elaborated in Table 3. Update Rage 10
Wheel Separation 0.2
3.2.2 Packages Used Wheel Diameter 0.1
Torque 10
Similar to the udacity-bot, there are two ROS packages used
for this robot:
• AMCL Also, when making a u-turn, the custom-bot is observed
• move base to have poorer performance in following the global path,
while the udacity-bot is observed to not deviate as much as
3.2.3 Parameters
the custom-bot.
The parameters of the packages are elaborated in Table 4.
4.1 Localization Results
4 R ESULTS 4.1.1 Udacity-bot
There are two measurements that are being observed: the The moment when the udacity-bot achieves the goal posi-
time for the localization to converged and the time for tion and orientation is portrayed in Figure 3.
the robot to get to the goal position and orientation. The
summary of the result is given under Table 5. 4.1.2 Custom-bot
The parameters of AMCL and move base for both The moment when the custom-bot achieves the goal posi-
robots are all the same, except for the footprint and tion and orientation is portrayed in Figure 4.
robot_radius where the udacity-bot has the former and
the custom-bot has the latter.
Another difference is the parameters applied 5 D ISCUSSION
to the differential drive controller plugin. For the The discussion of the results is divided into two sections:
wheelSeparation parameter, the udacity-bot is set to 0.4, the discussion regarding the parameters and the discussion
while the custom-bot is set to 0.2. For the wheelDiameter regarding the results observed.
parameter, the udacity-bot is set to 0.2, while the custom-bot Further, regarding the parameters, an independent tun-
is set to 0.1. ing is only conducted in the parameters for the udacity-bot,
The observed results show that the custom-bot appears while the custom-bot copies all of the parameters of udacity-
to be faster in getting to the goal position and also faster bot’s, except for the ones pertaining to its dimension. The
for its localization to converge. However, both of their custom-bot has similar parameters due to that they achieve
localization process seems to converge at the time when the a good job in navigating the custom-bot to the goal position
robot is making a u-turn. and orientation with no significant issue.
LOCALIZATION PROJECT, ROBOTICS NANODEGREE PROGRAM, UDACITY 4

TABLE 4: Custom-bot Packages’ Parameters

Property Value
AMCL
Odom Model Type diff-corrected
Minimum Particles 20
Maximum Particles 100
Transform Tolerance 0.3
Laser Model Type likelihood field
laser z hit 0.95
laser z rand 0.05
Odom alpha1 0.001
Odom alpha2 0.001
Odom alpha3 0.001
Odom alpha4 0.001
move base
Controller Frequency 5.0
Maximum X Velocity 1.0
Yaw Goal Tolerance 0.04
XY Goal Tolerance 0.03 (a) udacity-bot at goal
Sim Time 4.0
Meter Scoring True
Path Distance Scale 2.0
Obstacle Range 2.5
Ray Trace Range 3.5
Transform Tolerance 0.3
Robot Radius 0.2
Inflation Radius 1.75
Global & Local Update Frequency 5.0
Global & Local Publish Frequency 5.0
Global & Local Resolution 0.02
Global Width & Height 5.0
Local Width & Height 1.0

TABLE 5: Result Summary

Udacity-bot Custom-bot
Convergence Time (second) 409 278
Navigation Time (second) 895 810 (b) udacity-bot at goal no base

Fig. 3: Udacity-bot at Goal Position

5.1 Parameters Discussion

value of 0.001, since the noises are non-existent in
5.1.1 AMCL the simulation.
• The min-particles, max-particles, and the
transform_tolerance are tuned based on the 5.1.2 move base
performance of the processing unit in conducting • For the global and local parameters, both of their
localization. It is observed by the author that the update_frequency and publish_frequency
values of 20, 100, and 0.3, respectively, are in relation are set to 5.0, since they are both dependent upon
with the 5Hz value of update_frequency and the processing unit performance and in relation with
publish_frequency in producing a map visual- several AMCL parameters mentioned previously, it
ization that is not flickering and significantly less produces less warnings and less flickering map.
frequency-inconsistency warnings thrown. The other parameter with the same value is the
• For the laser parameters, the laser_model_type resolution, which for both global and local is set
used is the likelihood_field, since it is sug- to 0.2. However, for the width and height, the
gested by Udacity as the one that is more compu- global has a value of 5.0 and the local has a value
tationally efficient and more reliable in simulation. of 1.0, since a small value for both of them results in
Two additional parameters are z_laser_hit and a better behavior of the robot in following the local
z_laser_rand which are to specify the accuracy of and global path.
the laser sensor, which are both set to their default • Some parameters for the common costmap are
values, 0.95 and 0.05 respectively. set according to the illustration code in the pack-
• For the odometry, since the differential drive con- age’s documentation. They are obstacle_range
troller is used, the odom_model_type is set to and raytrace_range which are set to 2.5
diff-corrected. Further, as suggested in the doc- and 3.0 respectively. Then, footprint is spec-
umentation of AMCL package, that specification en- ified for the udacity-bot, since it has a box
tails only to set the alphas from odom_alpha_1 to chassis, while robot_radiu is specified for
odom_alpha_4 and they are all set to a very small the custom-bot, since it has a cylindrical chas-
LOCALIZATION PROJECT, ROBOTICS NANODEGREE PROGRAM, UDACITY 5

5.2 Result Discussion

It has been observed that the custom-bot performs better
than the udacity-bot with regards to both how fast the
particles converges and how fast the robot achieves the goal
position and orientation.
Since the only differing parameters from both robots
are their chassis’ shapes, dimensions, and their wheels, the
difference in performance might be explained by the size of
their wheels.
Even though the torque specified to both robots are the
same, the smaller size of the custom-bot’s wheels might
make it travel faster and thus, the convergence of the
localization particles is also faster, since it makes the u-turn
first (of which it has been encountered that the convergence
seems to happen when the robot is making a u-turn).
(a) custom-bot at goal Further, the problem of ’Kidnapped Robot’ when using
MCL is observed to be poor. A test of deactivating AMCL
when performing navigation towards the goal and reactivat-
ing it again (thus emulating the condition of the robot being
kidnapped) results in the robot getting off-tracked from the
navigation path and seem to not be able to getting back on
track.
Overall, the AMCL has performed a great job in approx-
imating the position and orientation of both robots, even
though both of them have a different shape and size. Using
it with a navigation stack such as move base is appropriate
in a real life situation that involves navigating a robot in a
known map. For example, the task of navigating a robot in a
warehouse would be effectively conducted by using AMCL.

6 C ONCLUSION / F UTURE WORK

(b) custom-bot at goal no base
In conclusion, AMCL is appropriate in conducting the task
Fig. 4: Custom-bot at Goal Position of localization when there is restriction in the capability of
the processing unit of the robot, since its parameter could
be tuned to lower the accuracy, but resulting in a better
and faster performance. Its application is thus, specifically
effective in a robot which has a low computing capability,
sis. Also, the transform_tolerance and the for which its performance can be improved by sacrificing
controller_frequency are set to 0.3 and 5.0Hz accuracy.
respectively, which are observed to work well Further, a significant issue in completing the task in this
with other parameters for both packages in reduc- paper is that it still takes a considerable amount of time for
ing warnings thrown. Another parameter is the the robot to navigate towards the goal position and orienta-
inflation_radius, which determines how far tion. An improvement in the future which would result in
does the path needs to stay away from the obstacles, faster processing will impact the performance significantly.
and it is set to 1.75 according to the paper written by This might be achieved by allocating a greater processing
Kaiyu Zheng [1], since it produces the path that are power and memory to the simulator (which translate in a
in the middle of obstacles. faster processing unit in the real world) and also simpler
• For the base local planner parameters, the sensors that would reduce the input data size and resulting
yaw_goal_tolerance and xy_goal_tolerance in a faster process.
are set to 0.03, since it has been observed to be the
lowest value of decimal to the power of two which
will keep the robot from rotating too long in adjust-
R EFERENCES
ing its orientation when goal position is achieved. [1] K. Zheng, “Ros navigation tuning guide,” eprint arXiv:1706.09068,
2017.
Then the max_vel_x is set to be 1.0, so that it
has faster speed rather than its default. Further, the
meter scoring is set to be true and the sim_time
and pdist_scale are set to 4.0 (as suggested by
the paper by Kaiyu Zheng [1]) and 2.0 respectively,
since they result in the local path being close to the
global’s.