Robot Localisation in Known Environment
Using Monte Carlo Localisation
Stanislav Basovnik, Pavol Jusko, Tomas Petrusek,
Michal Tulacek, and David Obdrzalek
Charles University in Prague, Faculty of Mathematics and Physics
Malostranske namesti 25, 118 00 Praha 1, Czech Republic
sbasovnik@gmail.com, pavol.jusko@gmail.com, petrusek@gmail.com,
michal@tulacek.eu, david.obdrzalek@mff.cuni.cz
Abstract. In this paper we present our approach to localisation of a robot in
a known environment. The decision making and the driving is much harder to
be done without the knowledge of the exact position. Therefore we discuss the
importance of the localisation and describe several known localising algorithms.
Then we concentrate on the one we have chosen for our application and outline
the implementation supporting various inputs. Combining of the measurements is
also discussed. In addition to well known inputs like odometry and other simple
inputs we describe deeper our beaconing system which proved to be very useful.
Keywords. Autonomous robot, Localisation, Monte Carlo Localisation
1 Introduction
Autonomous robot design is a complex process covering many aspects and containing
many decisions. The more autonomous robot we want, the better localisation we need.
For example, the localisation of a robot with only one positioning sensor is easy, but
the position of the robot can be at stake. On the other hand, as the number of sensors
increases, the harder is to estimate the position because of differences in the outputs
the sensors provide. One efficient way of dealing with multiple inputs is the use of
probabilistic methods. In this paper, we discuss this problem in general, and we present
one particular implementation using Monte Carlo localisation (MCL).
The following text is organized as follows: Section 2 gives characterization of the
task and presents the specifics of our selected problem. Section 3 gives brief outline of
existing localisation techniques. In Section 4, we describe the beaconing system, which
provides absolute position information for later use as one of inputs for the localisation
process. Section 5 presents Monte Carlo Localisation in general, and Section 6 shows
our implementation of it.
2 Characterisation of the task
The localisation is the key feature of each robot. If a robot does not know its position
then its actions are strongly limited. The goal of localisation is to determine the most

probable position of the robot based on known data. The localisation algorithm itself
should be universal and independent on the actual purpose of the robot. Then, the only
variable part of a localisation procedure is the set of sensors.
We will use data from robot’s sensors to compute its exact position. For example,
we can use odometry sensors, contactless detectors of obstacles, beacons for direction
and/or distance measuring, bumpers, camera and others. All these sensors provide data
with different accuracy so we need to handle the data with different weights. Local-
isation algorithms should not depend on a specific type of sensor or a limited list of
them. The goal is to develop a universal solution that works with different sensors (or
better said with as many different sensors as possible). Information retrieved from these
sensors is consequently used as input data for localisation algorithm.
In this article we will present the algorithm on the robot which is designed to par-
ticipate in the Eurobot autonomous robot contest [1]. The Eurobot contest rules define
the following properties of the task:
– Localisation is done in a known indoor environment
– Important areas of environment are highlighted
– The robot starts placed at known position
– The task is limited by time - there are only 90 seconds available
– The environment is relatively small (2 × 3 meters)
– There is one opponent robot which competes with our robot
– The environment contains several game elements
– The robot has to find important areas of the environment
– There can be placed localisation beacons at predefined places
– The robot has limited height and circumference.
– Because of its size, the robot has only a limited computing capacity
This list is quite wide. Obviously, it affects the development of robot hardware and
software, but it should be also noted that the algorithm itself is not that much application
dependent and can be used for other applications in different conditions too.
The localisation must be done with reasonable precision. If the robot computes
wrong position it could accidentally hit and destroy built structures or miss its goal.
This would surely lead to losing of the game. Also, everything has to be computed al-
most in real-time. In Eurobot game, the robot has 90 seconds to locate game elements
on the playing field or stored in the dispensers, collect the elements, drive to the target
area and finally build there a defined structure according to the rules. Throughout this
time it therefore needs to know in each moment where exactly it is and avoid collisions
with obstacles and the opponent robot.
As can be seen, GPS-based sensors cannot be used – the indoor environment and
small working area makes this sensor unusable. For such environment, other solution
must be used. Even we can assume that there is coherent light with a few local dis-
crepancies which helps to use visual systems, we need to expect interferences in sensor
readings - ultrasonic signals reflect in corners, infrared sensors are affected by strong
lights, and radio sensors are disturbed by local radio communication. On the other hand
we can expect that the robot will not meet unexpected obstacles (except playing ele-
ments or opponent robot).

