=Paper=
{{Paper
|id=None
|storemode=property
|title=Input Combination for Monte Carlo Localization
|pdfUrl=https://ceur-ws.org/Vol-584/paper7.pdf
|volume=Vol-584
|dblpUrl=https://dblp.org/rec/conf/itat/Obdrzalek09
}}
==Input Combination for Monte Carlo Localization==
https://ceur-ws.org/Vol-584/paper7.pdf
Input combination for Monte Carlo Localization
David Obdržálek
Charles University in Prague, Faculty of Mathematics and Physics
Malostranské náměstı́ 25, 118 00 Praha 1, Czech Republic
david.obdrzalek@mff.cuni.cz
Abstract. One of the basic skills for an autonomous ro- The following text is organized as follows: Sec-
bot is the ability to determine its own position. There are tion 2 gives characterization of the task and presents
numerous high-level systems which provide precise position the specifics of our selected problem. Section 3 gives
information, but the same task may be also solved using less brief outline of existing localization techniques. Sec-
advanced and less accurate sensors. In our paper, we show tion 4 presents Monte Carlo Localization in general,
how a good output may be acquired from not so good inputs
Section 5 shows our modification to MCL by differ-
if it is combined using modified Monte Carlo Localization
(MCL) system. The combination of more inputs also helps
entiating between sensor classes and Section 6 shows
to acquire plausible results even in situations, where adding some implementation aspects. Sections 7 and 8 sum-
new sensor(s) to an existing system raises doubts about the marize the results and conclude the paper.
position calculation, because the newly added sensor may
provide different position information (or data from which
the position is calculated) than what is provided by the al- 2 Motivation and characterization of
ready used sensors. We will show that using such “incor- the task
rect” data may be beneficial for determining the position
with a reasonable probability.
The goal of robot localization is to determine the po-
sition of the robot which moves through its working
environment. It may use data about the environment
1 Introduction and data about the robot, both using measured data
as well as data known in advance. To a great extent,
Good localization is for an autonomous robot one of the localization algorithm itself can be application in-
the keys to success. A robot which does not know its dependent and the usage for specific purposes can vary
position, or which gets lost while performing its task, just by choosing different inputs.
is not something what could be used in real life well. Inputs for the localization system may come from
For some tasks, localization can be quite simple, but different sources: data may be acquired for example
in general, the better autonomous robot we want, the using different sensors mounted on the robot (mea-
better (and usually more complicated) localization it suring either internal or external properties), by re-
needs. Some systems use single input for the localiza- ceiving signals sent from external sources, or even cre-
tion task and do not need any complex mechanisms to ated as virtual data which does not represent any real
accomplish all needed goals. Other systems combine measurements (e.g. expected position change based on
more inputs (and more input types) to acquire data for commands issued by the control system). Because the
the localization process; it may be because of different different sensors provide data with different level of ac-
nature of the data which is available to be measured curacy and trustworthiness, data should be also han-
for the localization as well as because different sensing dled with different weights.
methods may help to overcome problems with erro- The localization algorithm processes the selected
neous data coming from individual sensors. However, inputs to calculate the robot position. If the algorithm
combining more inputs may at the same time rise ques- itself does not depend on a specific type(s) of input
tions about the preciseness of the localization process: data, then it is possible to create a generic solution
What went wrong if two or more inputs showed dif- which works with different (and configurable) sets of
ferent positions? Is it because of faulty sensor, inex- sensors.
act measurement, cumulative errors or improper data In this paper we present one possible solution of the
handling? localization problem which has been tested on a real
Recently, the research in the robot localization sta- robot. This robot was used to play in the Eurobot au-
rted to bring very good results using probabilistic me- tonomous robot contest in 2009 (see [1]). Although the
thods. In this paper, we discuss this problem in gen- system was created for the 2009 edition of the contest,
eral, and we present one particular implementation it was designed so that it could be used without re-
which uses Monte Carlo Localization (MCL). programming for future editions too. Moreover, it was
46 David Obdržálek
designed to be independent on this particular task at of proper size and tries to determine the one the
all and it may be reused in other projects with differ- robot is in. Unfortunately, this requires large oper-
ent inputs as well. ational memory to store the data and computing
The Eurobot contest rules change every year, but power to handle it.
they always share the same core of basic characteris- Monte-Carlo localization [6] can represent multi-
tics (for more details, see the Eurobot Association web modal distribution and thus localize the robot glo-
pages at [1]): bally. It can process inputs from many sensors with
different accuracies. Moreover, it can be easily im-
– Known indoor environment with highlighted im- plemented.
portant landmarks
– Small working area (2.1 × 3 meters) For our given task, it is not possible to use standard
– Possibility to place localization beacons at prede- Kalman filter, because its basic requirements are not
fined places around the working area met: in our case, the expected value and variance of
– Target objects placed semi-randomly on the work- the measured values are not known.
ing area The second mentioned localization algorithm, Mar-
– Predefined starting position of the robot kov grid-based localization, would overcome this prob-
– Limited height and circumference of the robot lem, but would impose another problem at the same
– Two robots moving in the area at the same time time – the need to handle lot of data. The position of
with the necessity to avoid collisions a robot is specified as one cell in a grid covering the
whole working area. It is needed to store some data
This list obviously affects the development of ro-
for each grid cell, and to reach good precision level,
bot hardware and software. However, our aim was to
the grid must be fine. Our hardware platform provided
create a localization algorithm which is not that much
sufficient storage with reasonable power for processing
application dependent and can be used for other ap-
the navigation task and for controlling the hardware,
plications in different conditions too.
but including Markov localization would cause over-
The exactly needed precision level is application
loading of the system and the goal to create a success-
dependent and varies a lot from one application to an-
ful autonomous robot could not be reached: neither
other. For the specific conditions it is however impor-
the memory volume nor the computational power of
tant to maintain the precision in an acceptable range.
our hardware were strong enough to handle Markov
Therefore, our aim was to create a localization algo-
grid-based localization alone, not talking about com-
rithm which would be able to reach the required preci-
bining it with all the other needed tasks.
sion level even using less precise inputs. The precision
Therefore, we have decided to implement Monte-
should not be predefined nor implied by the algorithm.
Carlo localization and let it use the remaining resour-
ces in the system as long as it does not affect its func-
3 Localization algorithms tionality. This also directly implied the selection of the
MCL parameters in the tuning phase – “eat as much
The area of autonomous robot localization is well re- as you like as long as supply lasts”. At the same time,
searched (see e.g. [2]), and several ways can be used we gained the possibility to use more different sensors
to solve the localization problem. Therefore we do not for the localization task.
try to invent a new algorithm. Instead, we will out- The Monte-Carlo localization will be further dis-
line some existing localization algorithms and discuss cussed in Section 4 and our implementation in Sec-
some of their implementation details, together with tions 5 and 6.
technical problems we have met.
For localization based on various input values one
can choose from many algorithms; the most know are: 4 General description of MCL
Kalman filter [3, 4] generalizes the floating mean. It In this section we will briefly outline Monte Carlo Lo-
can handle noisy data so it is suitable for process- calization (MCL), introduced by Dieter Fox in the
ing the data from less precise sensors. However, late 1990s [6]. This algorithm meets all the require-
the model must be described with the expected ments mentioned in problem statement section earlier
value and variability which is often too difficult in this paper. It is a well defined and researched algo-
constraint. rithm and it is also well established in many applica-
Markov localization based on grid [5] resolves tions (see e.g. [7–10]).
one of the problems of Kalman filter, which needs Monte Carlo Localization maintains a list of possi-
to know the expected value and the variance of in- ble states of the state space (representing the positions
put data. This algorithm splits the area to the grid of the robot). Each state is weighted by its probability
Input combination for MCL 47
of correspondence with the actual state of the robot. During the initialization of MCL, it is needed to
In the most common implementation, the state repre- set the probability cloud. If the robot’s position is
sents the coordinates in 2D Cartesian space and the known,
¡ then
¢ for its (known) state x the probability
heading direction of the robot. It may be of course p x | M 0 =¡ 1, and¢ for all other states y 6= x the
easily extended to 3D space and/or contain more in- probability p y | M 0 = 0.
formation depicting the robot state. All these possible If the robot’s position is not known,
¡ the
¢ probability
states compose the so called probability cloud. of all positions is the same and p x | M 0 must be set
The Monte Carlo Localization algorithm consists for all x so that
of three phases: Prediction, Measurement, and Resam- Z
¡ ¢
pling. p x | M 0 dx = 1
During the Prediction phase, a new value for each
item of the cloud is computed, resulting in a new prob- One of the most important features of this method
ability cloud. To simulate various inaccuracies that is its ability to process data from more than one sour-
appear in a real hardware, random noise is added to ce. Every sensor participates on computing the prob-
each position in the prediction phase. This is very use- ability for the given state. For example, if we have
ful. For example: If the wheels were slipping and no a compass sensor and it reads that the robot is head-
random noise was added, the probability cloud would ing to the north, we can lower the probability of dif-
travel faster than the real hardware. ferently oriented samples. If robot’s bumper signalizes
During the measurement phase, data from real sen- collision, there is a high probability for the robot to be
sors are processed to adjust probability of the positions near a wall or another obstacle. It is therefore possible
in the cloud. The probability of samples with lesser to discard the part of the probability cloud which lies
likelihood (according to sensors) is lowered and vice in an open space.
versa. For example, when the sensors show the robot The Monte Carlo Localization can be implemented
orientation is northwards, weight for samples repre- easily, yet it provides very good results especially in
senting other orientations is lowered. cases, where the sensors do not provide exactly cor-
The last phase - resampling - manages size and cor- rect data (e.g. the distance measurement is subject to
rectness of the cloud. Samples with probability lower errors). Our implementation of the MCL algorithm,
than a given threshold are removed from the cloud. To which shows its great usability, is described in more
keep the number of positions constant, new positions detail in the following section.
are added. These new positions are placed around ex-
isting positions with high probability.
Formally, the goal is to determine robot’s state in 5 Sensor classes in modified MCL
step k, presuming the original state and all the mea-
We have decided to modify the original MCL algo-
surements M k = {mi , i = 1..k} are known. Robot’s
rithm and use sensor input also for the prediction
state is given by a vector x = hx, y, αi, where x and y
phase. We allow selected reliable sensors to change the
is the robot position and α is its heading.
position of MCL samples in addition to changing the
During
¡ the ¢prediction phase, the probability den-
weights of samples based on the sensor readouts. This
sity p xk | M k for step k is enumerated. It is based
allows to maintain the probability cloud more in shape
only on presumed movement of the robot without any
with the actual robot movement, yet we keep the core
input from real sensors. Therefore, for any known com-
MCL idea of adding random noise to handle unex-
mand uk−1 given to the robot, we have
pected inputs or inputs which are not in accordance
¡ ¢ to actual robot movement.
p xk | M k−1 = In our implementation, we divide the inputs com-
Z
¡ ¢ ing from sensors in two categories, which will be fur-
= p (xk | xk−1 , uk−1 ) p xk−1 | M k−1 dxk−1
ther discussed in following paragraphs:
In the measurement phase, we will compute the fi- – Advancing inputs
nal value of probability density for actual step k. To – Checking inputs
do so, data from sensors is used. It implies the proba-
bility of p (mk | xk ), where mk is the actual state and Our system contains two interfaces for these two
xk is the assumed position. The probability density in types of inputs. The device or its abstraction in Hard-
step k is then described by the following equation: ware Abstraction Layer implements the corresponding
¡ ¢ interface based on its type, so the MCL core can use it
¡ k
¢ p (mk | xk ) p xk |M k−1 as its input. The MCL core calls each device when it
p xk | M = has new data, and the work with the samples is done
p (mk |M k−1 )
48 David Obdržálek
by each device separately. This keeps the main code – Compass - checks the direction of samples
easier to read, simpler, and input independent. Also, – Beacons - check the distance from stationary bea-
the device itself knows the best how to interpret the cons
raw data it measures. – Bumpers - check collisions with playing field bor-
The level of reliability can be specified for each ders and other objects
input device. Then, the samples are adjusted by the – IR distance sensors - check distance to borders and
devices with respect to their configured ‘credibilities’. obstacles
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 6 Implementation aspects
slip on the surface when too much power is used. Then,
the credibility of driven wheels encoders will be set Our implementation of MCL is based on previous work
lower than the credibility of the sensors mounted on on a robot which participated in Eurobot 2008 con-
undriven wheels. In addition, setting the reliability test (see [11]). That first “pilot” MCL implementa-
level helps to deal with different frequencies of data tion in 2008 was not complete; it was rather proof-
sampling. of-concept than a reliable software unit, and we also
knew the computational power will be different if 2009
so performance was not considered at all. However,
5.1 Advancing inputs the results seemed very promising, so it has not been
This input type is used for changing the samples which dropped but has been further developed and extended
form the probability cloud. Such input could be for ex- to use it in 2009 for real. In the following paragraphs,
ample odometry, from which relative movement since we emphasize several implementation aspects we con-
last iteration is calculated. This difference is then used sider as important for the successful result.
to change the samples properties. i.e. to move them.
The information provided by these kind of inputs ap- 6.1 Position estimation
plied to samples is ‘blurred’ by randomly generated
noise as described earlier in the general MCL descrip- It is expected that the MCL outputs the estimation
tion. After moving the samples, boundary conditions of robot position. Because of its nature, the result-
are checked (i.e. to exclude samples which fell out of ing position (“most probable position”) can be com-
the physical working area). As a result the probabil- puted from the samples at any time. This estimation
ity of samples representing impossible positions is de- is very simple, just computing the weighted average of
creased. all samples. In addition we can determine the overall
These advancing inputs are added to the origi- reliability of this estimation. Therefore, we have made
nal MCL algorithm, which deals only with theoret- the interface to the MCL asynchronous to the inputs,
ical movement based on movement commands. It is and the MCL core can be called at any time whenever
not necessary to use it so, but it brings much better needed. This approach obviously dramatically saves
precision for little cost. the computational power in comparison to incremen-
Our robot currently uses only one advancing input: tal localization methods which might need periodical
the odometry information from encoders mounted on updates or re-calculations.
dedicated sensor wheels.
6.2 Localization without initial knowledge
5.2 Checking inputs
Monte Carlo Localization can also determine the robot
Checking inputs do not affect the position of the sam- position from scratch. At the beginning of localization
ples. Instead, they are just adjusting their probabil- (when the robot is lost) samples are spread uniformly
ity (also called sample weights). The reason for this all over the playing field as described in Section 4.
is that inputs of this type provide absolute position The sensors providing absolute positioning informa-
information and not relative difference from the last tion lower the weight of misplaced samples and new
measurement. This also does not need to be one exact samples are placed in regions with higher probability
point, but an area or position probability distribution, (see Figure 2). This is repeated until sufficiently reli-
which fits perfectly to the Monte Carlo Localization able position estimation of the robot is reached.
algorithm. At the same time, it is possible to reach a result
All checking inputs may be processed separately; even without absolute sensors – as the robot moves,
we regulate them only by setting their reliability levels. the sensors which provide relative information (ad-
Our robot uses these checking inputs: vancing inputs) will move the samples as usually and
Input combination for MCL 49
B1
dt1
Intersection
dt3
1 B3
3 2
dt2
B2
Fig. 1. Beaconing system; B1, B2, B3 are the beacons, and the robot (marked by grey circle) measured distances dt1 ,
dt2 , dt3 from individual beacons.
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.
50 David Obdržálek
the boundary checks gradually cut the impossible con- constant. This condition is met as we are using ultra-
figurations until the required precision is reached sonic waves in a small environment with more or less
(e.g. only one and small cloud remains). constant conditions and the robot speed is negligible.
Since the speed of the sound waves is known, we
6.3 Adding / removing sensors can measure the time difference, from which the dis-
tance may be easily calculated. It is possible to use two
When new sensors are added to a system, the infor- beacons for good position calculation (provided the
mation they provide may affect the position the robot measurements are precise and we know at which half-
“thinks” it is in. It may be because the new sensor plane the robot is). If there 3 or more beacons located
gives better data (in which case we certainly appre- around the working area, the trilateration will theoret-
ciate the change). On contrary, the new sensor could ically give a single solution. Practically, the measure-
provide data with lesser quality then the already exist- ments may not be precise and so the calculation may
ing sensors. This is not a big problem in MCL, because not lead to any intersection of the circles. In our sys-
such low quality data may change the samples prop- tem, this is not a problem, because the measurements
erties (position) or weight, but because of the nature are not used for trilateration but handled separately
how MCL works, such change may be perceived as to adapt the probability cloud used in MCL.
adding the random noise which is part of MCL any- To correctly measure the traveling time, we syn-
way. So, it may even help the algorithm to work well. chronize the transmitter-receiver system by using in-
It could be said in general – the more different inputs, frared light (see below).
the better. Many other systems based on the TOF principle
If we remove a sensor from the robot or if it stops have been developed; for examples see e.g. [12, 13].
providing data and there are other sensors available, it
does not imply the MCL results will be worse. It means
Hardware The transmitting system consists of three
there are fewer inputs which adjust the samples or
stationary interconnected beacons located at specified
their weights but the remaining sensors will adapt the
places around the working area of the robot. When
probability cloud in accordance to their inputs and so
the system receives signals from the three beacons and
sufficient level of result preciseness can be maintained.
calculates the three distances, it can theoretically de-
Therefore, the system is less vulnerable than a system
termine its position by using trilateration. In praxis,
which relies during the localization on one sensor or
such simplest form does not fully work. The robot may
sensor set.
move between receiving signals from all the beacons,
some signals may not be received or they may provide
6.4 Beacons incorrect information because of reflections. Even that,
good estimation may be acquired as was discussed in
In the following paragraphs, we present our design of
Section 6.
a sensor set which provides relatively good information
The signal is sent one-way only, the receivers do not
about the robot position and in cooperation with other
communicate with the transmitters. Therefore, there
sensors it helps to create a robust localization system
can be multiple independent identical receivers, which
– the beacon system.
are able to determine its individual positions. These
The main idea of this beacon system is to mount
receivers may be then used for localizing more objects
several beacons around the working area of the ro-
and if the information is passed to a single center,
bot and let the robot measure the distance to these
it may be of substantial help (for example to create
beacons. Then, the robot will be able to estimate its
opponent avoidance system by placing one receiver on
position because the beacons position is known. This
the opponent and reading it by wireless transfer).
sensor set provides absolute position information, but
its correctness may be attacked by the environment
features, as for example the signal may get reflected Transmitters at each beacon work in the following
by close obstacles like walls or the robot could not be way:
able to measure the distance to one beacon because
the signal may get lost (or get blocked by an obsta- 1. Send timing information (infrared)
cle). 2. Wait for a defined period of time
3. Send distance measuring information (ultrasonic)
4. Wait for a defined period of time
The principle In our system, we measure the time (this is sequentially repeated for all beacons)
the signal travels from the transmitter at the beacon
to the receiver mounted on the robot (TOF – Time As we want to measure time difference between the
of Flight). Of course this works only if the speed is signal being sent and received, we need to have syn-
Input combination for MCL 51
chronized clocks. This is done in step 1 by using in- unit which controls all the other devices and is highly
frared modulated signals. Besides that, the transmit- configurable. It means that all the parameters of the
ted information contains additional information about equation for distance calculation can be changed easily
the beacon which is going to transmit sound waves. without the need of changing the beacons hardware or
Sound waves are transmitted as ultrasonic waves, device firmware. It even allows us to calculate or adjust
and are always transmitted only from one beacon at the parameters on the flight if distance information is
a time. The transmitted signal contains also the iden- provided based on external measurement.
tification of the source beacon. The configuration of the main computing unit con-
tains not only the important constants for the equa-
Receiver waits for the infrared timing information. tion, but also the positions of the transmitting bea-
When it is received, the receiver resynchronizes its in- cons. As we know the distance and the beacon id, we
ternal timer and generates a message. These messages can increase the weights of the MCL samples in the
are transported to the localization unit. Every mes- circular belt formed by these two values and a range
sage contains time stamp, information that synchro- constant. MCL samples far from the belt are penalized
nization occurred, and the information about beacon (see Figure 2).
which is going to transmit ultrasonic information in This approach is much better and more robust
this time step. Upon reception of the timing infor- than just waiting for intersections and then computing
mation, the receiver switches its state to wait for ul- the robot position using simple trilateration. These in-
trasonic signal. When correct ultrasonic information tersections may not happen very often because of the
arrives, the receiver generates similar message as is time gap between individual beacon transmissions (es-
the message after IR reception, but containing time pecially when the robot is moving fast). At the same
stamp for ultrasonic reception and beacon identifica- time, it is good to implement different weighting for
tion transmitted in the ultrasonic data. The differ- the samples on a belt, near an intersection of two belts
ence in these two timestamps is linearly dependent and near the intersection of all three belts.
to distance with a constant offset (the two signals are
not transmitted exactly at the same time). Since each
6.6 Camera
beacon identifies itself in both infrared and ultrasonic
transmissions, the probability of mismatch is reduced. The idea of using camera for absolute robot position-
When the infrared information is not received, ing seemed very hard at the first time. Later, when
a message is generated saying the synchronization did we had the modular MCL implementation finished,
not occur and the timestamp is generated from previ- we realized there is a great opportunity to use the
ously synchronized internal clock. When the ultrasonic information we get from the camera while looking for
information is not received, localization unit is notified the playing elements positioned at predefined places of
that nothing was received. the playing area. Now, we can compare the playing el-
The situation after three successfully received ul- ement positions (acquired from the camera) with their
trasonic signals with synchronized clock can be seen fixed positions (defined by the Eurobot contest rules)
in Figure 1. and adjust the weight of the MCL samples to merge
the two positions. For more details, see [14].
6.5 Beacons and MCL
As described earlier, our beacon system consists of 6.7 Gyroscope
three transmitting and one receiving beacons. The in-
formation is passed from the beacon system to the In the early stages of robot design, we proposed to use
main computing unit via messages containing beacon a compass as one of the input sensors. However, using
id (i.e. transmitter identification) and time difference a compass in a small indoor competition is not a very
between the infrared and ultrasonic transmissions. good idea, because its precision can be degraded by in-
There are two reasons why each message contains fluence of many factors (e.g. huge metallic cupboard,
the time difference (delta) instead of the calculated electromagnetism, steel concrete walls or metal struc-
distance: computational power of the microcontroller ture building). Using a gyroscope instead of a compass
and the degree of robustness. The main computing would be much more efficient for our purposes, be-
unit is more powerful than the receiving beacon, so cause gyroscope works completely independently and
we let the beacon do less work and we even bene- the influence of the environment is minimal. The only
fit from this decision. We considered deltas to be the problem is the placement of the gyroscope itself, be-
perfect raw data for our purpose - distance measure- cause it should be placed in the rotational axis of the
ment. The computation is done in the main computing robot.
52 David Obdržálek
7 The results and performance the contest and all connected events when the working
conditions for the robot remain unchanged. After fin-
Apparently, processing of a large number of MCL sam- ishing the year, we want to evaluate the performance
ples may have impact on performance of the whole of this MCL implementation to be able to judge its us-
localization system. In general, the more samples are age in other environments and with other hardware.
taken into computation, the more precise the localiza-
tion is, but the slower the computation is.
References
In our project, we have achieved acceptable speed
using 400 samples. The acquired precision lies within 1. Eurobot Association: Eurobot autonomous robot con-
a margin of single millimeters which is sufficient for test: http://www.eurobot.org, 2009.
the current task; should higher precision be needed, 2. S. Thrun: Robotic mapping: a survey. In: Exploring
it could be easily reached by increasing the samples artificial intelligence in the new millennium. Morgan
count and fine-tuning the weighting functions. Also, Kaufmann Publishers Inc., 2003, 1–35.
3. R. Negenborn: Robot localisation and kalman filters:
this number of samples and the resulting precision are
On finding your position in a noisy world. Master’s
independent on the working area size. thesis, Utrecht University, 2003.
On contrary, the Markov grid-based localization 4. G. Welch, G. Bishop: An introduction to the Kalman
requires to handle a grid with the size of the robot filter. Technical Report TR 95-041, University of
working area and the number of cells proportional to North Carolina at Chapel Hill, 2004.
required precision. In the case of Eurobot contest, to 5. W. Burgard, A. Derr, D. Fox, A.B. Cremers: Integrat-
reach the same precision we would need to handle a ing global position estimation and position tracking for
grid of 2100 x 3000 samples which is magnitudes higher mobile robots: The dynamic Markov localization ap-
than the 400 samples needed when using MCL. proach. In: Proc. of the IEEE/RSJ International Con-
ference on Intelligent Robots and Systems (IROS).,
The depicted modification of using sensors for the
1998.
prediction phase instead of using just the information 6. F. Dellaert, D. Fox, W. Burgard, S. Thrun: Monte
of expected robot movement has increased the preci- Carlo localization for mobile robots. In: Proc. of the
sion too, as it takes into account not only where the IEEE International Conference on Robotics & Au-
robot was supposed to move, but where it actually tomation (ICRA99), 1998.
moved. To be able to use sensors for this modification, 7. E. Menegatti, M. Zoccarato, E. Pagello, H. Ishiguro:
it is needed to assure their good credibility. For our Image-based Monte-Carlo localisation with omnidirec-
real robot, we have used odometry sensors mounted tional images. Robotics and Autonomous Systems 48,
on dedicated wheels, which are not subject to skids 2004, 17–30.
8. D. Hähnel, W. Burgard: Mapping and localization with
and slides of the powered wheels. It has proven this is
rfid technology. In: Proc. of the IEEE International
sufficient to reach a good level of precision. Conference on Robotics & Automation (ICRA05),
2004, 1015–1020.
9. O. Wulf, M. Khalaf-Allah, B. Wagner: Using 3D data
8 Conclusion and future work for Monte Carlo localization in complex indoor envi-
ronments. In: 2nd Bi-Annual European Conference on
In our paper, we have described the advantages of the Mobile Robots (ECMR05), 2005, 170–175.
Monte Carlo Localization compared to other methods 10. S. Lenser, M. Veloso: Sensor resetting localization for
of position estimation and how we benefit of it in our poorly modelled mobile robots. In: Proc. of the IEEE
implementation. Based on available sensor types, we International Conference on Robotics & Automation
have decided to adapt the MCL algorithm to use one (ICRA00), 2000.
sensor class to change the samples instead of using all 11. A. Mikulik, D. Obdrzalek, T. Petrusek, S. Basovnik,
sensors to change the sample weights only. M. Dekar, P. Jusko, R. Pechal, R. Pitak: Logion –
As a practical result, we have developed a mod- a robot which collects rocks. In: Proceedings of the
EUROBOT Conference 2008, 276–287.
ular system for robot localization which allows easy
12. S.Y. Yi: Global ultrasonic system with selective acti-
extension by different kinds of modules. Our imple- vation for autonomous navigation of an indoor mobile
mentation allows us to add more facilities with almost robot. Robotica 26, 3, 2008, 277–283.
no or just minimal work effort and with no changes to 13. L. Dazhai, F.H. Fu, W. Wei: Ultrasonic based au-
the core localization itself at all, while increasing the tonomous docking on plane for mobile robot. In: IEEE
precision of the resulting position. The created system International Conference on Automation and Logistics
was successfully used for Eurobot 2009 contest edition, (ICAL 2008), 2008, 1396–1401.
and its design allows using it for other purposes too. 14. S. Basovnik, L. Mach, A. Mikulik, D. Obdrzalek: De-
Because the system has been created for 2009 edi- tecting scene elements using maximally stable colour
regions. In: Proceedings of the EUROBOT Conference
tion of Eurobot contest, we want to continue gather-
2009.
ing testing data throughout the whole year of 2009 in