3 Localisation algorithms
The area of autonomous robot localisation is well researched (see e.g. [2]), and several
ways can be used to solve the localisation problem. Therefore we do not try to invent
a new algorithm. Instead, we will outline some existing localisation algorithms and
discuss some of their implementation details, together with technical problems we have
met.
For localisation based on various input values we can choose from many algorithms.
Here we will present some of them:
Kalman filter [3, 4] the method which generalizes the floating mean. It can handle
noisy data so it is suitable for processing the data from less precise sensors. How-
ever, the model must be described with the expected value and variability which is
often too difficult constraint.
Markov localisation based on grid [5] this method resolves problem of the Kalman
filter, that must know expected value and variance of input data. This algorithm
splits the area to the grid of proper size. However this effort needs large operational
memory and computing power.
Monte-Carlo localisation [6] method that can be easily implemented. It can repre-
sent multimodal distribution and thus localize the robot globally. Moreover it can
process inputs from many sensors with different accuracy.
For our implementation we have chosen the Monte-Carlo localisation for its sim-
plicity and possibility of using more sensors.
4 Beacons
In this section, we present our design of a sensor set which provides relatively good
information about the robot position and in cooperation with other sensors it helps to
create a robust localisation system.
The main idea of this beacon system is to mount several beacons around the working
area of the robot and let the robot measure the distance to these beacons. Then, the robot
will be able to estimate its position because the beacons position is known.
4.1 Physical principle
Our absolute positioning system works on a simple principle
l = c ·dt (1)
where l is the distance, c is the speed and dt is the time of travel. In our system, we
measure the time the signal travels from the transmitter at the beacon to the receiver
mounted on the robot. Of course this works only if the speed is constant. This condition
is met as we are using ultrasonic waves. Since the speed of these sound waves is known,
we have to measure the time difference, from which the distance may be calculated
using Equation (1). To correctly measure the travelling time, we synchronize the system
by using infrared light. Similar systems based on Equation (1) (although using different
time synchronisation) have been developed; for examples see e.g. [12, 13].

4.2 Hardware
The transmitting system consists of three separate stationary beacons connected by a
cable. When the system receives signals from the three beacons and calculates the three
distances, it can theoretically determine its position by using triangulation. In praxis,
such simplest form does not fully work. The robot may move between receiving signals
from all the beacons, some signals may not be received or they may provide incorrect
information. Even that, good estimation may be acquired as will be further discussed in
Section 6.
The signal is sent one-way only, the receivers do not communicate with the trans-
mitters. Therefore, there can be multiple independent identical receivers, which are able
to determine its individual positions. These receivers may be then used for localizing
more objects and if the information is passed to a single centre, it may be of substantial
help.
Now we will focus on each part of the system closer.
Transmitters work in the following way.
1. Send timing information from one beacon (infrared)
2. Wait for a defined period of time
3. Send distance measuring information from the beacon (ultrasonic)
4. Wait a defined period of time
5. Repeat steps 1-4 for all other beacons.
Since we want to measure time difference between the signal being sent and it being
received, we need to have synchronized clocks. This is done in step 1 by using infrared
modulated signals. Besides that, the transmitted information contains additional infor-
mation about the beacon which is going to transmit sound waves.
Sound waves are transmitted as ultrasonic waves, and are always transmitted only
from one beacon at a time. The transmitted signal contains also the identification of the
source beacon.
Receiver waits for infrared timing information. When it is received, the receiver resyn-
chronizes its internal timer and generates a message. These messages are transported to
the localisation unit by serial line (RS-232), but any other transport layer may be used
(e.g. Bluetooth). Every message contains time stamp, information that synchronisation
occurred, and the information about beacon which is going to transmit ultrasonic infor-
mation in this time step. Upon reception of the timing information, the receiver switches
its state to wait for ultrasonic signal. When correct ultrasonic information arrives, the
receiver generates similar message as is the message after IR reception, but containing
time stamp for ultrasonic reception and beacon identification transmitted in the ultra-
sonic data. The difference in these two timestamps is related to distance (only a constant
needs to be subtracted, because the two signals are not transmitted exactly at the same
time). Since each beacon identifies itself in both infrared and ultrasonic transmissions,
the probability of mismatch is reduced.

When the infrared information is not received, a message is generated saying the
synchronisation did not occur and the timestamp is generated from previously synchro-
nised internal clock. When the ultrasonic information is not received, localisation unit
is notified that nothing was received.
The situation after three successfully received ultrasonic signals with synchronised
clock can be seen in Figure 1.
Intersection
B1
B2
B3
2
1
3
dt1
dt2
dt3
Fig. 1. Beaconing system
5 General description of MCL
In this section we will briefly introduce Monte Carlo Localisation (MCL). This algo-
rithm meets all the requirements mentioned in problem statement section earlier in this
paper. It is a well defined and researched algorithm (see e.g. [6]) and it is also well
established in many applications (see e.g. [7–10]).
Monte Carlo Localisation maintains a list of robot’s possible states or positions.
Each state is weighted by its probability of correspondence with the actual state of
the robot. In the most common implementation, the state represents the coordinates in
2D Cartesian space and the heading direction of the robot. It may be of course easily
extended to 3D space and/or contain more information depicting the robot state. All
these possible states compose the so called probability cloud.
The Monte Carlo Localisation algorithm consists of three phases: the prediction,
measurement, and resampling phase.
During the prediction phase, a new value for each item of the cloud is computed,
resulting in a new probability cloud. To simulate various inaccuracies that appear in a
real hardware, random noise is added to each position in the prediction phase. This is
very useful. For example: If the wheels were slipping and no random noise was added,
the probability cloud would travel faster than the real hardware.
During the measurement phase, data from real sensors are processed to adjust prob-
ability of the positions in the cloud. The probability of samples with lesser likelihood

(according to sensors) is lowered and vice versa. For example, when the sensors show
the robot orientation is northways, weight for samples representing other orientations is
lowered.
The last phase - resampling - manages size and correctness of the cloud. Positions
with probability lower than a given threshold are removed from the cloud. To keep the
number of positions constant, new positions are added. These new positions are derived
from and placed around the existing positions with high probability.
More formally, our goal is to determine robot’s state in step k, presuming the origi-
nal state and all the measurements Mk = {mi, i = 1..k} are known. Robot’s state is given
by a vector x = [x,y,α], where x and y is the robot position and α is its heading.
1. During the prediction phase, the enumeration of probability density p
(
xk | Mk
)
for
the step k takes place. It is based only on presumed movement of the robot without
any input from real sensors. Therefore, for any known command uk−1 given to the
robot, we have
p
(
xk | Mk−1
)
=
∫
p
(
xk | xk−1,uk−1
)
p
(
xk−1 | Mk−1
)
dxk−1 (2)
2. In the measurement phase, we will compute the final value of probability density
for actual step k. To do so we will use data from sensors expressed as probability
p(mk | xk), where mk is the actual state and xk is the assumed position. Finally,
probability density in step k is described by the following equation:
p
(
xk | Mk
)
= p(mk | xk) p
(
xk|Mk−1
)
p(mk|Mk−1)
(3)
Initialization:
– If the robot’s position is known, then for its state x we have: p
(
x | M0
)
= 1, for all
other states y 6= x p
(
y | M0
)
= 0.
– If the robot’s position is not known, the probability of all positions is the same.
Therefore p
(
x | M0
)
must be set for all x so that
∫
p
(
x | M0
)
dx = 1 (4)
One of the most important features of this method is its ability to process data from
more than one source. Every sensor participates on computing the probability for the
given state. For example, if we have a compass sensor and it reads that the robot is
heading to the north, we can lower the probability of differently oriented samples. If
robot’s bumper signalizes collision, there is a high probability for the robot to be near
a wall or another obstacle. It is therefore possible to discard the part of the probability
cloud which lies in an open space.
Our implementation of the MCL algorithm is described in more detail in the fol-
lowing section.

6 MCL Implementation
Our implementation of MCL is based on previous work on the Logion robot which par-
ticipated in Eurobot 2008 contest (see [11]). In the following paragraphs, we emphasize
several implementation aspects we consider as important for the successful result.
6.1 Sensors processing
In our implementation, we divide the inputs coming from sensors in two categories:
– Advancing inputs
– Checking inputs
Our system contains two interfaces for these two types of inputs. The device or
its abstraction in Hardware Abstraction Layer implements the corresponding interface
based on its type, so the MCL core can use it as its input. The MCL core calls each
device when it has new data, and the work with the samples is done by each device
separately. This keeps the main code easier to read, simpler, and input independent.
Also, the device itself knows the best how to interpret the raw data it measures.
The level of reliability can be specified for each input device. Then, the samples are
adjusted by the devices with respect to their configured credibilities. For example: two
sets of odometry encoders, one pair on driven wheels and one pair on dedicated wheels,
have different accuracy because the driven wheels may slip on the surface when too
much power is used. Then, the credibility of driven wheels encoders will be set lower
than the credibility of the undriven sensor wheels. In addition, setting the reliability
level helps to deal with different frequencies of data sampling.
6.2 Advancing inputs
This input type is used for moving the samples. Such input could be for example odom-
etry (processing of wheel encoders). The information provided by these kind of inputs
applied to samples is blurred by randomly generated noise as described earlier. After
advancing the samples, boundary conditions are checked. As a result the probability of
samples representing impossible positions is decreased. If there are several advancing
input devices, these devices must be read all at once and the result advancing informa-
tion is computed as a weighted average of all inputs according to their reliabilities.
6.3 Checking inputs
Checking inputs are not affecting the position of the samples. Instead, they are just ad-
justing their probability (also called sample weights). The reason for this is that inputs
of this type do not provide relative difference from the last measurement, but abso-
lute position information. This also does not need to be one exact point, but an area
or position probability distribution, which fits perfectly to the Monte Carlo Localisa-
tion algorithm. All checking inputs are processed separately; we regulate them only by
setting their reliability levels.
Our robot uses these checking inputs:

– compass - checks the direction of samples
– beacons - checks the distance from stationary beacons
– bumpers - checks collisions with playing field borders and other objects
– IR distance sensors - checks distance to borders and obstacles
6.4 Position estimation
It is expected that the MCL outputs the estimation of robot position. Because of its na-
ture and implementation, the result position can be computed from samples at any time.
This estimation is very simple, just computing the weighted average of all samples. In
addition we can determine the overall reliability of this estimation.
6.5 I am entirely lost
MCL can also determine the robot position from scratch if it has some absolute sensors.
The only change to the algorithm itself is reinitializing of the sample cloud. At the
beginning of localisation (when the robot is lost) samples are spread uniformly all over
the playing field as described in Section 5. The sensors providing absolute positioning
information lower the weight of misplaced samples and new samples are placed in
regions with higher probability (see Figure 2). This is repeated until sufficiently reliable
position estimation of the robot is reached.
Fig. 2. MCL after processing one beacon input: The circular belt marks the input from the bottom
left beacon. The “pins” represent oriented MCL samples; sample probability is proportional to
their darkness.

6.6 Beacons and MCL
As described earlier, our beacon system consists of three transmitting and one receiving
beacons. The information is passed from the beacon system to the main computing unit
via messages containing beacon id (i.e. transmitter identification) and time difference
between the infrared and ultrasonic transmissions. For more hardware details see full
description in Section 4.
There are two reasons why each message contains the time difference (delta) instead
of the calculated distance: computational power of the micro controller and the degree
of robustness. The main computing unit is more powerful than the receiving beacon, so
we let the beacon do less work and we even benefit from this decision. We considered
deltas to be the perfect raw data for our purpose - distance measurement. The compu-
tation is done in the main computing unit which controls all the other devices and is
highly configurable. It means that all the parameters of the equation for distance cal-
culation can be changed easily without the need of changing the beacons hardware or
device firmware. It even allows us to calculate or adjust the parameters on the flight if
distance information is provided based on external measurement. The main calculation
is described by Eq. (1).
The configuration of the main computing unit contains not only the important con-
stants for the equation, but also the positions of the transmitting beacons. As we know
the distance and the beacon id, we can increase the weights of the MCL samples in the
circular belt formed by these two values and a range constant. MCL samples far from
the belt are penalized (see Figure 2).
This approach is much better and more robust than just waiting for intersections and
then computing the robot position using simple triangulation. These intersections may
not happen very often because of the time gap between individual beacon transmissions
(especially when the robot is moving fast). At the same time, it is good to implement
different weighting for the samples on a belt, near an intersection of two belts and near
the intersection of all three belts.
6.7 Camera
The idea of using camera for absolute positioning seemed very hard at the first time.
Later, when we had the modular MCL implementation finished, we realized there is
a great opportunity to use the information we get from the camera while looking for
the playing elements positioned at predefined places of the playing area. Now, we can
compare the playing element positions (acquired from the camera) with their fixed po-
sitions (defined by the Eurobot contest rules) and adjust the weight of the MCL samples
to merge the two positions.
6.8 Gyroscope
In the early stages of robot design, we proposed to use a compass as one of the input
sensors. However, using a compass in a small indoor competition is not a very good
idea, because its precision can be degraded by influence of many factors (e.g. huge
metallic cupboard, electromagnetism, steel concrete walls or metal structure building).

Using a gyroscope instead of a compass would be much more efficient for our purposes,
because gyroscope works completely independently and the influence of the environ-
ment is minimal. The only problem is the placement of the gyroscope itself, because it
should be placed in the rotational axis of the robot.
6.9 Performance
Apparently, the processing of a large number of MCL samples may have impact on
performance of the whole localisation system. In general, the more samples we take
into computation, the more precise the localisation is, but the slower the computation
is. There is an easy way to adjust the precision to speed ratio by setting the number of
samples in the MCL cloud. In our project, we have achieved acceptable precision and
speed using 400 samples.
7 Conclusion
The advantages of using Monte Carlo Localisation instead of relying on straightforward
sensor measurings are great. Now we can use different sensing devices and combine
them with respect to their parameters, precision and credibility.
We have developed a modular system for robot localisation which allows easy ex-
tension by different kinds of modules. Our implementation allows us to add more facil-
ities with almost no or just minimal work effort and with no changes to the MCL itself
at all, while increasing the precision of the resulting position.
In our paper we have described the advantages of the Monte Carlo Localisation
compared to other methods of position estimation and how we benefit of it in our im-
plementation. The modular design of sensor processing and MCL position estimation
is described, together with practical comments on different sensor types. The created
system will be used for Eurobot 2009 contest edition but its design allows using it for
other purposes too (which we are already planning).
References
1. Eurobot Autonomous robot contest: http://www.eurobot.org
2. S. Thrun: Robotic mapping: A survey. Exploring Artificial Intelligence in the New Millenium,
2002
3. R. Negenborn: Robot Localisation and Kalman Filters: On finding your position in a noisy
world. Master Thesis, Utrech University, September, 2003
4. G. Welch and G. Bishop: An introduction to the Kalman filter. Technical Report TR 95-041,
University of North Carolina, Department of Computer Science, 1995
5. W. Burgard, A. Derr, D. Fox and A. B. Cremers: Integrating global position estimation and
position tracking for mobile robots: the dynamic markov localisation approach. In Proc. of the
IEEE/RSJ International Conference on Intelligent Robots and Systems (IROS), 1998
6. F. Dellaert, D. Fox, W. Burgard, and S. Thrun: Monte Carlo Localisation for Mobile Robots.
IEEE International Conference on Robotics and Automation (ICRA99), May, 1999.
7. E. Menegatti and M. Zoccarato: Image-based monte-carlo localisation with omnidirectional
images. Robotics and Autonomous Systems 48, 2004, 17–30

8. D. Ha¨hnel and W. Burgard: Mapping and localisation with rfid technology. In Proceedings of
ICRA05, 2004, 1015–1020
9. O. Wulf, B. Wagner and M. Khalaf-Allah: Using 3D data for Monte Carlo Localisation in
complex indoor environments. European Conference on Mobile Robots (ECMR05), Septem-
ber, 2005
10. S. Lenser and M. Veloso: Sensor Resetting Localisation for Poorly Modelled Mobile Robot.
In Proceedings of the IEEE International Conference on Robotics and Automation (ICRA),
2000
11. A. Mikulik, D. Obdrzalek, T. Petrusek, S. Basovnik, M. Dekar, P. Jusko, R. Pechal, R. Pitak:
Logion - A robot Which Collects Rocks. Proceedings of the EUROBOT Conference 2008,
May, 2008, 276–287
12. Y. Soo-Yeong: Global ultrasonic system with selective activation for autonomous navigation
of an indoor mobile robot. Robotica, vol. 26, May, 2008, 277-283
13. L. Dazhai, F. Hualej, W. Wei: Ultrasonic Based Autonomous Docking on Plane for Mo-
bile Robot. IEEE International Conference on Automation and Logistics, vols. 1-6, September,
2008, 1396-1401