<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE article PUBLIC "-//NLM//DTD Journal Publishing DTD v2.3 20070202//EN" "journalpublishing.dtd">
<article xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink" xml:lang="en" article-type="research-article">
<front>
<journal-meta>
<journal-id journal-id-type="nlm-ta">Sensors</journal-id>
<journal-title>Sensors</journal-title>
<issn pub-type="epub">1424-8220</issn>
<publisher>
<publisher-name>Molecular Diversity Preservation International (MDPI)</publisher-name></publisher></journal-meta>
<article-meta>
<article-id pub-id-type="doi">10.3390/s91210217</article-id>
<article-id pub-id-type="publisher-id">sensors-09-10217</article-id>
<article-categories>
<subj-group>
<subject>Article</subject></subj-group></article-categories>
<title-group>
<article-title>Sonar Sensor Models and Their Application to Mobile Robot Localization</article-title></title-group>
<contrib-group>
<contrib contrib-type="author">
<name><surname>Burguera</surname><given-names>Antoni</given-names></name><xref ref-type="corresp" rid="c1-sensors-09-10217"><sup>*</sup></xref></contrib>
<contrib contrib-type="author">
<name><surname>González</surname><given-names>Yolanda</given-names></name></contrib>
<contrib contrib-type="author">
<name><surname>Oliver</surname><given-names>Gabriel</given-names></name></contrib>
<aff id="af1-sensors-09-10217">Department de Matemàtiques i Informàtica, Universitat de les Illes Balears, Ctra. de Valldemosa Km. 7.5, E-07122 Palma de Mallorca, Spain; E-Mails: <email>y.gonzalez@uib.es</email> (Y.G.); <email>goliver@uib.es</email> (G.O.)</aff></contrib-group>
<author-notes>
<corresp id="c1-sensors-09-10217">
<label>*</label>Author to whom correspondence should be addressed; E-Mail: <email>antoni.burguera@uib.es</email>; Tel: +34 971 172911; Fax: +34 971 173003.</corresp></author-notes>
<pub-date pub-type="collection">
<year>2009</year></pub-date>
<pub-date pub-type="epub">
<day>17</day>
<month>12</month>
<year>2009</year></pub-date>
<volume>9</volume>
<issue>12</issue>
<fpage>10217</fpage>
<lpage>10243</lpage>
<history>
<date date-type="received">
<day>2</day>
<month>11</month>
<year>2009</year></date>
<date date-type="rev-recd">
<day>18</day>
<month>11</month>
<year>2009</year></date>
<date date-type="accepted">
<day>14</day>
<month>12</month>
<year>2009</year></date></history>
<permissions>
<copyright-statement>© 2009 by the authors; licensee Molecular Diversity Preservation International, Basel, Switzerland.</copyright-statement>
<copyright-year>2009</copyright-year>
<license>
<p>This article is an open access article distributed under the terms and conditions of the Creative Commons Attribution license (http://creativecommons.org/licenses/by/3.0/).</p></license></permissions>
<abstract>
<p>This paper presents a novel approach to mobile robot localization using sonar sensors. This approach is based on the use of particle filters. Each particle is augmented with local environment information which is updated during the mission execution. An experimental characterization of the sonar sensors used is provided in the paper. A probabilistic measurement model that takes into account the sonar uncertainties is defined according to the experimental characterization. The experimental results quantitatively evaluate the presented approach and provide a comparison with other localization strategies based on both the sonar and the laser. Some qualitative results are also provided for visual inspection.</p></abstract>
<kwd-group>
<kwd>sonar</kwd>
<kwd>mobile robot localization</kwd>
<kwd>particle filter</kwd></kwd-group></article-meta></front>
<body>
<sec sec-type="intro">
<label>1.</label>
<title>Introduction</title>
<p>A crucial requirement for a mobile robot to accomplish useful long term missions is that the robot has some knowledge about its pose with respect to a fixed reference frame. The process of estimating the robot pose with respect to such fixed reference frame is known as the <italic>localization</italic> problem. A common approach to localize the robot is the use of <italic>exteroceptive</italic> sensors, such as range finders, measuring the external environment, combined with <italic>proprioceptive</italic> sensors, such as odometers. Exteroceptive sensor data can be correlated at subsequent robot positions to compute displacement estimates, based on initial guesses provided by proprioceptive sensors.</p>
<p>The quality of the pose estimates is, consequently, strongly related to the quality of the sensor measurements. That is why localization strategies usually rely on accurate sensors such as laser range scanners. Most of these sensors are able to provide thousands of readings per second with a sub degree angular resolution. Other sensors, such as standard <italic>Time-of-Flight</italic> (TOF) ultrasonic range finders, do not have these properties. In general terms, standard ultrasonic range finders are only able to provide tenths of readings per second and have angular resolutions one or two orders of magnitude worse than laser scanners.</p>
<p>However, ultrasonic range finders are still appealing in the mobile robotics community for several reasons. Their price and power consumption are better than those of laser scanners. Moreover, their basic behavior is shared with underwater sonar, which is a sensor vastly used in underwater and marine robotics. A typical underwater sonar, although being far more complex than the ultrasonic devices used in this work, can take profit of those localization techniques accounting for the ultrasonic sensor limitations.</p>
<p>Some researchers have demonstrated the validity of standard ultrasonic range finders, like the Polaroid ultrasonic sensors, to perform localization. For instance, Tardós <italic>et al.</italic> [<xref ref-type="bibr" rid="b1-sensors-09-10217">1</xref>] used a perceptual grouping technique to identify and localize environmental features, such as corners and lines, together with robust data association to perform SLAM with sonar. Gro<italic>β</italic>mann <italic>et al.</italic> [<xref ref-type="bibr" rid="b2-sensors-09-10217">2</xref>] confronted the sonar localization problem by means of the Hough transform and probability grids to detect walls and corners.</p>
<p>However, looking for features has shown to be a complex, unreliable and time consuming task due to the noisy nature of sonar data. That is why different approaches have to be adopted when using this kind of sensors. For example, Burguera <italic>et al.</italic> [<xref ref-type="bibr" rid="b3-sensors-09-10217">3</xref>] defined the <italic>sonar probabilistic Iterative Correspondence</italic> (spIC), not requiring environmental features to be localized. They showed that scan matching localization can provide reasonably good results if sonar uncertainties are taken into account. Hernández <italic>et al.</italic> [<xref ref-type="bibr" rid="b4-sensors-09-10217">4</xref>] also proposed an approach to underwater localization using sonar without requiring environmental features. One more study is by Young-Ho Choi and Se-Young Oh [<xref ref-type="bibr" rid="b5-sensors-09-10217">5</xref>], who proposed an approach to localization using visual sonar. Although a visual sonar consists on obtaining range measurements from image data, it has comparable characteristics and poses similar problems to localization that the ultrasonic range finders.</p>
<p>Nowadays it is broadly accepted that probabilistic methods are the most promising ones to deal with sensor and pose uncertainties in real-time. In this context, Kalman filters are commonly used to perform localization and SLAM. However, they fail to represent ambiguities and to recover from localization failures. To confront some of these problems, Dellaert <italic>et al.</italic> [<xref ref-type="bibr" rid="b6-sensors-09-10217">6</xref>] introduced the <italic>Monte Carlo Localization</italic> (MCL), where the probability density function is represented by a set of samples randomly drawn from it. The set of samples, which are usually called <italic>particles</italic>, is recursively updated by means of a method generically called <italic>Particle Filter</italic>.</p>
<p>As a nonparametric implementation of Bayes filters, particle filters have two main advantages. One is that they can approximate a wide range of probability distributions. The other is that even the most straightforward implementation of them exhibits very good results when applied to localization. Particle filters have been successfully applied to SLAM [<xref ref-type="bibr" rid="b7-sensors-09-10217">7</xref>, <xref ref-type="bibr" rid="b8-sensors-09-10217">8</xref>], multi-robot localization [<xref ref-type="bibr" rid="b9-sensors-09-10217">9</xref>] and localization given an <italic>a priori</italic> map using laser [<xref ref-type="bibr" rid="b10-sensors-09-10217">10</xref>] and sonar sensors [<xref ref-type="bibr" rid="b11-sensors-09-10217">11</xref>], among other applications. One particular study by Silver <italic>et al.</italic> [<xref ref-type="bibr" rid="b12-sensors-09-10217">12</xref>] proposed the combined use of the <italic>Iterative Closest Point</italic> (ICP) scan matching [<xref ref-type="bibr" rid="b13-sensors-09-10217">13</xref>] and particle filters to deal with the sparseness and low accuracy of sonar sensors in underwater environments. Although the method was only tested in simulation, this approach does not require any <italic>a priori</italic> map and exhibits very good results. A similar approach, tested using real sonar readings, was proposed in [<xref ref-type="bibr" rid="b14-sensors-09-10217">14</xref>]. Although both approaches share some points in common with the research presented in this paper, they neither experimentally characterize the sonar sensor nor model it in any way.</p>
<p>The goal of this paper is to define, develop and experimentally evaluate an algorithm to perform MCL without <italic>a priori</italic> maps and using sonar sensors. The use of sonar sensors in this context is a relevant contribution of this paper, and is supported by an exhaustive experimental characterization of a widely spread sonar configuration.</p>
<p>More specifically, in this paper we propose the use of a probabilistic correlation technique as measurement model in a particle filter to perform mobile robot localization using sonar sensors. Each sonar reading is modeled by a bivariate Normal distribution. In order to properly model the sonar readings, an experimental characterization of the sonar sensor is performed in Section 2.. Thanks to these models, the correlation between two sets of sonar readings can be performed by means of statistical compatibility tests. The particle filter operation is described in Section 3.. Also, in this work, the particles are augmented with local environment information. This local information is updated at each time step, and allows the localization process to be performed without any <italic>a priori</italic> map. The aim of this local environment information is to deal with the sparseness of the sets of sonar readings. In Section 4. the model definition, the correlation process and the local map construction are presented. In order to validate and measure the quality of this approach, sonar and laser data has been simultaneously gathered in different environments. Using the laser readings, a ground truth has been constructed. Then, the sonar-based particle localization is evaluated by comparing its results to the ground truth. The quantitative evaluation method, as well as the experimental results evaluating different algorithm's parameters, are provided in Section 5. The experimental results show that the proposed approach to sonar-based localization is able to provide robust and accurate robot pose estimates. Finally, Section 6. concludes the paper.</p></sec>
<sec>
<label>2.</label>
<title>The Polaroid Sensor</title>
<sec>
<label>2.1.</label>
<title>Overview</title>
<p>During the 80s, Polaroid developed a TOF ultrasonic range sensor for automatic camera focusing. Different versions of these sensors appeared. The third generation was based on the 6,500 ranging module. This module had the ability to detect and report multiple echoes. Moreover, a developer's kit was released for these sensors, allowing the user to configure the different parameters, such as frequency, gain or maximum range. Because of this, the 6,500 ranging module was extensively used in mobile robotics.</p>
<p>Although the original Polaroid sensors are not being used by recent robotic platforms, the 6,500 series ranging module is still commonly used. The ultrasonic sensors used in this paper are those endowed in a <italic>Pioneer 3-DX</italic> mobile robot. They are based on the 6,500 series ranging module and a 600 series electrostatic transducer. Throughout this paper, these sensors will be referred to as the <italic>Polaroid sensors</italic>.</p>
<p>In mobile robotics, sonar sensors are commonly used to detect objects which are in the same plane that the sensor itself. This idea will be referred to as the <italic>2D assumption</italic>. Thus, only the cross section of the sonar beam over the sensor plane is going to be considered in this paper. Also, it is usual to mount the sonar sensors so that their acoustic axis is parallel to the floor. In this case, under the mentioned 2D assumption, the vertical expansion rate of the sonar beam is not taken into account.</p>
<p>Being endowed on a specific robotic platform, some of the sensor capabilities are not accessible to the user while some other are limited because of the robot configuration. For example, the multiple echo capability is not accessible by our mobile robot. Moreover, although a firing rate of 40 ms is possible, only 2 of the 16 available sensors are accessed every 40 ms. The details of our specific robotic platform are provided in [<xref ref-type="bibr" rid="b15-sensors-09-10217">15</xref>]. Those details of Polaroid sensors not depending on our specific robot platform are provided next.</p></sec>
<sec>
<label>2.2.</label>
<title>Theoretical Model</title>
<p>Let us introduce some basic notation. If the 2D assumption is performed, the position of an object with respect to the sensor can be denoted by the polar coordinates (<italic>r, θ</italic>), <italic>r</italic> being the distance to the sensor and <italic>θ</italic> the orientation with respect to the sonar acoustic axis, as illustrated in <xref ref-type="fig" rid="f1-sensors-09-10217">Figure 1a</xref>. The angle <italic>θ</italic> is also named the <italic>bearing</italic> or the <italic>azimuth</italic>. A sonar sensor will be characterized by the frequency <italic>f</italic> and the wavelength <italic>λ</italic> of the emitted ultrasonic pulse, and by the radius <italic>a</italic> of the transducer.</p>
<p>The term <italic>sound pressure</italic>, at a given point and time, refers to the difference between the pressure of the environment outside the sound wave and the pressure found within the sound wave. The sound pressure has been used by different researchers to evaluate the sensitivity of an ultrasonic sensor. For example, Kleeman and Kuc [<xref ref-type="bibr" rid="b16-sensors-09-10217">16</xref>] state that, under the 2D assumption, for an object located at (<italic>r, θ</italic>) the detected echo pressure referenced to the receiver output is given by the expression
<disp-formula id="FD1">
<label>(1)</label>
<mml:math id="mm1" display="block">
<mml:semantics id="sm1">
<mml:mrow>
<mml:mi>P</mml:mi>
<mml:mo stretchy="false">(</mml:mo>
<mml:mi>r</mml:mi>
<mml:mo>,</mml:mo>
<mml:mi>θ</mml:mi>
<mml:mo stretchy="false">)</mml:mo>
<mml:mo>=</mml:mo>
<mml:mfrac>
<mml:mrow>
<mml:mi>β</mml:mi>
<mml:mi>f</mml:mi>
<mml:msup>
<mml:mi>a</mml:mi>
<mml:mn>4</mml:mn></mml:msup></mml:mrow>
<mml:mrow>
<mml:msup>
<mml:mi>r</mml:mi>
<mml:mn>2</mml:mn></mml:msup></mml:mrow></mml:mfrac>
<mml:msup>
<mml:mrow>
<mml:mrow>
<mml:mo>(</mml:mo>
<mml:mrow>
<mml:mfrac>
<mml:mrow>
<mml:mn>2</mml:mn>
<mml:msub>
<mml:mi>J</mml:mi>
<mml:mn>1</mml:mn></mml:msub>
<mml:mo stretchy="false">(</mml:mo>
<mml:mi>k</mml:mi>
<mml:mi>a</mml:mi>
<mml:mo>sin</mml:mo>
<mml:mo stretchy="false">(</mml:mo>
<mml:mi>θ</mml:mi>
<mml:mo stretchy="false">)</mml:mo>
<mml:mo stretchy="false">)</mml:mo></mml:mrow>
<mml:mrow>
<mml:mi>k</mml:mi>
<mml:mi>a</mml:mi>
<mml:mo>sin</mml:mo>
<mml:mo stretchy="false">(</mml:mo>
<mml:mi>θ</mml:mi>
<mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:mfrac></mml:mrow>
<mml:mo>)</mml:mo></mml:mrow></mml:mrow>
<mml:mn>2</mml:mn></mml:msup></mml:mrow></mml:semantics></mml:math></disp-formula>where <italic>β</italic> is a proportionality constant used to include parameters that can not be controlled by design, <italic>k</italic> = 2<italic>π/λ</italic> and <italic>J</italic><sub>1</sub> is the Bessel function of the first kind of order 1. Let us parametrize the previous equation for the Polaroid sensors used in this paper. According to the sensor data sheet [<xref ref-type="bibr" rid="b17-sensors-09-10217">17</xref>], these sensors operate at a frequency <italic>f</italic> = 50 kHz and the transducer radius is <italic>a</italic> = 19.22 mm. Moreover, the temperature operating range is said to be from −30 °C to 70 °C. Let us assume a temperature of 20 °C, which is at the center of the temperature operating range. The speed of sound at this temperature is 343.21m/s. Thus, given the frequency <italic>f</italic> and the speed of sound, it is easy to see that <italic>λ</italic> = 6.86 mm.</p>
<p>Now, let us focus on the dependence of the echo pressure on the azimuth, assuming a constant value for <italic>r</italic>. <xref ref-type="fig" rid="f1-sensors-09-10217">Figure 1b</xref> shows the evaluation of <xref ref-type="disp-formula" rid="FD1">Equation 1</xref> with respect to the azimuth. The curve has been scaled to values between 0 and 1, to make the representation independent of the specific values of <italic>r</italic> and <italic>β.</italic> The <italic>Sound Pressure Level</italic> (SPL) is shown in <xref ref-type="fig" rid="f1-sensors-09-10217">Figure 1c</xref> in polar coordinates. The SPL expresses the relation between the sound pressure and a reference pressure as a level on a logarithmic decibel scale. The used reference pressure is the maximum pressure. Being the SPL in a logarithmic scale, some details are easier to appreciate than in the sound pressure graph.</p>
<p>The first thing to be noticed is that the sound pressure concentrates along the sonar acoustic axis. This area of high sensitivity is called the <italic>main lobe</italic>. Also, some weaker sensitivity areas appear around the azimuths ±17° and ±30°. These areas are called <italic>side lobes</italic>. More specifically, the main lobe is defined as the angular interval [−<italic>θ</italic><sub>0</sub>, <italic>θ</italic><sub>0</sub>], where <italic>θ</italic><sub>0</sub> is the lowest positive azimuth where <xref ref-type="disp-formula" rid="FD1">Equation 1</xref> equals to zero. In this case, as can be observed in <xref ref-type="fig" rid="f1-sensors-09-10217">Figure 1b</xref>, <italic>θ</italic><sub>0</sub> ≃ 12.5°. The interval [−<italic>θ</italic><sub>0</sub><italic>, θ</italic><sub>0</sub>] lies between the dashed lines in <xref ref-type="fig" rid="f1-sensors-09-10217">Figure 1c</xref>.</p>
<p>The sonar response mainly depends on the main lobe, where the most part of the signal strength is concentrated. Because of this, it is reasonable to assume that the received echoes have been produced in the main lobe and, thus, that the azimuth of the detected object lies in [−<italic>θ</italic><sub>0</sub>, <italic>θ</italic><sub>0</sub>]. Consequently, there is an azimuth uncertainty of 2<italic>θ</italic><sub>0</sub>. In the particular case of the Polaroid sensor under analysis, this theoretical azimuth uncertainty is, thus, 25°.</p>
<p>Taking into account the importance of the main lobe, it is common to model a sonar reading as the circular sector defined by the angular interval [−<italic>θ</italic><sub>0</sub>, <italic>θ</italic><sub>0</sub>] and centered at the sensor position. The sonar wedge, as defined by Moravec [<xref ref-type="bibr" rid="b18-sensors-09-10217">18</xref>], models the sonar readings in this way. The detected object is, in consequence, assumed to lie somewhere on the boundary arc of such sector. The azimuth uncertainty, 2<italic>θ</italic><sub>0</sub> is then referred to as the sensor <italic>opening</italic>. Henceforth, the sensor opening will be denoted by <italic>α</italic>, thus <italic>α</italic> = 2<italic>θ</italic><sub>0</sub>. This model, which is called the <italic>wedge model</italic>, is depicted in <xref ref-type="fig" rid="f1-sensors-09-10217">Figure 1d</xref>.</p></sec>
<sec>
<label>2.3.</label>
<title>Experimental Characterization</title>
<p>Some studies [<xref ref-type="bibr" rid="b19-sensors-09-10217">19</xref>] have shown that significant differences appear between the theoretical model, the sensor specifications and the real behavior of the sensor. Additionally, a significant amount of studies concerning sonar modeling in mobile robotics are based on experimental models [<xref ref-type="bibr" rid="b20-sensors-09-10217">20</xref>–<xref ref-type="bibr" rid="b22-sensors-09-10217">22</xref>]. Thus, we feel that an experimental evaluation of the parameters of the Polaroid sensors used in this research is necessary.</p>
<p>In order to build the sensor characterization, we have taken into account the following two aspects. First, although the sonar wedge model is widely used, it may be too simplistic. In consequence, the experiments are intended to find the limits of this model. Second, as the sensor is endowed on a specific robot platform, the usual way to access its measurements is by means of the robot's operating system. Accordingly, the characterization relies on reading the range information as it is provided by the robot's operating system under different conditions and, afterwards, comparing the gathered data to a ground truth. For the sake of simplicity, henceforth, the range readings provided by the robot's operating system from the Polaroid sensors will be referred to as, simply, the sensor (or the sonar) readings.</p>
<p>The presented analysis is based on the experimental evaluation of the following sensor parameters: resolution, minimum and maximum range, maximum angle of incidence, sensor opening and accuracy. Only the most relevant results are shown here. An exhaustive description of the evaluation procedures and the results are available in [<xref ref-type="bibr" rid="b23-sensors-09-10217">23</xref>].</p>
<p>The <italic>resolution</italic> of a sonar is the smallest change in range that it can detect. The robot's operating system provides the range information in millimeters using an integer format. Accordingly, resolutions below one millimeter are not possible under this configuration. Taking this fact into account, a calibrated sheet was used to accurately place a wooden panel and a cardboard box at different distances from the sensor, ranging from 0m to 5 m with a 0.5 m interval. At each of these distances, the wooden panel was moved, millimeter by millimeter, a distance of 10 cm. The same process was performed using the cardboard box. Also, a similar process was done by moving, millimeter by millimeter, the sensor with respect to a stone wall. At each distance, a set of 100 sonar measurements were obtained and stored.</p>
<p>From these measurements, three important details have been observed. Firstly, it has been observed that the sensor is not able to measure distances up to 5 m. Secondly, we have also observed that there is a minimum detection distance. These two aspects will be discussed later. Finally, it has been observed that the smallest range that the sensor is able to detect is one millimeter. The value is constant along the whole sensor range, and is the same for all the 16 robot sensors that have been tested and for the three aforementioned materials. Accordingly the Polaroid sensor's resolution is, when it is accessed through the robot's operating system, 1 mm. This value slightly differs from the specifications, whereas the resolution is said to be 3 mm.</p>
<p>The <italic>minimum and maximum ranges</italic> refer to the minimum and maximum distances, respectively, at which the sensor can reliably detect an object. A first approximation of these values was obtained, as mentioned earlier, when analyzing the resolution. By placing a calibrated sheet around the previously obtained rough values, it has been observed that the minimum range is 167 mm. This value slightly differs from the one specified in the data sheet, where the minimum range is said to be 150 mm. <xref ref-type="fig" rid="f2-sensors-09-10217">Figure 2a</xref> exemplifies the data obtained during the minimum range determination.</p>
<p>The maximum range is related to the sound attenuation with distance. Our experiments show a maximum range of 4,910 mm. This value significantly differs from the sensor specification, where the maximum range is said to be 10.7 m. Taking into account this large difference it is clear that this limit is imposed by the robot's manufacturer [<xref ref-type="bibr" rid="b15-sensors-09-10217">15</xref>]. Nevertheless, our observation also differs from the robot specification, where it is said that the maximum range is 5 m. Being this maximum range intentionally reduced by the robot's operating system, it does not depend on the material being detected and is exactly the same for all of the 16 tested sensors. <xref ref-type="fig" rid="f2-sensors-09-10217">Figure 2b</xref> exemplifies the data obtained during the maximum range determination.</p>
<p>The angle of incidence is defined as the angle between the sonar acoustic axis and the perpendicular to the detected object. The <italic>maximum angle of incidence</italic> refers to the maximum value for the angle of incidence producing a reliable range measurement. We have observed that this parameter is related to the material of the detected object. Broadly speaking, flat surfaces are likely to specularly reflect the most part of the ultrasonic energy and produce a low maximum angle of incidence. To the contrary, rough surfaces tend to reflect the ultrasonic pulse in scattered directions, thus providing larger values for this parameter. For example, the maximum angle of incidence with respect to an object located 1m away from the sensor is 81° if the object if a rough stone wall but only 16° if the object is a flat wooden panel.</p>
<p>As stated previously, the term <italic>opening</italic> refers to the azimuth interval at which the sensor is able to detect an object. The opening has been traditionally related to the main lobe of the SPL pattern. In order to take also into account the effects of the side lobes, as well as to test the limits of the sonar wedge model, the opening has been evaluated for different ranges. Being the maximum range 4,910 mm, we have measured the sensor opening for distances of 0.5, 1.5, 2, 2.5, 3, 3.5, 4 and 4.5 m. The results, as well as a graphical representation, are summarized in <xref ref-type="fig" rid="f3-sensors-09-10217">Figure 3a</xref>.</p>
<p>It can be observed how the opening is not constant. For the short range of 0.5 m, the measured opening is significantly larger than the theoretical value. This is likely to be produced by the side lobes. For large ranges the obtained opening is significantly below the theoretical value, which is probably due to the attenuation of the sound with distance.</p>
<p>The term <italic>accuracy</italic> refers to the deviation of the obtained measurements from the actual ranges. We have observed that short range readings are more accurate than the long range ones. Thus, we have measured the accuracy as a function of the range. In order to measure this parameter, sets of 500 readings each have been gathered around actual ranges of 0.5, 1, 1.5, 2, 2.5, 3, 3.5, 4, 4.5 and 4.91 m. The last range is 4.91 m, instead of 5 m, because the maximum range has been found to be 4,910 mm.</p>
<p>The errors between the actual and the measured ranges have been computed. The mean and the standard deviation of these errors are shown in <xref ref-type="fig" rid="f3-sensors-09-10217">Figure 3b</xref>. It can be observed how the mean and the standard deviation of the errors tend to increase with distance.</p>
<p>The obtained sensor characterization will be used in Section 4. to build the measurement model for MCL.</p></sec></sec>
<sec>
<label>3.</label>
<title>The Sonar Monte Carlo Localization Approach</title>
<sec>
<label>3.1.</label>
<title>Overview and Notation</title>
<p>Bayes filters address the problem of estimating the state <italic>x<sub>t</sub></italic> of a dynamical system from the sensor measurements. The robot's internal knowledge about this state is usually called the <italic>belief</italic>, and is represented by <italic>bel</italic>(<italic>x<sub>t</sub></italic>), where the subindex <italic>t</italic> depicts the time step. Particle filters are implementations of the Bayes filter that represent the belief by a set <italic>X<sub>t</sub></italic> of weighted random samples, called particles, which are distributed according to the belief itself. At time <italic>t</italic>, the particle set is updated by means of the control vector <italic>u<sub>t</sub></italic> and the sensor measurements <italic>z<sub>t</sub></italic>. In the context of this paper, <italic>u<sub>t</sub></italic> corresponds to the robot odometric data and the <italic>z<sub>t</sub></italic> are the sonar readings. Given that this paper is centered on the localization problem, the state to be estimated is the robot pose.</p>
<p>The use of particle filters in localization has centered the attention of the localization community since their introduction in this context. Dellaert <italic>et al.</italic> [<xref ref-type="bibr" rid="b6-sensors-09-10217">6</xref>] and Fox <italic>et al.</italic> [<xref ref-type="bibr" rid="b24-sensors-09-10217">24</xref>] defined the term MCL to refer, precisely, to those localization techniques based on particle filters. The instantiation of the MCL to the sonar context will be referred to as <italic>sonar Monte Carlo Localization</italic> (sMCL) throughout this paper. The particularities of sMCL with respect to the standard MCL approach will also be pointed out here. Let the set of particles at time step <italic>t</italic> be defined as follows:
<disp-formula id="FD2">
<label>(2)</label>
<mml:math id="mm2" display="block">
<mml:semantics id="sm2">
<mml:mrow>
<mml:msub>
<mml:mi>X</mml:mi>
<mml:mi>t</mml:mi></mml:msub>
<mml:mo>=</mml:mo>
<mml:mrow>
<mml:mo stretchy="false">{</mml:mo>
<mml:mrow>
<mml:mrow>
<mml:mo stretchy="false">(</mml:mo>
<mml:mrow>
<mml:msubsup>
<mml:mi>x</mml:mi>
<mml:mi>t</mml:mi>
<mml:mrow>
<mml:mo stretchy="false">[</mml:mo>
<mml:mi>m</mml:mi>
<mml:mo stretchy="false">]</mml:mo></mml:mrow></mml:msubsup>
<mml:mo>,</mml:mo>
<mml:msubsup>
<mml:mi>w</mml:mi>
<mml:mi>t</mml:mi>
<mml:mrow>
<mml:mo stretchy="false">[</mml:mo>
<mml:mi>m</mml:mi>
<mml:mo stretchy="false">]</mml:mo></mml:mrow></mml:msubsup>
<mml:mo>,</mml:mo>
<mml:msubsup>
<mml:mi>s</mml:mi>
<mml:mi>t</mml:mi>
<mml:mrow>
<mml:mo stretchy="false">[</mml:mo>
<mml:mi>m</mml:mi>
<mml:mo stretchy="false">]</mml:mo></mml:mrow></mml:msubsup></mml:mrow>
<mml:mo stretchy="false">)</mml:mo></mml:mrow>
<mml:mo>,</mml:mo>
<mml:mn>1</mml:mn>
<mml:mo>≤</mml:mo>
<mml:mi>m</mml:mi>
<mml:mo>≤</mml:mo>
<mml:mi>M</mml:mi></mml:mrow>
<mml:mo stretchy="false">}</mml:mo></mml:mrow></mml:mrow></mml:semantics></mml:math></disp-formula>where <italic>M</italic> is the number of particles. Each 
<inline-formula>
<mml:math id="mm3">
<mml:semantics id="sm3">
<mml:mrow>
<mml:msubsup>
<mml:mi>x</mml:mi>
<mml:mi>t</mml:mi>
<mml:mrow>
<mml:mo stretchy="false">[</mml:mo>
<mml:mi>m</mml:mi>
<mml:mo stretchy="false">]</mml:mo></mml:mrow></mml:msubsup></mml:mrow></mml:semantics></mml:math></inline-formula> is a concrete instantiation of the robot pose at time <italic>t</italic>. Under the 2D assumption <italic>x<sub>t</sub></italic> is a three dimensional vector of the form [<italic>x, y, θ</italic>]<italic><sup>T</sup></italic>, representing the robot position and orientation. Each representing the robot position and orientation. Each 
<inline-formula>
<mml:math id="mm4">
<mml:semantics id="sm4">
<mml:mrow>
<mml:msubsup>
<mml:mi>w</mml:mi>
<mml:mi>t</mml:mi>
<mml:mrow>
<mml:mo stretchy="false">[</mml:mo>
<mml:mi>m</mml:mi>
<mml:mo stretchy="false">]</mml:mo></mml:mrow></mml:msubsup></mml:mrow></mml:semantics></mml:math></inline-formula> is the particle importance factor or weight, so that, ideally, 
<inline-formula>
<mml:math id="mm5">
<mml:semantics id="sm5">
<mml:mrow>
<mml:msubsup>
<mml:mi>w</mml:mi>
<mml:mi>t</mml:mi>
<mml:mrow>
<mml:mo stretchy="false">[</mml:mo>
<mml:mi>m</mml:mi>
<mml:mo stretchy="false">]</mml:mo></mml:mrow></mml:msubsup>
<mml:mo>=</mml:mo>
<mml:mi>p</mml:mi>
<mml:mrow>
<mml:mo>(</mml:mo>
<mml:mrow>
<mml:msub>
<mml:mi>z</mml:mi>
<mml:mi>t</mml:mi></mml:msub>
<mml:mo stretchy="false">|</mml:mo>
<mml:msubsup>
<mml:mi>x</mml:mi>
<mml:mi>t</mml:mi>
<mml:mrow>
<mml:mo stretchy="false">[</mml:mo>
<mml:mi>m</mml:mi>
<mml:mo stretchy="false">]</mml:mo></mml:mrow></mml:msubsup></mml:mrow>
<mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:mrow></mml:semantics></mml:math></inline-formula>.</p>
<p>The term 
<inline-formula>
<mml:math id="mm6">
<mml:semantics id="sm6">
<mml:mrow>
<mml:msubsup>
<mml:mi>s</mml:mi>
<mml:mi>t</mml:mi>
<mml:mrow>
<mml:mo stretchy="false">[</mml:mo>
<mml:mi>m</mml:mi>
<mml:mo stretchy="false">]</mml:mo></mml:mrow></mml:msubsup></mml:mrow></mml:semantics></mml:math></inline-formula> denotes the particle's local map. This local map is a short history of the most recent <italic>k</italic> sets of sonar readings represented with respect to a coordinate frame located at 
<inline-formula>
<mml:math id="mm7">
<mml:semantics id="sm7">
<mml:mrow>
<mml:msubsup>
<mml:mi>x</mml:mi>
<mml:mi>t</mml:mi>
<mml:mrow>
<mml:mo stretchy="false">[</mml:mo>
<mml:mi>m</mml:mi>
<mml:mo stretchy="false">]</mml:mo></mml:mrow></mml:msubsup></mml:mrow></mml:semantics></mml:math></inline-formula>. The use of 
<inline-formula>
<mml:math id="mm8">
<mml:semantics id="sm8">
<mml:mrow>
<mml:msubsup>
<mml:mi>s</mml:mi>
<mml:mi>t</mml:mi>
<mml:mrow>
<mml:mo stretchy="false">[</mml:mo>
<mml:mi>m</mml:mi>
<mml:mo stretchy="false">]</mml:mo></mml:mrow></mml:msubsup></mml:mrow></mml:semantics></mml:math></inline-formula> and its on-line building are two of the particularities of the sMCL approach that make the localization process not dependant on <italic>a priori</italic> maps. A description of how this history is built and used is presented in Section 4.</p>
<p>Let 
<inline-formula>
<mml:math id="mm9">
<mml:semantics id="sm9">
<mml:mrow>
<mml:msubsup>
<mml:mover accent="true">
<mml:mi>x</mml:mi>
<mml:mo>¯</mml:mo></mml:mover>
<mml:mi>t</mml:mi>
<mml:mrow>
<mml:mo stretchy="false">[</mml:mo>
<mml:mi>m</mml:mi>
<mml:mo stretchy="false">]</mml:mo></mml:mrow></mml:msubsup></mml:mrow></mml:semantics></mml:math></inline-formula> denote the relative robot displacement and rotation from time <italic>t</italic> − 1 to time <italic>t</italic> according to the particle <italic>m</italic>. Finally, let the operators ⊖ and ⊕ denote the inversion and the compounding transformations. The operator ⊕ will be used with two additions with respect to the one introduced by Smith <italic>et al.</italic> [<xref ref-type="bibr" rid="b25-sensors-09-10217">25</xref>]. First, if the right-hand operand is a point, ⊕ is used to transform the reference of the point [<xref ref-type="bibr" rid="b1-sensors-09-10217">1</xref>]. Second, if the right-hand operand is a set of points, the operator is applied individually to each point and, thus, it returns the resulting set of points.</p>
<p>Finally, let the superindex [1 : <italic>M</italic>] denote all the particles. For instance, 
<inline-formula>
<mml:math id="mm10">
<mml:semantics id="sm10">
<mml:mrow>
<mml:msubsup>
<mml:mi>x</mml:mi>
<mml:mi>t</mml:mi>
<mml:mrow>
<mml:mo stretchy="false">[</mml:mo>
<mml:mn>1</mml:mn>
<mml:mo>:</mml:mo>
<mml:mi>M</mml:mi>
<mml:mo stretchy="false">]</mml:mo></mml:mrow></mml:msubsup></mml:mrow></mml:semantics></mml:math></inline-formula>, represents the poses of all particles at time <italic>t</italic>, and 
<inline-formula>
<mml:math id="mm11">
<mml:semantics id="sm11">
<mml:mrow>
<mml:msubsup>
<mml:mi>s</mml:mi>
<mml:mi>t</mml:mi>
<mml:mrow>
<mml:mo stretchy="false">[</mml:mo>
<mml:mn>1</mml:mn>
<mml:mo>:</mml:mo>
<mml:mi>M</mml:mi>
<mml:mo stretchy="false">]</mml:mo></mml:mrow></mml:msubsup></mml:mrow></mml:semantics></mml:math></inline-formula> denote all the local maps at time <italic>t</italic>.</p>
<p><xref ref-type="fig" rid="f4-sensors-09-10217">Figure 4</xref> summarizes the notation used throughout this paper.</p></sec>
<sec>
<label>3.2.</label>
<title>Initialization</title>
<p>Particle filters build the particle set <italic>X<sub>t</sub></italic> recursively from the particle set <italic>X<sub>t</sub></italic><sub>−1</sub> one time step earlier. Thus, it is necessary to initialize the recursion by defining <italic>X</italic><sub>0</sub>. In general, this initialization only involves the initial population of the state space. For instance, if global localization has to be performed, the initialization usually consists on distributing the particles over the empty regions of the global map randomly according to a uniform distribution. To the contrary, if pose tracking is the goal, the whole particle set can be initialized to the starting robot pose, which is commonly assumed to be [0,0,0]<italic><sup>T</sup></italic>. Although our proposal lies in the pose tracking category, the initialization also involves building the initial local maps 
<inline-formula>
<mml:math id="mm12">
<mml:semantics id="sm12">
<mml:mrow>
<mml:msubsup>
<mml:mi>s</mml:mi>
<mml:mi>t</mml:mi>
<mml:mrow>
<mml:mo stretchy="false">[</mml:mo>
<mml:mi>m</mml:mi>
<mml:mo stretchy="false">]</mml:mo></mml:mrow></mml:msubsup></mml:mrow></mml:semantics></mml:math></inline-formula>.</p>
<p>In order to initialize the particle set, including the local maps, the robot has to move during <italic>k</italic> time steps and compute its pose using some external method such as odometry. Then, the robot pose 
<inline-formula>
<mml:math id="mm13">
<mml:semantics id="sm13">
<mml:mrow>
<mml:msubsup>
<mml:mi>x</mml:mi>
<mml:mn>0</mml:mn>
<mml:mrow>
<mml:mo stretchy="false">[</mml:mo>
<mml:mn>1</mml:mn>
<mml:mo>:</mml:mo>
<mml:mi>M</mml:mi>
<mml:mo stretchy="false">]</mml:mo></mml:mrow></mml:msubsup></mml:mrow></mml:semantics></mml:math></inline-formula> for all particles is set to the mentioned odometric estimate. Also, during the initialization, <italic>k</italic> sets of sonar readings are gathered and represented with respect to 
<inline-formula>
<mml:math id="mm14">
<mml:semantics id="sm14">
<mml:mrow>
<mml:msubsup>
<mml:mi>x</mml:mi>
<mml:mn>0</mml:mn>
<mml:mrow>
<mml:mo stretchy="false">[</mml:mo>
<mml:mn>1</mml:mn>
<mml:mo>:</mml:mo>
<mml:mi>M</mml:mi>
<mml:mo stretchy="false">]</mml:mo></mml:mrow></mml:msubsup></mml:mrow></mml:semantics></mml:math></inline-formula> based on odometric information. The history for all particles 
<inline-formula>
<mml:math id="mm15">
<mml:semantics id="sm15">
<mml:mrow>
<mml:msubsup>
<mml:mi>s</mml:mi>
<mml:mn>0</mml:mn>
<mml:mrow>
<mml:mo stretchy="false">[</mml:mo>
<mml:mn>1</mml:mn>
<mml:mo>:</mml:mo>
<mml:mi>M</mml:mi>
<mml:mo stretchy="false">]</mml:mo></mml:mrow></mml:msubsup></mml:mrow></mml:semantics></mml:math></inline-formula> is then set to the mentioned <italic>k</italic> sets of sonar readings. Also, if necessary, the whole set of particles could be initialized by means of a more complex motion model, such as those described in [<xref ref-type="bibr" rid="b26-sensors-09-10217">26</xref>].</p>
<p>According to the described initialization process, the value of <italic>k</italic>, which represents the size of each local map, also determines the duration of the initialization phase. The influence of this initial dependence on odometry on the overall particle filter operation is bounded. Different values of <italic>k</italic> will be experimentally tested in Section 5. Just as an example, let us consider the case <italic>k</italic> = 100. According to the experimental results, this is a reasonable value for the local map size. Also, our robotic platform provides a time step of 100ms. In this case, the robot has to solely rely on odometry during the first 10s of operation. In order to reduce the negative effects of this initial dependence on dead reckoning, the robot motion during the initialization process could be intentionally defined to minimize the odometric error. Nonetheless, the experimental results suggest that there is no need to force such specific motion during the initialization.</p>
<p>Although having to rely on dead reckoning during 10 s may seem a long time, it is important to emphasize that this initialization is needed because of the low Polaroid's sensing rate, which is, under the described robot configuration, close to 50 range measurements per second. When compared to other sensors, such as standard laser range finders, which provide thousands of readings per second, the need for a few seconds initialization time becomes clear. A similar issue is found in other studies such as [<xref ref-type="bibr" rid="b1-sensors-09-10217">1</xref>] or [<xref ref-type="bibr" rid="b4-sensors-09-10217">4</xref>], where more than 10 seconds are required to gather enough sonar data to perform localization.</p></sec>
<sec>
<label>3.3.</label>
<title>The Particle Filter</title>
<p>When the initialization has been performed, the particle filter is ready to start. The proposed particle filter implementation is shown in Algorithm 1. Next, the particularities of this algorithm and the main differences with respect to the standard particle filtering approach are described.</p>
<p>Line 3 is in charge of sampling from the motion model. In general, the motion model involves sampling from the distribution <italic>p</italic>(<italic>x<sub>t</sub></italic>∣<italic>x<sub>t</sub></italic> <sub>− 1</sub>, <italic>u<sub>t</sub></italic>). Different algorithms to perform such sampling exist in the literature [<xref ref-type="bibr" rid="b26-sensors-09-10217">26</xref>]. These algorithms rely on some parameters which have to be experimentally tuned for each specific robotic platform. However, sampling from the aforementioned distribution is only necessary if global localization has to be performed. Being this study focused on pose tracking, we propose an alternative motion model which is computationally cheaper and allows the use of simpler error models. Our proposal is to sample from the posterior over local robot poses and use the compounding operator to build the final particle set. Thus, line 3 generates hypothetical robot motions 
<inline-formula>
<mml:math id="mm16">
<mml:semantics id="sm16">
<mml:mrow>
<mml:msubsup>
<mml:mover accent="true">
<mml:mi>x</mml:mi>
<mml:mo>¯</mml:mo></mml:mover>
<mml:mi>t</mml:mi>
<mml:mrow>
<mml:mo stretchy="false">[</mml:mo>
<mml:mi>m</mml:mi>
<mml:mo stretchy="false">]</mml:mo></mml:mrow></mml:msubsup></mml:mrow></mml:semantics></mml:math></inline-formula> from time <italic>t</italic> − 1 to time <italic>t</italic>. It is important to emphasize that 
<inline-formula>
<mml:math id="mm17">
<mml:semantics id="sm17">
<mml:mrow>
<mml:msubsup>
<mml:mover accent="true">
<mml:mi>x</mml:mi>
<mml:mo>¯</mml:mo></mml:mover>
<mml:mi>t</mml:mi>
<mml:mrow>
<mml:mo stretchy="false">[</mml:mo>
<mml:mi>m</mml:mi>
<mml:mo stretchy="false">]</mml:mo></mml:mrow></mml:msubsup></mml:mrow></mml:semantics></mml:math></inline-formula> does not depend on 
<inline-formula>
<mml:math id="mm18">
<mml:semantics id="sm18">
<mml:mrow>
<mml:msubsup>
<mml:mi>x</mml:mi>
<mml:mrow>
<mml:mi>t</mml:mi>
<mml:mo>−</mml:mo>
<mml:mn>1</mml:mn></mml:mrow>
<mml:mrow>
<mml:mo stretchy="false">[</mml:mo>
<mml:mi>m</mml:mi>
<mml:mo stretchy="false">]</mml:mo></mml:mrow></mml:msubsup></mml:mrow></mml:semantics></mml:math></inline-formula> because it represents a relative motion, not the global robot pose. Thus, this step involves sampling from the distribution <italic>p(x̄<sub>t</sub></italic>∣<italic>u<sub>t</sub></italic>), where <italic>x̄<sub>t</sub></italic> represents a robot motion from time step <italic>t</italic> − 1 to time step <italic>t</italic>. In general, the robot motion from time step <italic>t</italic> − 1 and time step <italic>t</italic> is so small that the mentioned distribution can be approximated by a Normal. In the performed experiments, the robot moved less than 2 cm between two time steps, which is a reasonably small distance to perform the Normal approximation. Moreover, in some cases, such as the one of a differential drive robot, the motion model is linear with the wheel velocities, making the Normal assumption even more feasible. Thus, our proposal for the motion model is to randomly generate the 
<inline-formula>
<mml:math id="mm19">
<mml:semantics id="sm19">
<mml:mrow>
<mml:msubsup>
<mml:mover accent="true">
<mml:mi>x</mml:mi>
<mml:mo>¯</mml:mo></mml:mover>
<mml:mi>t</mml:mi>
<mml:mrow>
<mml:mo stretchy="false">[</mml:mo>
<mml:mi>m</mml:mi>
<mml:mo stretchy="false">]</mml:mo></mml:mrow></mml:msubsup></mml:mrow></mml:semantics></mml:math></inline-formula> according to a Normal <italic>N</italic>(<italic>μ, P</italic>). The mean, <italic>μ</italic>, can be obtained from a kinematic model of the robot. The covariance has to be obtained experimentally. However, the obtention of such covariance is easier than the obtention of the parameters involved in the algorithms to sample from <italic>p</italic> (<italic>x<sub>t</sub></italic>∣<italic>x<sub>t</sub></italic><sub>−1</sub><italic>, u<sub>t</sub></italic>).</p>
<array>
<tbody>
<tr>
<td align="left" valign="top" colspan="2"><bold>Algorithm 1:</bold> The Particle Filter algorithm.</td></tr>
<tr>
<td align="left" valign="top" colspan="2">
<mml:math id="mm20">
<mml:semantics id="sm20">
<mml:mrow>
<mml:mtext mathvariant="bold">Input</mml:mtext>
<mml:mo>:</mml:mo>
<mml:mrow>
<mml:mo>{</mml:mo>
<mml:mrow>
<mml:mtable columnalign="left">
<mml:mtr columnalign="left">
<mml:mtd columnalign="left">
<mml:mrow>
<mml:mi>M</mml:mi>
<mml:mo>:</mml:mo></mml:mrow></mml:mtd>
<mml:mtd>
<mml:mrow>
<mml:mtext>Number of particles</mml:mtext></mml:mrow></mml:mtd></mml:mtr>
<mml:mtr columnalign="left">
<mml:mtd>
<mml:mrow>
<mml:msub>
<mml:mi>X</mml:mi>
<mml:mrow>
<mml:mi>t</mml:mi>
<mml:mo>−</mml:mo>
<mml:mn>1</mml:mn></mml:mrow></mml:msub>
<mml:mo>:</mml:mo></mml:mrow></mml:mtd>
<mml:mtd>
<mml:mrow>
<mml:mtext>Particle set</mml:mtext>
<mml:mrow>
<mml:mo stretchy="false">{</mml:mo>
<mml:mrow>
<mml:mo stretchy="false">(</mml:mo>
<mml:msubsup>
<mml:mi>x</mml:mi>
<mml:mrow>
<mml:mi>t</mml:mi>
<mml:mo>−</mml:mo>
<mml:mn>1</mml:mn></mml:mrow>
<mml:mrow>
<mml:mo stretchy="false">[</mml:mo>
<mml:mn>1</mml:mn>
<mml:mo>:</mml:mo>
<mml:mi>M</mml:mi>
<mml:mo stretchy="false">]</mml:mo></mml:mrow></mml:msubsup>
<mml:mo>,</mml:mo>
<mml:msubsup>
<mml:mi>w</mml:mi>
<mml:mrow>
<mml:mi>t</mml:mi>
<mml:mo>−</mml:mo>
<mml:mn>1</mml:mn></mml:mrow>
<mml:mrow>
<mml:mo stretchy="false">[</mml:mo>
<mml:mn>1</mml:mn>
<mml:mo>:</mml:mo>
<mml:mi>M</mml:mi>
<mml:mo stretchy="false">]</mml:mo></mml:mrow></mml:msubsup>
<mml:mo>,</mml:mo>
<mml:msubsup>
<mml:mi>s</mml:mi>
<mml:mrow>
<mml:mi>t</mml:mi>
<mml:mo>−</mml:mo>
<mml:mn>1</mml:mn></mml:mrow>
<mml:mrow>
<mml:mo stretchy="false">[</mml:mo>
<mml:mn>1</mml:mn>
<mml:mo>:</mml:mo>
<mml:mi>M</mml:mi>
<mml:mo stretchy="false">]</mml:mo></mml:mrow></mml:msubsup>
<mml:mo stretchy="false">)</mml:mo></mml:mrow>
<mml:mo stretchy="false">}</mml:mo></mml:mrow></mml:mrow></mml:mtd></mml:mtr>
<mml:mtr>
<mml:mtd>
<mml:mrow>
<mml:msub>
<mml:mi>u</mml:mi>
<mml:mi>t</mml:mi></mml:msub>
<mml:mo>:</mml:mo></mml:mrow></mml:mtd>
<mml:mtd>
<mml:mrow>
<mml:mtext>Odometry</mml:mtext></mml:mrow></mml:mtd></mml:mtr>
<mml:mtr>
<mml:mtd>
<mml:mrow>
<mml:msub>
<mml:mi>z</mml:mi>
<mml:mi>t</mml:mi></mml:msub>
<mml:mo>:</mml:mo></mml:mrow></mml:mtd>
<mml:mtd>
<mml:mrow>
<mml:mtext>Sonar readings</mml:mtext></mml:mrow></mml:mtd></mml:mtr></mml:mtable></mml:mrow></mml:mrow></mml:mrow></mml:semantics></mml:math></td></tr>
<tr>
<td align="left" valign="top" colspan="2">
<mml:math id="mm21">
<mml:semantics id="sm21">
<mml:mrow>
<mml:mtext mathvariant="bold">Output</mml:mtext>
<mml:mo>:</mml:mo>
<mml:mrow>
<mml:mo stretchy="false">{</mml:mo>
<mml:mrow>
<mml:mtable>
<mml:mtr>
<mml:mtd>
<mml:mrow>
<mml:msub>
<mml:mi>X</mml:mi>
<mml:mi>t</mml:mi></mml:msub>
<mml:mo>:</mml:mo></mml:mrow></mml:mtd>
<mml:mtd>
<mml:mrow>
<mml:mtext>Particle set</mml:mtext>
<mml:mrow>
<mml:mo stretchy="false">{</mml:mo>
<mml:mrow>
<mml:mo stretchy="false">(</mml:mo>
<mml:msubsup>
<mml:mi>x</mml:mi>
<mml:mi>t</mml:mi>
<mml:mrow>
<mml:mo stretchy="false">[</mml:mo>
<mml:mn>1</mml:mn>
<mml:mo>:</mml:mo>
<mml:mi>M</mml:mi>
<mml:mo stretchy="false">]</mml:mo></mml:mrow></mml:msubsup>
<mml:mo>,</mml:mo>
<mml:msubsup>
<mml:mi>w</mml:mi>
<mml:mi>t</mml:mi>
<mml:mrow>
<mml:mo stretchy="false">[</mml:mo>
<mml:mn>1</mml:mn>
<mml:mo>:</mml:mo>
<mml:mi>M</mml:mi>
<mml:mo stretchy="false">]</mml:mo></mml:mrow></mml:msubsup>
<mml:mo>,</mml:mo>
<mml:msubsup>
<mml:mi>s</mml:mi>
<mml:mi>t</mml:mi>
<mml:mrow>
<mml:mo stretchy="false">[</mml:mo>
<mml:mn>1</mml:mn>
<mml:mo>:</mml:mo>
<mml:mi>M</mml:mi>
<mml:mo stretchy="false">]</mml:mo></mml:mrow></mml:msubsup>
<mml:mo stretchy="false">)</mml:mo></mml:mrow>
<mml:mo stretchy="false">}</mml:mo></mml:mrow></mml:mrow></mml:mtd></mml:mtr></mml:mtable></mml:mrow></mml:mrow></mml:mrow></mml:semantics></mml:math></td></tr>
<tr>
<td align="right" valign="top"><bold>1</bold></td>
<td align="left" valign="top"><bold>begin</bold></td></tr>
<tr>
<td align="right" valign="top"><bold>2</bold></td>
<td align="left" valign="top"> <bold>for</bold> <italic>m</italic> → 1 <bold>to</bold> <italic>M</italic> <bold>do</bold></td></tr>
<tr>
<td align="right" valign="top"><bold>3</bold></td>
<td align="left" valign="top">  
<mml:math id="mm22">
<mml:semantics id="sm22">
<mml:mrow>
<mml:msubsup>
<mml:mover accent="true">
<mml:mi>x</mml:mi>
<mml:mo>¯</mml:mo></mml:mover>
<mml:mi>t</mml:mi>
<mml:mrow>
<mml:mo stretchy="false">[</mml:mo>
<mml:mi>m</mml:mi>
<mml:mo stretchy="false">]</mml:mo></mml:mrow></mml:msubsup>
<mml:mo>←</mml:mo>
<mml:mtext>sample motion model</mml:mtext>
<mml:mo stretchy="false">(</mml:mo>
<mml:msub>
<mml:mi>u</mml:mi>
<mml:mi>t</mml:mi></mml:msub>
<mml:mrow>
<mml:mo stretchy="false">)</mml:mo>
<mml:mo>;</mml:mo></mml:mrow></mml:mrow></mml:semantics></mml:math></td></tr>
<tr>
<td align="right" valign="top"><bold>4</bold></td>
<td align="left" valign="top">  
<mml:math id="mm23">
<mml:semantics id="sm23">
<mml:mrow>
<mml:msubsup>
<mml:mi>w</mml:mi>
<mml:mi>t</mml:mi>
<mml:mrow>
<mml:mo stretchy="false">[</mml:mo>
<mml:mi>m</mml:mi>
<mml:mo stretchy="false">]</mml:mo></mml:mrow></mml:msubsup>
<mml:mo>←</mml:mo>
<mml:mtext>measurement model</mml:mtext>
<mml:mo stretchy="false">(</mml:mo>
<mml:msub>
<mml:mi>z</mml:mi>
<mml:mi>t</mml:mi></mml:msub>
<mml:mo>,</mml:mo>
<mml:msubsup>
<mml:mover accent="true">
<mml:mi>x</mml:mi>
<mml:mo>¯</mml:mo></mml:mover>
<mml:mi>t</mml:mi>
<mml:mrow>
<mml:mo stretchy="false">[</mml:mo>
<mml:mi>m</mml:mi>
<mml:mo stretchy="false">]</mml:mo></mml:mrow></mml:msubsup>
<mml:mo>,</mml:mo>
<mml:msubsup>
<mml:mi>s</mml:mi>
<mml:mrow>
<mml:mi>t</mml:mi>
<mml:mo>−</mml:mo>
<mml:mn>1</mml:mn></mml:mrow>
<mml:mrow>
<mml:mo stretchy="false">[</mml:mo>
<mml:mi>m</mml:mi>
<mml:mo stretchy="false">]</mml:mo></mml:mrow></mml:msubsup>
<mml:mrow>
<mml:mo stretchy="false">)</mml:mo>
<mml:mo>;</mml:mo></mml:mrow></mml:mrow></mml:semantics></mml:math></td></tr>
<tr>
<td align="right" valign="top"><bold>5</bold></td>
<td align="left" valign="top"> <bold>endfor</bold></td></tr>
<tr>
<td align="right" valign="top"><bold>6</bold></td>
<td align="left" valign="top"> <bold>for</bold> <italic>m</italic> ← 1 <bold>to</bold> <italic>M</italic> <bold>do</bold></td></tr>
<tr>
<td align="right" valign="top"><bold>7</bold></td>
<td align="left" valign="top">  draw <italic>i</italic> with probability 
<mml:math id="mm24">
<mml:semantics id="sm24">
<mml:mrow>
<mml:msubsup>
<mml:mi>w</mml:mi>
<mml:mi>t</mml:mi>
<mml:mrow>
<mml:mo stretchy="false">[</mml:mo>
<mml:mi>i</mml:mi>
<mml:mo stretchy="false">]</mml:mo></mml:mrow></mml:msubsup>
<mml:mo>;</mml:mo></mml:mrow></mml:semantics></mml:math></td></tr>
<tr>
<td align="right" valign="top"><bold>8</bold></td>
<td align="left" valign="top">  
<mml:math id="mm25">
<mml:semantics id="sm25">
<mml:mrow>
<mml:msubsup>
<mml:mi>x</mml:mi>
<mml:mi>t</mml:mi>
<mml:mrow>
<mml:mo stretchy="false">[</mml:mo>
<mml:mi>i</mml:mi>
<mml:mo stretchy="false">]</mml:mo></mml:mrow></mml:msubsup>
<mml:mo>←</mml:mo>
<mml:msubsup>
<mml:mi>x</mml:mi>
<mml:mrow>
<mml:mi>t</mml:mi>
<mml:mo>−</mml:mo>
<mml:mn>1</mml:mn></mml:mrow>
<mml:mrow>
<mml:mo stretchy="false">[</mml:mo>
<mml:mi>i</mml:mi>
<mml:mo stretchy="false">]</mml:mo></mml:mrow></mml:msubsup>
<mml:mo>⊕</mml:mo>
<mml:msubsup>
<mml:mover accent="true">
<mml:mi>x</mml:mi>
<mml:mo>¯</mml:mo></mml:mover>
<mml:mi>t</mml:mi>
<mml:mrow>
<mml:mo stretchy="false">[</mml:mo>
<mml:mi>i</mml:mi>
<mml:mo stretchy="false">]</mml:mo></mml:mrow></mml:msubsup>
<mml:mrow>
<mml:mo>;</mml:mo></mml:mrow></mml:mrow></mml:semantics></mml:math></td></tr>
<tr>
<td align="right" valign="top"><bold>9</bold></td>
<td align="left" valign="top">  
<mml:math id="mm26" display="block">
<mml:semantics id="sm26">
<mml:mrow>
<mml:msubsup>
<mml:mi>s</mml:mi>
<mml:mi>t</mml:mi>
<mml:mrow>
<mml:mo stretchy="false">[</mml:mo>
<mml:mi>i</mml:mi>
<mml:mo stretchy="false">]</mml:mo></mml:mrow></mml:msubsup>
<mml:mo>←</mml:mo>
<mml:mtext>update history</mml:mtext>
<mml:mo stretchy="false">(</mml:mo>
<mml:msubsup>
<mml:mi>s</mml:mi>
<mml:mrow>
<mml:mi>t</mml:mi>
<mml:mo>−</mml:mo>
<mml:mn>1</mml:mn></mml:mrow>
<mml:mrow>
<mml:mo stretchy="false">[</mml:mo>
<mml:mi>i</mml:mi>
<mml:mo stretchy="false">]</mml:mo></mml:mrow></mml:msubsup>
<mml:mo stretchy="false">,</mml:mo>
<mml:msub>
<mml:mi>z</mml:mi>
<mml:mi>t</mml:mi></mml:msub>
<mml:mo>,</mml:mo>
<mml:msubsup>
<mml:mover accent="true">
<mml:mi>x</mml:mi>
<mml:mo>¯</mml:mo></mml:mover>
<mml:mi>t</mml:mi>
<mml:mrow>
<mml:mo stretchy="false">[</mml:mo>
<mml:mi>i</mml:mi>
<mml:mo stretchy="false">]</mml:mo></mml:mrow></mml:msubsup>
<mml:mrow>
<mml:mo stretchy="false">)</mml:mo>
<mml:mo>;</mml:mo></mml:mrow></mml:mrow></mml:semantics></mml:math></td></tr>
<tr>
<td align="right" valign="top"><bold>10</bold></td>
<td align="left" valign="top">  
<mml:math id="mm27" display="block">
<mml:semantics id="sm27">
<mml:mrow>
<mml:msub>
<mml:mi>X</mml:mi>
<mml:mi>t</mml:mi></mml:msub>
<mml:mo>←</mml:mo>
<mml:msub>
<mml:mi>X</mml:mi>
<mml:mi>t</mml:mi></mml:msub>
<mml:mo>∪</mml:mo>
<mml:mo stretchy="false">{</mml:mo>
<mml:mo stretchy="false">(</mml:mo>
<mml:msubsup>
<mml:mi>x</mml:mi>
<mml:mi>t</mml:mi>
<mml:mrow>
<mml:mo stretchy="false">[</mml:mo>
<mml:mi>i</mml:mi>
<mml:mo stretchy="false">]</mml:mo></mml:mrow></mml:msubsup>
<mml:mo>,</mml:mo>
<mml:msubsup>
<mml:mi>w</mml:mi>
<mml:mi>t</mml:mi>
<mml:mrow>
<mml:mo stretchy="false">[</mml:mo>
<mml:mi>i</mml:mi>
<mml:mo stretchy="false">]</mml:mo></mml:mrow></mml:msubsup>
<mml:mo>,</mml:mo>
<mml:msubsup>
<mml:mi>s</mml:mi>
<mml:mi>t</mml:mi>
<mml:mrow>
<mml:mo stretchy="false">[</mml:mo>
<mml:mi>i</mml:mi>
<mml:mo stretchy="false">]</mml:mo></mml:mrow></mml:msubsup>
<mml:mrow>
<mml:mo stretchy="false">)</mml:mo>
<mml:mo stretchy="false">}</mml:mo>
<mml:mo>;</mml:mo></mml:mrow></mml:mrow></mml:semantics></mml:math></td></tr>
<tr>
<td align="right" valign="top"><bold>11</bold></td>
<td align="left" valign="top"> <bold>endfor</bold></td></tr>
<tr>
<td align="right" valign="top"><bold>12</bold></td>
<td align="left" valign="top"><bold>end</bold></td></tr></tbody></array>
<p>Line 4 incorporates the measurement <italic>z<sub>t</sub></italic> into the particle set by computing the importance factor 
<inline-formula>
<mml:math id="mm28">
<mml:semantics id="sm28">
<mml:mrow>
<mml:msubsup>
<mml:mi>w</mml:mi>
<mml:mi>t</mml:mi>
<mml:mrow>
<mml:mo stretchy="false">[</mml:mo>
<mml:mi>m</mml:mi>
<mml:mo stretchy="false">]</mml:mo></mml:mrow></mml:msubsup></mml:mrow></mml:semantics></mml:math></inline-formula>. The particles that best explain the current sonar readings will have best weights. In general, given the sonar readings <italic>z<sub>t</sub></italic>, the measurement model should assign to the particle <italic>m</italic> the weight 
<inline-formula>
<mml:math id="mm29">
<mml:semantics id="sm29">
<mml:mrow>
<mml:mi>p</mml:mi>
<mml:mrow>
<mml:mo stretchy="false">(</mml:mo>
<mml:mrow>
<mml:msub>
<mml:mi>z</mml:mi>
<mml:mi>t</mml:mi></mml:msub>
<mml:mo stretchy="false">|</mml:mo>
<mml:msubsup>
<mml:mi>x</mml:mi>
<mml:mi>t</mml:mi>
<mml:mrow>
<mml:mo stretchy="false">[</mml:mo>
<mml:mi>m</mml:mi>
<mml:mo stretchy="false">]</mml:mo></mml:mrow></mml:msubsup></mml:mrow>
<mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:mrow></mml:semantics></mml:math></inline-formula>.</p>
<p>There are two main approaches in the literature to compute 
<inline-formula>
<mml:math id="mm30">
<mml:semantics id="sm30">
<mml:mrow>
<mml:mi>p</mml:mi>
<mml:mrow>
<mml:mo stretchy="false">(</mml:mo>
<mml:mrow>
<mml:msub>
<mml:mi>z</mml:mi>
<mml:mi>t</mml:mi></mml:msub>
<mml:mo stretchy="false">|</mml:mo>
<mml:msubsup>
<mml:mi>x</mml:mi>
<mml:mi>t</mml:mi>
<mml:mrow>
<mml:mo stretchy="false">[</mml:mo>
<mml:mi>m</mml:mi>
<mml:mo stretchy="false">]</mml:mo></mml:mrow></mml:msubsup></mml:mrow>
<mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:mrow></mml:semantics></mml:math></inline-formula>. On the one hand, the <italic>Simultaneous Localization and Mapping</italic> (SLAM) studies [<xref ref-type="bibr" rid="b7-sensors-09-10217">7</xref>, <xref ref-type="bibr" rid="b27-sensors-09-10217">27</xref>], which include the map into the state vector, so that readings can be fully predicted from 
<inline-formula>
<mml:math id="mm31">
<mml:semantics id="sm31">
<mml:mrow>
<mml:msubsup>
<mml:mi>x</mml:mi>
<mml:mi>t</mml:mi>
<mml:mrow>
<mml:mo stretchy="false">[</mml:mo>
<mml:mi>m</mml:mi>
<mml:mo stretchy="false">]</mml:mo></mml:mrow></mml:msubsup></mml:mrow></mml:semantics></mml:math></inline-formula>. On the other hand, the approaches relying on <italic>a priori</italic> maps. Besides, both approaches have some problems. For example, including the maps into the state vector leads to a high dimensional state vector that makes difficult to properly populate the state space with particles [<xref ref-type="bibr" rid="b28-sensors-09-10217">28</xref>]. This problem is magnified if the local maps are histories of readings, as the dimensionality grows significantly faster than in the approaches that make use of feature maps. Also, using an <italic>a priori</italic> map drastically reduces the autonomy of the robot because it can only be deployed in previously known environments.</p>
<p>Our proposal is to approximate these probabilities by measuring the degree of matching between the current readings and the particles' local maps. As the local maps are not included into the state vector, the problem of high dimensional state spaces does not appear. In other words, we approximate the weights by 
<inline-formula>
<mml:math id="mm32">
<mml:semantics id="sm32">
<mml:mrow>
<mml:mi>p</mml:mi>
<mml:mrow>
<mml:mo stretchy="false">(</mml:mo>
<mml:mrow>
<mml:msub>
<mml:mi>z</mml:mi>
<mml:mi>t</mml:mi></mml:msub>
<mml:mo stretchy="false">|</mml:mo>
<mml:msubsup>
<mml:mover accent="true">
<mml:mi>x</mml:mi>
<mml:mo>¯</mml:mo></mml:mover>
<mml:mi>t</mml:mi>
<mml:mrow>
<mml:mo stretchy="false">[</mml:mo>
<mml:mi>m</mml:mi>
<mml:mo stretchy="false">]</mml:mo></mml:mrow></mml:msubsup>
<mml:mo>,</mml:mo>
<mml:msubsup>
<mml:mi>s</mml:mi>
<mml:mi>t</mml:mi>
<mml:mrow>
<mml:mo stretchy="false">[</mml:mo>
<mml:mi>m</mml:mi>
<mml:mo stretchy="false">]</mml:mo></mml:mrow></mml:msubsup></mml:mrow>
<mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:mrow></mml:semantics></mml:math></inline-formula>. It is important to emphasize that the global robot pose 
<inline-formula>
<mml:math id="mm33">
<mml:semantics id="sm33">
<mml:mrow>
<mml:msubsup>
<mml:mi>x</mml:mi>
<mml:mi>t</mml:mi>
<mml:mrow>
<mml:mo stretchy="false">[</mml:mo>
<mml:mi>m</mml:mi>
<mml:mo stretchy="false">]</mml:mo></mml:mrow></mml:msubsup></mml:mrow></mml:semantics></mml:math></inline-formula> is not necessary and the local pose 
<inline-formula>
<mml:math id="mm34">
<mml:semantics id="sm34">
<mml:mrow>
<mml:msubsup>
<mml:mover accent="true">
<mml:mi>x</mml:mi>
<mml:mo>¯</mml:mo></mml:mover>
<mml:mi>t</mml:mi>
<mml:mrow>
<mml:mo stretchy="false">[</mml:mo>
<mml:mi>m</mml:mi>
<mml:mo stretchy="false">]</mml:mo></mml:mrow></mml:msubsup></mml:mrow></mml:semantics></mml:math></inline-formula> can be used instead because the maps are represented with respect to a coordinate frame which is local to each particle. The method to approximate this probability based on the provided sonar experimental characterization is described in Section 4.</p>
<p>Line 7 is in charge of the resampling. At this point, the algorithm draws with replacement <italic>M</italic> particles. The probability of drawing each particle is its importance factor. Broadly speaking, during the resampling, the particles with good weights have higher probability to remain in the particle set. In this paper, the low variance sampling algorithm has been chosen to implement the resampling step. This is a well known algorithm whose description can be found elsewhere [<xref ref-type="bibr" rid="b26-sensors-09-10217">26</xref>].</p>
<p>As stated previously, our motion model provides local robot poses. Thus, an additional step is required in order to update the global robot poses held by the particle set. This is accomplished in line 8 by compounding the global robot pose at time step <italic>t</italic> − 1 with the relative motion from time step <italic>t</italic> − 1 to time step <italic>t</italic>. In other words, the pose of each particle with respect to a fixed coordinate frame is updated in this line. Taking into account the initialization process, this means that this line is in charge of computing the pose of each particle with respect to the robot pose when the mission started.</p>
<p>Line 9 incorporates the current sonar measurements into the local maps. In order to do this, the robot motion 
<inline-formula>
<mml:math id="mm35">
<mml:semantics id="sm35">
<mml:mrow>
<mml:msubsup>
<mml:mover accent="true">
<mml:mi>x</mml:mi>
<mml:mo>¯</mml:mo></mml:mover>
<mml:mi>t</mml:mi>
<mml:mrow>
<mml:mo stretchy="false">[</mml:mo>
<mml:mi>m</mml:mi>
<mml:mo stretchy="false">]</mml:mo></mml:mrow></mml:msubsup></mml:mrow></mml:semantics></mml:math></inline-formula> is used. Thus, the stored local maps are different depending on the trajectory followed by each particle. This line is also in charge of neglecting the oldest information in each local map so that its size remains constant. Moreover, all the readings are represented with respect to 
<inline-formula>
<mml:math id="mm36">
<mml:semantics id="sm36">
<mml:mrow>
<mml:msubsup>
<mml:mi>x</mml:mi>
<mml:mi>t</mml:mi>
<mml:mrow>
<mml:mo stretchy="false">[</mml:mo>
<mml:mi>m</mml:mi>
<mml:mo stretchy="false">]</mml:mo></mml:mrow></mml:msubsup></mml:mrow></mml:semantics></mml:math></inline-formula> in line 9. Thanks to this last step, the measurement model does not depend on the global robot pose. A detailed description of this process is provided in Section 4. Finally, the new particle set <italic>X<sub>t</sub></italic> is constructed in line 10.</p>
<p><xref ref-type="fig" rid="f5-sensors-09-10217">Figure 5a</xref> illustrates the different components of the presented particle filter algorithm during a real robot operation. In order to provide a clear representation, the black lines on the center of the image represent a short history of the robot poses for each particle. The specific 
<inline-formula>
<mml:math id="mm37">
<mml:semantics id="sm37">
<mml:mrow>
<mml:msubsup>
<mml:mi>x</mml:mi>
<mml:mi>t</mml:mi>
<mml:mrow>
<mml:mo stretchy="false">[</mml:mo>
<mml:mn>1</mml:mn>
<mml:mo>:</mml:mo>
<mml:mi>M</mml:mi>
<mml:mo stretchy="false">]</mml:mo></mml:mrow></mml:msubsup></mml:mrow></mml:semantics></mml:math></inline-formula> correspond to the right end points of the mentioned lines. The black points represent the local maps. Being the robot pose values 
<inline-formula>
<mml:math id="mm38">
<mml:semantics id="sm38">
<mml:mrow>
<mml:msubsup>
<mml:mi>x</mml:mi>
<mml:mi>t</mml:mi>
<mml:mrow>
<mml:mo stretchy="false">[</mml:mo>
<mml:mn>1</mml:mn>
<mml:mo>:</mml:mo>
<mml:mi>M</mml:mi>
<mml:mo stretchy="false">]</mml:mo></mml:mrow></mml:msubsup></mml:mrow></mml:semantics></mml:math></inline-formula> roughly divided in two groups, the local maps seem to draw a double wall. The circles represent the current readings <italic>z<sub>t</sub></italic> according to each particle.</p>
<p>During the mission execution, it may be necessary not only to execute the particle filter algorithm but also to perform a <italic>density extraction</italic>. The density extraction consists on obtaining a continuous representation of the posterior over the robot poses instead of the discrete, sample based, representation held by the particle filter. In some cases it is sufficient to obtain the most probable robot pose instead of the full probability distribution.</p>
<p>Although the presented pose tracking approach may lead to multimodal distributions, we have experimentally observed that the Gaussian approximation does not introduce significant errors. Consequently, our proposal is to perform this type of density extraction when needed. <xref ref-type="fig" rid="f5-sensors-09-10217">Figure 5b</xref> shows an example of Gaussian approximation during one of the experiments conducted in this paper. If more accurate representations of the belief are necessary, some other density extraction techniques, such as K-means, histograms or kernel density estimation techniques should be used.</p></sec></sec>
<sec>
<label>4.</label>
<title>The Measurement Model</title>
<sec>
<label>4.1.</label>
<title>The Probabilistic Sonar Model</title>
<p>The measurement model is in charge of computing the importance factors of the particles. In particle filter localization, the importance factor represents the likelihood of having the current set of readings <italic>z<sub>t</sub></italic> at the robot pose 
<inline-formula>
<mml:math id="mm39">
<mml:semantics id="sm39">
<mml:mrow>
<mml:msubsup>
<mml:mi>x</mml:mi>
<mml:mi>t</mml:mi>
<mml:mrow>
<mml:mo stretchy="false">[</mml:mo>
<mml:mi>m</mml:mi>
<mml:mo stretchy="false">]</mml:mo></mml:mrow></mml:msubsup></mml:mrow></mml:semantics></mml:math></inline-formula>. This dependence on the absolute robot pose is useful if an <italic>a priori</italic> global map is available, because the range readings can be matched against the global map using the absolute robot pose.</p>
<p>One of the advantages of the presented approach is that it does not require any <italic>a priori</italic> global map. Instead, each particle updates a small local map. The local map 
<inline-formula>
<mml:math id="mm40">
<mml:semantics id="sm40">
<mml:mrow>
<mml:msubsup>
<mml:mi>s</mml:mi>
<mml:mrow>
<mml:mi>t</mml:mi>
<mml:mo>−</mml:mo>
<mml:mn>1</mml:mn></mml:mrow>
<mml:mrow>
<mml:mo stretchy="false">[</mml:mo>
<mml:mi>m</mml:mi>
<mml:mo stretchy="false">]</mml:mo></mml:mrow></mml:msubsup></mml:mrow></mml:semantics></mml:math></inline-formula> is represented with respect to 
<inline-formula>
<mml:math id="mm41">
<mml:semantics id="sm41">
<mml:mrow>
<mml:msubsup>
<mml:mi>x</mml:mi>
<mml:mrow>
<mml:mi>t</mml:mi>
<mml:mo>−</mml:mo>
<mml:mn>1</mml:mn></mml:mrow>
<mml:mrow>
<mml:mo stretchy="false">[</mml:mo>
<mml:mi>m</mml:mi>
<mml:mo stretchy="false">]</mml:mo></mml:mrow></mml:msubsup></mml:mrow></mml:semantics></mml:math></inline-formula>. Moreover, our implementation generates 
<inline-formula>
<mml:math id="mm42">
<mml:semantics id="sm42">
<mml:mrow>
<mml:msubsup>
<mml:mover accent="true">
<mml:mi>x</mml:mi>
<mml:mo>¯</mml:mo></mml:mover>
<mml:mrow>
<mml:mi>t</mml:mi></mml:mrow>
<mml:mrow>
<mml:mo stretchy="false">[</mml:mo>
<mml:mi>m</mml:mi>
<mml:mo stretchy="false">]</mml:mo></mml:mrow></mml:msubsup></mml:mrow></mml:semantics></mml:math></inline-formula>, which represents a relative motion between 
<inline-formula>
<mml:math id="mm43">
<mml:semantics id="sm43">
<mml:mrow>
<mml:msubsup>
<mml:mi>x</mml:mi>
<mml:mrow>
<mml:mi>t</mml:mi>
<mml:mo>−</mml:mo>
<mml:mn>1</mml:mn></mml:mrow>
<mml:mrow>
<mml:mo stretchy="false">[</mml:mo>
<mml:mi>m</mml:mi>
<mml:mo stretchy="false">]</mml:mo></mml:mrow></mml:msubsup></mml:mrow></mml:semantics></mml:math></inline-formula> and 
<inline-formula>
<mml:math id="mm44">
<mml:semantics id="sm44">
<mml:mrow>
<mml:msubsup>
<mml:mi>x</mml:mi>
<mml:mi>t</mml:mi>
<mml:mrow>
<mml:mo stretchy="false">[</mml:mo>
<mml:mi>m</mml:mi>
<mml:mo stretchy="false">]</mml:mo></mml:mrow></mml:msubsup></mml:mrow></mml:semantics></mml:math></inline-formula>. Consequently, by matching 
<inline-formula>
<mml:math id="mm45">
<mml:semantics id="sm45">
<mml:mrow>
<mml:msubsup>
<mml:mover accent="true">
<mml:mi>x</mml:mi>
<mml:mo>¯</mml:mo></mml:mover>
<mml:mi>t</mml:mi>
<mml:mrow>
<mml:mo stretchy="false">[</mml:mo>
<mml:mi>m</mml:mi>
<mml:mo stretchy="false">]</mml:mo></mml:mrow></mml:msubsup>
<mml:mo>⊕</mml:mo>
<mml:msub>
<mml:mi>z</mml:mi>
<mml:mi>t</mml:mi></mml:msub></mml:mrow></mml:semantics></mml:math></inline-formula> against 
<inline-formula>
<mml:math id="mm46">
<mml:semantics id="sm46">
<mml:mrow>
<mml:msubsup>
<mml:mi>s</mml:mi>
<mml:mrow>
<mml:mi>t</mml:mi>
<mml:mo>−</mml:mo>
<mml:mn>1</mml:mn></mml:mrow>
<mml:mrow>
<mml:mo stretchy="false">[</mml:mo>
<mml:mi>m</mml:mi>
<mml:mo stretchy="false">]</mml:mo></mml:mrow></mml:msubsup></mml:mrow></mml:semantics></mml:math></inline-formula>, the particle weight can be computed as an approximation of 
<inline-formula>
<mml:math id="mm47">
<mml:semantics id="sm47">
<mml:mrow>
<mml:mi>p</mml:mi>
<mml:mrow>
<mml:mo stretchy="false">(</mml:mo>
<mml:mrow>
<mml:msub>
<mml:mi>z</mml:mi>
<mml:mi>t</mml:mi></mml:msub>
<mml:mo stretchy="false">|</mml:mo>
<mml:msubsup>
<mml:mover accent="true">
<mml:mi>x</mml:mi>
<mml:mo>¯</mml:mo></mml:mover>
<mml:mi>t</mml:mi>
<mml:mrow>
<mml:mo stretchy="false">[</mml:mo>
<mml:mi>m</mml:mi>
<mml:mo stretchy="false">]</mml:mo></mml:mrow></mml:msubsup>
<mml:mo>,</mml:mo>
<mml:msubsup>
<mml:mi>s</mml:mi>
<mml:mrow>
<mml:mi>t</mml:mi>
<mml:mo>−</mml:mo>
<mml:mn>1</mml:mn></mml:mrow>
<mml:mrow>
<mml:mo stretchy="false">[</mml:mo>
<mml:mi>m</mml:mi>
<mml:mo stretchy="false">]</mml:mo></mml:mrow></mml:msubsup></mml:mrow>
<mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:mrow></mml:semantics></mml:math></inline-formula>. Differently speaking, the idea is to evaluate the degree of matching between the current set of readings and each stored map. This idea is similar to scan matching [<xref ref-type="bibr" rid="b3-sensors-09-10217">3</xref>, <xref ref-type="bibr" rid="b13-sensors-09-10217">13</xref>], where two consecutive range scans are matched to find the relative motion between them.</p>
<p>The proposal in this paper models the sonar readings by Normal distributions. Then, statistical compatibility tests are used to compute the degree of matching between the current sonar readings and each of the local maps.</p>
<p>The sonar reading provided by the <italic>i</italic> – <italic>th</italic> sonar sensor at time step <italic>t</italic> is modeled by the Normal distribution 
<inline-formula>
<mml:math id="mm48">
<mml:semantics id="sm48">
<mml:mrow>
<mml:msubsup>
<mml:mi>r</mml:mi>
<mml:mi>t</mml:mi>
<mml:mi>i</mml:mi></mml:msubsup>
<mml:mo>=</mml:mo>
<mml:mi>N</mml:mi>
<mml:mo stretchy="false">(</mml:mo>
<mml:msubsup>
<mml:mover accent="true">
<mml:mi>r</mml:mi>
<mml:mo>^</mml:mo></mml:mover>
<mml:mi>t</mml:mi>
<mml:mi>i</mml:mi></mml:msubsup>
<mml:mo>,</mml:mo>
<mml:msubsup>
<mml:mi>P</mml:mi>
<mml:mi>t</mml:mi>
<mml:mi>i</mml:mi></mml:msubsup>
<mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:semantics></mml:math></inline-formula>. The mean vector is 
<inline-formula>
<mml:math id="mm49">
<mml:semantics id="sm49">
<mml:mrow>
<mml:msubsup>
<mml:mover accent="true">
<mml:mi>r</mml:mi>
<mml:mo>^</mml:mo></mml:mover>
<mml:mi>t</mml:mi>
<mml:mi>i</mml:mi></mml:msubsup>
<mml:mo>=</mml:mo>
<mml:msup>
<mml:mrow>
<mml:mo stretchy="false">[</mml:mo>
<mml:mi>r</mml:mi>
<mml:mo>,</mml:mo>
<mml:mn>0</mml:mn>
<mml:mo stretchy="false">]</mml:mo></mml:mrow>
<mml:mi>T</mml:mi></mml:msup></mml:mrow></mml:semantics></mml:math></inline-formula>, being <italic>r</italic> the range measure provided by the sonar. The covariance is defined as
<disp-formula id="FD3">
<label>(3)</label>
<mml:math id="mm50" display="block">
<mml:semantics id="sm50">
<mml:mrow>
<mml:msubsup>
<mml:mi>P</mml:mi>
<mml:mi>t</mml:mi>
<mml:mi>i</mml:mi></mml:msubsup>
<mml:mo>=</mml:mo>
<mml:mrow>
<mml:mo>[</mml:mo>
<mml:mrow>
<mml:mtable>
<mml:mtr>
<mml:mtd>
<mml:mrow>
<mml:msubsup>
<mml:mi>σ</mml:mi>
<mml:mrow>
<mml:mi>x</mml:mi>
<mml:mi>x</mml:mi></mml:mrow>
<mml:mn>2</mml:mn></mml:msubsup>
<mml:mo stretchy="false">(</mml:mo>
<mml:mi>r</mml:mi>
<mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:mtd>
<mml:mtd>
<mml:mn>0</mml:mn></mml:mtd></mml:mtr>
<mml:mtr>
<mml:mtd>
<mml:mn>0</mml:mn></mml:mtd>
<mml:mtd>
<mml:mrow>
<mml:msubsup>
<mml:mi>σ</mml:mi>
<mml:mrow>
<mml:mi>y</mml:mi>
<mml:mi>y</mml:mi></mml:mrow>
<mml:mn>2</mml:mn></mml:msubsup>
<mml:mo stretchy="false">(</mml:mo>
<mml:mi>r</mml:mi>
<mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:mtd></mml:mtr></mml:mtable></mml:mrow>
<mml:mo>]</mml:mo></mml:mrow></mml:mrow></mml:semantics></mml:math></disp-formula>where <italic>σ<sub>xx</sub></italic>(<italic>r</italic>) and <italic>σ<sub>yy</sub>(r)</italic> model the range and angular uncertainties respectively. The angular uncertainty is related to the sonar opening, so that 
<inline-formula>
<mml:math id="mm51">
<mml:semantics id="sm51">
<mml:mrow>
<mml:msub>
<mml:mi>σ</mml:mi>
<mml:mrow>
<mml:mi>y</mml:mi>
<mml:mi>y</mml:mi></mml:mrow></mml:msub>
<mml:mo stretchy="false">(</mml:mo>
<mml:mi>r</mml:mi>
<mml:mo stretchy="false">)</mml:mo>
<mml:mo>=</mml:mo>
<mml:mfrac>
<mml:mi>r</mml:mi>
<mml:mn>2</mml:mn></mml:mfrac>
<mml:mo>tan</mml:mo>
<mml:mrow>
<mml:mo stretchy="false">(</mml:mo>
<mml:mrow>
<mml:mfrac>
<mml:mrow>
<mml:mi>α</mml:mi>
<mml:mo stretchy="false">(</mml:mo>
<mml:mi>r</mml:mi>
<mml:mo stretchy="false">)</mml:mo></mml:mrow>
<mml:mn>2</mml:mn></mml:mfrac></mml:mrow>
<mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:mrow></mml:semantics></mml:math></inline-formula>. The term <italic>α</italic>, which represents the opening, is written here as a function of <italic>r</italic> because, as shown in Section 2., the opening changes with distance. Consequently, <italic>α(r)</italic> has to be computed by means of the values provided in <xref ref-type="fig" rid="f3-sensors-09-10217">Figure 3a</xref>. For example, for a range between 1.5 m and 2 m, the opening <italic>α(r)</italic> should be 23.17°. Obviously, the values for <italic>α(r)</italic> could also be interpolated from the experimental data if necessary.</p>
<p>The values of <italic>σ<sub>xx</sub>(r)</italic>, representing the range uncertainty, can be obtained in a similar way from the accuracy shown in <xref ref-type="fig" rid="f3-sensors-09-10217">Figure 3b</xref>. The accuracy was defined as the deviation from the sonar readings to the real range, thus, the accuracy actually represents the range uncertainty.</p>
<p><xref ref-type="fig" rid="f6-sensors-09-10217">Figure 6a</xref> exemplifies the proposed model. The Normal distributions corresponding to different ranges have been computed as described, and the 99% confidence ellipses drawn. The range uncertainty has been increased by a factor of 50 to provide a clear representation. The meaning of the model becomes clear when it is compared to <xref ref-type="fig" rid="f3-sensors-09-10217">Figure 3a</xref>.</p>
<p>For a given particle <italic>m</italic>, the robot motion from time step <italic>t</italic> − 1<italic>to</italic> time step <italic>t</italic> is modeled by the Normal distribution 
<inline-formula>
<mml:math id="mm52">
<mml:semantics id="sm52">
<mml:mrow>
<mml:msubsup>
<mml:mover accent="true">
<mml:mi>x</mml:mi>
<mml:mo>¯</mml:mo></mml:mover>
<mml:mi>t</mml:mi>
<mml:mi>m</mml:mi></mml:msubsup>
<mml:mo>=</mml:mo>
<mml:mi>N</mml:mi>
<mml:mo stretchy="false">(</mml:mo>
<mml:msubsup>
<mml:mover accent="true">
<mml:mi>x</mml:mi>
<mml:mo>¯</mml:mo></mml:mover>
<mml:mi>t</mml:mi>
<mml:mi>m</mml:mi></mml:msubsup>
<mml:mo>,</mml:mo>
<mml:mi>P</mml:mi>
<mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:semantics></mml:math></inline-formula>. The mean of this distribution is, precisely, the motion generated by the motion model in line 3 of Algorithm 1. The covariance has to be defined so that 
<inline-formula>
<mml:math id="mm53">
<mml:semantics id="sm53">
<mml:mrow>
<mml:msubsup>
<mml:mover accent="true">
<mml:mi>x</mml:mi>
<mml:mo>¯</mml:mo></mml:mover>
<mml:mi>t</mml:mi>
<mml:mi>m</mml:mi></mml:msubsup></mml:mrow></mml:semantics></mml:math></inline-formula> is a good approximation of the distribution <italic>p(x̄<sub>t</sub></italic>∣<italic>u<sub>t</sub>)</italic> used in the motion model. If the motion model also makes use of Normal distributions, as it was described previously, the same covariance can be used here.</p>
<p>Finally, the relative position of the sonar sensor <italic>i</italic> with respect to the robot reference frame is represented by <italic>t<sub>i</sub></italic>. This relative position do not change over time, and is perfectly known. <xref ref-type="fig" rid="f6-sensors-09-10217">Figure 6b</xref> depicts the relation between the described models.</p></sec>
<sec>
<label>4.2.</label>
<title>Building the Local Maps</title>
<p>As stated previously, the particles are weighted by matching the current set of readings <italic>z<sub>t</sub></italic> against the stored readings 
<inline-formula>
<mml:math id="mm54">
<mml:semantics id="sm54">
<mml:mrow>
<mml:msubsup>
<mml:mi>s</mml:mi>
<mml:mrow>
<mml:mi>t</mml:mi>
<mml:mo>−</mml:mo>
<mml:mn>1</mml:mn></mml:mrow>
<mml:mrow>
<mml:mo stretchy="false">[</mml:mo>
<mml:mi>m</mml:mi>
<mml:mo stretchy="false">]</mml:mo></mml:mrow></mml:msubsup></mml:mrow></mml:semantics></mml:math></inline-formula>. The former set has been gathered at the current robot pose whereas the latter one is represented with respect to the robot pose one time step earlier. In order to match them, both sets have to be represented with respect to the same coordinate frame. The current set <italic>z<sub>t</sub></italic> has less readings than the history. Accordingly, from a computational point of view it is preferable to transform the points in <italic>z<sub>t</sub></italic>. The set of readings <italic>z<sub>t</sub></italic> is built as follows
<disp-formula id="FD4">
<label>(4)</label>
<mml:math id="mm55" display="block">
<mml:semantics id="sm55">
<mml:mrow>
<mml:msub>
<mml:mi>z</mml:mi>
<mml:mi>t</mml:mi></mml:msub>
<mml:mo>=</mml:mo>
<mml:mo stretchy="false">{</mml:mo>
<mml:msub>
<mml:mi>t</mml:mi>
<mml:mi>i</mml:mi></mml:msub>
<mml:mo>⊕</mml:mo>
<mml:msubsup>
<mml:mi>r</mml:mi>
<mml:mi>t</mml:mi>
<mml:mi>i</mml:mi></mml:msubsup>
<mml:mo>,</mml:mo>
<mml:mo>∀</mml:mo>
<mml:mi>i</mml:mi>
<mml:mo>∈</mml:mo>
<mml:mi>V</mml:mi>
<mml:msub>
<mml:mi>S</mml:mi>
<mml:mi>t</mml:mi></mml:msub>
<mml:mo stretchy="false">}</mml:mo></mml:mrow></mml:semantics></mml:math></disp-formula>where <italic>VS<sub>t</sub></italic> is the set of sonar sensors that have generated a reading during time step <italic>t</italic>. Each item in <italic>z<sub>t</sub></italic> will be denoted 
<inline-formula>
<mml:math id="mm56">
<mml:semantics id="sm56">
<mml:mrow>
<mml:msubsup>
<mml:mi>z</mml:mi>
<mml:mi>t</mml:mi>
<mml:mi>i</mml:mi></mml:msubsup>
<mml:mo>=</mml:mo>
<mml:mi>N</mml:mi>
<mml:mo stretchy="false">(</mml:mo>
<mml:msubsup>
<mml:mover accent="true">
<mml:mi>z</mml:mi>
<mml:mo>^</mml:mo></mml:mover>
<mml:mi>t</mml:mi>
<mml:mi>i</mml:mi></mml:msubsup>
<mml:mo>,</mml:mo>
<mml:msubsup>
<mml:mi>Q</mml:mi>
<mml:mi>t</mml:mi>
<mml:mi>i</mml:mi></mml:msubsup>
<mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:semantics></mml:math></inline-formula>, meaning that it was gathered at time <italic>t</italic> by the <italic>i</italic> – <italic>th</italic> sonar sensor.</p>
<p>Let <italic>S<sub>new</sub></italic> be defined as the set of readings in <italic>z<sub>t</sub></italic> represented with respect to the coordinate frame of 
<inline-formula>
<mml:math id="mm57">
<mml:semantics id="sm57">
<mml:mrow>
<mml:msubsup>
<mml:mi>s</mml:mi>
<mml:mrow>
<mml:mi>t</mml:mi>
<mml:mo>−</mml:mo>
<mml:mn>1</mml:mn></mml:mrow>
<mml:mrow>
<mml:mo stretchy="false">[</mml:mo>
<mml:mi>m</mml:mi>
<mml:mo stretchy="false">]</mml:mo></mml:mrow></mml:msubsup></mml:mrow></mml:semantics></mml:math></inline-formula> (see <xref ref-type="fig" rid="f4-sensors-09-10217">Figure 4</xref>) using the motion 
<inline-formula>
<mml:math id="mm58">
<mml:semantics id="sm58">
<mml:mrow>
<mml:msubsup>
<mml:mover accent="true">
<mml:mi>x</mml:mi>
<mml:mo>¯</mml:mo></mml:mover>
<mml:mi>t</mml:mi>
<mml:mi>m</mml:mi></mml:msubsup></mml:mrow></mml:semantics></mml:math></inline-formula> proposed by the particle:
<disp-formula id="FD5">
<label>(5)</label>
<mml:math id="mm59" display="block">
<mml:semantics id="sm59">
<mml:mrow>
<mml:msub>
<mml:mi>S</mml:mi>
<mml:mrow>
<mml:mtext mathvariant="italic">new</mml:mtext></mml:mrow></mml:msub>
<mml:mo>=</mml:mo>
<mml:msubsup>
<mml:mover accent="true">
<mml:mi>x</mml:mi>
<mml:mo>¯</mml:mo></mml:mover>
<mml:mi>t</mml:mi>
<mml:mi>m</mml:mi></mml:msubsup>
<mml:mo>⊕</mml:mo>
<mml:msub>
<mml:mi>z</mml:mi>
<mml:mi>t</mml:mi></mml:msub>
<mml:mo>=</mml:mo>
<mml:mo stretchy="false">{</mml:mo>
<mml:msubsup>
<mml:mover accent="true">
<mml:mi>x</mml:mi>
<mml:mo>¯</mml:mo></mml:mover>
<mml:mi>t</mml:mi>
<mml:mi>m</mml:mi></mml:msubsup>
<mml:mo>⊕</mml:mo>
<mml:msubsup>
<mml:mi>z</mml:mi>
<mml:mi>j</mml:mi>
<mml:mi>i</mml:mi></mml:msubsup>
<mml:mo>,</mml:mo>
<mml:mo>∀</mml:mo>
<mml:mi>i</mml:mi>
<mml:mo>∈</mml:mo>
<mml:mi>V</mml:mi>
<mml:msub>
<mml:mi>S</mml:mi>
<mml:mi>t</mml:mi></mml:msub>
<mml:mo stretchy="false">}</mml:mo></mml:mrow></mml:semantics></mml:math></disp-formula></p>
<p>Each item in <italic>S<sub>new</sub></italic> will be denoted by 
<inline-formula>
<mml:math id="mm60">
<mml:semantics id="sm60">
<mml:mrow>
<mml:msubsup>
<mml:mi>p</mml:mi>
<mml:mi>t</mml:mi>
<mml:mi>i</mml:mi></mml:msubsup></mml:mrow></mml:semantics></mml:math></inline-formula>, meaning that it has been generated from 
<inline-formula>
<mml:math id="mm61">
<mml:semantics id="sm61">
<mml:mrow>
<mml:msubsup>
<mml:mi>z</mml:mi>
<mml:mi>t</mml:mi>
<mml:mi>i</mml:mi></mml:msubsup></mml:mrow></mml:semantics></mml:math></inline-formula>.</p>
<p>To ease notation, let us denote by <italic>S<sub>old</sub></italic> the history 
<inline-formula>
<mml:math id="mm62">
<mml:semantics id="sm62">
<mml:mrow>
<mml:msubsup>
<mml:mi>s</mml:mi>
<mml:mrow>
<mml:mi>t</mml:mi>
<mml:mo>−</mml:mo>
<mml:mn>1</mml:mn></mml:mrow>
<mml:mrow>
<mml:mo stretchy="false">[</mml:mo>
<mml:mi>m</mml:mi>
<mml:mo stretchy="false">]</mml:mo></mml:mrow></mml:msubsup></mml:mrow></mml:semantics></mml:math></inline-formula>. It was stated previously that all the readings in <italic>S<sub>old</sub></italic> are represented with respect to the robot pose at time step <italic>t</italic> − 1. Using the defined sensor models, this is accomplished as follows:
<disp-formula id="FD6">
<label>(6)</label>
<mml:math id="mm63" display="block">
<mml:semantics id="sm63">
<mml:mtable columnalign="left">
<mml:mtr columnalign="left">
<mml:mtd columnalign="left">
<mml:msub>
<mml:mi>S</mml:mi>
<mml:mrow>
<mml:mtext mathvariant="italic">old</mml:mtext></mml:mrow></mml:msub></mml:mtd>
<mml:mtd>
<mml:mo>=</mml:mo></mml:mtd>
<mml:mtd>
<mml:mo stretchy="false">{</mml:mo>
<mml:msub>
<mml:mi>z</mml:mi>
<mml:mrow>
<mml:mi>t</mml:mi>
<mml:mo>−</mml:mo>
<mml:mn>1</mml:mn></mml:mrow></mml:msub>
<mml:mo>,</mml:mo></mml:mtd></mml:mtr>
<mml:mtr>
<mml:mtd/>
<mml:mtd/>
<mml:mtd>
<mml:mo>⊖</mml:mo>
<mml:msubsup>
<mml:mover accent="true">
<mml:mi>x</mml:mi>
<mml:mo>¯</mml:mo></mml:mover>
<mml:mrow>
<mml:mi>t</mml:mi>
<mml:mo>−</mml:mo>
<mml:mn>1</mml:mn></mml:mrow>
<mml:mi>m</mml:mi></mml:msubsup>
<mml:mo>⊕</mml:mo>
<mml:msub>
<mml:mi>z</mml:mi>
<mml:mrow>
<mml:mi>t</mml:mi>
<mml:mo>−</mml:mo>
<mml:mn>2</mml:mn></mml:mrow></mml:msub>
<mml:mo>,</mml:mo></mml:mtd></mml:mtr>
<mml:mtr>
<mml:mtd/>
<mml:mtd/>
<mml:mtd>
<mml:mo>⊖</mml:mo>
<mml:msubsup>
<mml:mover accent="true">
<mml:mi>x</mml:mi>
<mml:mo>¯</mml:mo></mml:mover>
<mml:mrow>
<mml:mi>t</mml:mi>
<mml:mo>−</mml:mo>
<mml:mn>1</mml:mn></mml:mrow>
<mml:mi>m</mml:mi></mml:msubsup>
<mml:mo>⊕</mml:mo>
<mml:mo stretchy="false">(</mml:mo>
<mml:mo>⊖</mml:mo>
<mml:msubsup>
<mml:mover accent="true">
<mml:mi>x</mml:mi>
<mml:mo>¯</mml:mo></mml:mover>
<mml:mrow>
<mml:mi>t</mml:mi>
<mml:mo>−</mml:mo>
<mml:mn>2</mml:mn></mml:mrow>
<mml:mi>m</mml:mi></mml:msubsup>
<mml:mo stretchy="false">)</mml:mo>
<mml:msub>
<mml:mi>z</mml:mi>
<mml:mrow>
<mml:mi>t</mml:mi>
<mml:mo>−</mml:mo>
<mml:mn>3</mml:mn></mml:mrow></mml:msub>
<mml:mo>,</mml:mo>
<mml:mo>…</mml:mo>
<mml:mo>,</mml:mo></mml:mtd></mml:mtr>
<mml:mtr>
<mml:mtd/>
<mml:mtd/>
<mml:mtd>
<mml:mo>⊖</mml:mo>
<mml:msubsup>
<mml:mover accent="true">
<mml:mi>x</mml:mi>
<mml:mo>¯</mml:mo></mml:mover>
<mml:mrow>
<mml:mi>t</mml:mi>
<mml:mo>−</mml:mo>
<mml:mn>1</mml:mn></mml:mrow>
<mml:mi>m</mml:mi></mml:msubsup>
<mml:mo>⊕</mml:mo>
<mml:mo>…</mml:mo>
<mml:mo>⊕</mml:mo>
<mml:mo stretchy="false">(</mml:mo>
<mml:mo>⊖</mml:mo>
<mml:msubsup>
<mml:mover accent="true">
<mml:mi>x</mml:mi>
<mml:mo>¯</mml:mo></mml:mover>
<mml:mrow>
<mml:mi>t</mml:mi>
<mml:mo>−</mml:mo>
<mml:mi>k</mml:mi>
<mml:mo>+</mml:mo>
<mml:mn>1</mml:mn></mml:mrow>
<mml:mi>m</mml:mi></mml:msubsup>
<mml:mo stretchy="false">)</mml:mo>
<mml:msub>
<mml:mi>z</mml:mi>
<mml:mrow>
<mml:mi>t</mml:mi>
<mml:mo>−</mml:mo>
<mml:mi>k</mml:mi></mml:mrow></mml:msub>
<mml:mo stretchy="false">}</mml:mo></mml:mtd></mml:mtr></mml:mtable></mml:semantics></mml:math></disp-formula>where <italic>k</italic> is the history size. By observing the previous equation it is easy to see that it is not necessary to perform these computations at each time step. Instead, line 9 of Algorithm 1 computes 
<inline-formula>
<mml:math id="mm64">
<mml:semantics id="sm64">
<mml:mrow>
<mml:msubsup>
<mml:mi>s</mml:mi>
<mml:mi>t</mml:mi>
<mml:mrow>
<mml:mo stretchy="false">[</mml:mo>
<mml:mi>m</mml:mi>
<mml:mo stretchy="false">]</mml:mo></mml:mrow></mml:msubsup></mml:mrow></mml:semantics></mml:math></inline-formula> from 
<inline-formula>
<mml:math id="mm65">
<mml:semantics id="sm65">
<mml:mrow>
<mml:msubsup>
<mml:mi>s</mml:mi>
<mml:mrow>
<mml:mi>t</mml:mi>
<mml:mo>−</mml:mo>
<mml:mn>1</mml:mn></mml:mrow>
<mml:mrow>
<mml:mo stretchy="false">[</mml:mo>
<mml:mi>m</mml:mi>
<mml:mo stretchy="false">]</mml:mo></mml:mrow></mml:msubsup></mml:mrow></mml:semantics></mml:math></inline-formula> as follows:
<disp-formula id="FD7">
<label>(7)</label>
<mml:math id="mm66" display="block">
<mml:semantics id="sm66">
<mml:mrow>
<mml:msubsup>
<mml:mi>s</mml:mi>
<mml:mi>t</mml:mi>
<mml:mrow>
<mml:mo stretchy="false">[</mml:mo>
<mml:mi>m</mml:mi>
<mml:mo stretchy="false">]</mml:mo></mml:mrow></mml:msubsup>
<mml:mo>=</mml:mo>
<mml:mo stretchy="false">(</mml:mo>
<mml:mo stretchy="false">(</mml:mo>
<mml:mo>⊖</mml:mo>
<mml:msubsup>
<mml:mover accent="true">
<mml:mi>x</mml:mi>
<mml:mo>¯</mml:mo></mml:mover>
<mml:mi>t</mml:mi>
<mml:mrow>
<mml:mo stretchy="false">[</mml:mo>
<mml:mi>m</mml:mi>
<mml:mo stretchy="false">]</mml:mo></mml:mrow></mml:msubsup>
<mml:mo stretchy="false">)</mml:mo>
<mml:mo>⊕</mml:mo>
<mml:msubsup>
<mml:mi>s</mml:mi>
<mml:mrow>
<mml:mi>t</mml:mi>
<mml:mo>−</mml:mo>
<mml:mn>1</mml:mn></mml:mrow>
<mml:mrow>
<mml:mo stretchy="false">[</mml:mo>
<mml:mi>m</mml:mi>
<mml:mo stretchy="false">]</mml:mo></mml:mrow></mml:msubsup>
<mml:mo stretchy="false">)</mml:mo>
<mml:mo>∪</mml:mo>
<mml:msub>
<mml:mi>z</mml:mi>
<mml:mi>t</mml:mi></mml:msub></mml:mrow></mml:semantics></mml:math></disp-formula></p>
<p>First, the readings in 
<inline-formula>
<mml:math id="mm67">
<mml:semantics id="sm67">
<mml:mrow>
<mml:msubsup>
<mml:mi>s</mml:mi>
<mml:mrow>
<mml:mi>t</mml:mi>
<mml:mo>−</mml:mo>
<mml:mn>1</mml:mn></mml:mrow>
<mml:mrow>
<mml:mo stretchy="false">[</mml:mo>
<mml:mi>m</mml:mi>
<mml:mo stretchy="false">]</mml:mo></mml:mrow></mml:msubsup></mml:mrow></mml:semantics></mml:math></inline-formula> are represented with respect to the coordinate frame of 
<inline-formula>
<mml:math id="mm68">
<mml:semantics id="sm68">
<mml:mrow>
<mml:msubsup>
<mml:mi>x</mml:mi>
<mml:mi>t</mml:mi>
<mml:mrow>
<mml:mo stretchy="false">[</mml:mo>
<mml:mi>m</mml:mi>
<mml:mo stretchy="false">]</mml:mo></mml:mrow></mml:msubsup></mml:mrow></mml:semantics></mml:math></inline-formula> by compounding them with 
<inline-formula>
<mml:math id="mm69">
<mml:semantics id="sm69">
<mml:mrow>
<mml:mo>⊖</mml:mo>
<mml:msubsup>
<mml:mover accent="true">
<mml:mi>x</mml:mi>
<mml:mo>¯</mml:mo></mml:mover>
<mml:mi>t</mml:mi>
<mml:mrow>
<mml:mo stretchy="false">[</mml:mo>
<mml:mi>m</mml:mi>
<mml:mo stretchy="false">]</mml:mo></mml:mrow></mml:msubsup></mml:mrow></mml:semantics></mml:math></inline-formula>. Then, the new set of readings <italic>z<sub>t</sub></italic> is added. Finally, although not being represented in <xref ref-type="disp-formula" rid="FD7">Equation 7</xref>, the oldest readings in the resulting set have to be deleted so that the size of the local maps remains constant along the whole mission execution. Thanks to the recursive update, the computational effort required to build <italic>S<sub>old</sub></italic> is significantly reduced. Moreover, it is not necessary to store a history of the robot motions. A special situation arises at the beginning of the particle filter operation, when <italic>t</italic> &lt; <italic>k</italic>. In that case, part of the readings in <italic>S<sub>old</sub></italic> come from the initialization process.</p>
<p><xref ref-type="fig" rid="f7-sensors-09-10217">Figure 7</xref> shows an example of <italic>S<sub>new</sub></italic> and <italic>S<sub>old</sub></italic> built as described. It can be observed how the obtained Normal distributions are well suited to model the sonar uncertainties, especially the angular one.</p></sec>
<sec>
<label>4.3.</label>
<title>The Probabilistic Approach</title>
<p>There exist many algorithms to match sets of range readings [<xref ref-type="bibr" rid="b13-sensors-09-10217">13</xref>, <xref ref-type="bibr" rid="b29-sensors-09-10217">29</xref>, <xref ref-type="bibr" rid="b30-sensors-09-10217">30</xref>]. Most of them follow the structure proposed by the ICP algorithm [<xref ref-type="bibr" rid="b13-sensors-09-10217">13</xref>]. One important step in this algorithm is the establishment of <italic>correspondences</italic> between readings in two consecutive sensor scans. A correspondence is an association between a reading in <italic>S<sub>new</sub></italic> and a reading in <italic>S<sub>old</sub></italic>. Correspondences are commonly established in two steps. First, <italic>S<sub>new</sub></italic> is represented with respect to the coordinate frame of <italic>S<sub>old</sub></italic> by using the current pose estimate. Then, correspondences are defined according to a proximity criteria: a reading in <italic>S<sub>new</sub></italic> is associated with the closest one in <italic>S<sub>old</sub></italic>. The proximity criteria usually relies on the Euclidean distance. When it is built, a set of correspondences gives information about the degree of matching between the two sets of readings.</p>
<p>The proposed measurement model is based on matching the current set of readings against the local maps. However, instead of using the Euclidean distance, this method proposes the use of the Normal distributions in <italic>S<sub>new</sub></italic> and <italic>S<sub>old</sub></italic> to establish correspondences only for those readings which are statistically compatible. Then, the degree of matching can be computed from the overall statistical compatibility.</p>
<p>Let <italic>q<sub>j</sub></italic> = <italic>N(q̂<sub>j</sub>, P<sub>j</sub>)</italic> be a reading in <italic>S<sub>old</sub></italic>. To decide whether 
<inline-formula>
<mml:math id="mm70">
<mml:semantics id="sm70">
<mml:mrow>
<mml:msubsup>
<mml:mi>p</mml:mi>
<mml:mi>t</mml:mi>
<mml:mi>i</mml:mi></mml:msubsup>
<mml:mo>∈</mml:mo>
<mml:msub>
<mml:mi>S</mml:mi>
<mml:mrow>
<mml:mtext mathvariant="italic">new</mml:mtext></mml:mrow></mml:msub></mml:mrow></mml:semantics></mml:math></inline-formula> and <italic>q<sub>j</sub></italic> are statistically compatible, the squared Mahalanobis distance is used:
<disp-formula id="FD8">
<label>(8)</label>
<mml:math id="mm71" display="block">
<mml:semantics id="sm71">
<mml:mrow>
<mml:msup>
<mml:mi>D</mml:mi>
<mml:mn>2</mml:mn></mml:msup>
<mml:mo stretchy="false">(</mml:mo>
<mml:msubsup>
<mml:mi>p</mml:mi>
<mml:mi>t</mml:mi>
<mml:mi>i</mml:mi></mml:msubsup>
<mml:mo>,</mml:mo>
<mml:msub>
<mml:mi>q</mml:mi>
<mml:mi>j</mml:mi></mml:msub>
<mml:mo stretchy="false">)</mml:mo>
<mml:mo>=</mml:mo>
<mml:msup>
<mml:mrow>
<mml:mo stretchy="false">(</mml:mo>
<mml:msubsup>
<mml:mi>p</mml:mi>
<mml:mi>t</mml:mi>
<mml:mi>i</mml:mi></mml:msubsup>
<mml:mo>−</mml:mo>
<mml:msub>
<mml:mi>q</mml:mi>
<mml:mi>j</mml:mi></mml:msub>
<mml:mo stretchy="false">)</mml:mo></mml:mrow>
<mml:mi>T</mml:mi></mml:msup>
<mml:msup>
<mml:mi>P</mml:mi>
<mml:mrow>
<mml:mo>−</mml:mo>
<mml:mn>1</mml:mn></mml:mrow></mml:msup>
<mml:mo stretchy="false">(</mml:mo>
<mml:msubsup>
<mml:mi>p</mml:mi>
<mml:mi>t</mml:mi>
<mml:mi>i</mml:mi></mml:msubsup>
<mml:mo>−</mml:mo>
<mml:msub>
<mml:mi>q</mml:mi>
<mml:mi>j</mml:mi></mml:msub>
<mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:semantics></mml:math></disp-formula>where <italic>P</italic> is the covariance matrix associated to 
<inline-formula>
<mml:math id="mm72">
<mml:semantics id="sm72">
<mml:mrow>
<mml:msubsup>
<mml:mi>p</mml:mi>
<mml:mi>t</mml:mi>
<mml:mi>i</mml:mi></mml:msubsup>
<mml:mo>−</mml:mo>
<mml:msub>
<mml:mi>q</mml:mi>
<mml:mi>j</mml:mi></mml:msub></mml:mrow></mml:semantics></mml:math></inline-formula>. <xref ref-type="disp-formula" rid="FD5">Equation 5</xref> shows that each 
<inline-formula>
<mml:math id="mm73">
<mml:semantics id="sm73">
<mml:mrow>
<mml:msubsup>
<mml:mi>p</mml:mi>
<mml:mi>t</mml:mi>
<mml:mi>i</mml:mi></mml:msubsup></mml:mrow></mml:semantics></mml:math></inline-formula> in <italic>S<sub>new</sub></italic> is the result of compounding 
<inline-formula>
<mml:math id="mm74">
<mml:semantics id="sm74">
<mml:mrow>
<mml:msubsup>
<mml:mover accent="true">
<mml:mi>x</mml:mi>
<mml:mo>¯</mml:mo></mml:mover>
<mml:mi>t</mml:mi>
<mml:mi>m</mml:mi></mml:msubsup></mml:mrow></mml:semantics></mml:math></inline-formula> with 
<inline-formula>
<mml:math id="mm75">
<mml:semantics id="sm75">
<mml:mrow>
<mml:msubsup>
<mml:mi>z</mml:mi>
<mml:mi>t</mml:mi>
<mml:mi>i</mml:mi></mml:msubsup></mml:mrow></mml:semantics></mml:math></inline-formula>. Thus, to compute the covariance, the compounding operation is linearized around 
<inline-formula>
<mml:math id="mm76">
<mml:semantics id="sm76">
<mml:mrow>
<mml:msubsup>
<mml:mover accent="true">
<mml:mi>x</mml:mi>
<mml:mo>¯</mml:mo></mml:mover>
<mml:mi>t</mml:mi>
<mml:mrow>
<mml:mo stretchy="false">[</mml:mo>
<mml:mi>m</mml:mi>
<mml:mo stretchy="false">]</mml:mo></mml:mrow></mml:msubsup></mml:mrow></mml:semantics></mml:math></inline-formula> and 
<inline-formula>
<mml:math id="mm77">
<mml:semantics id="sm77">
<mml:mrow>
<mml:msubsup>
<mml:mover accent="true">
<mml:mi>z</mml:mi>
<mml:mo>^</mml:mo></mml:mover>
<mml:mi>t</mml:mi>
<mml:mi>i</mml:mi></mml:msubsup></mml:mrow></mml:semantics></mml:math></inline-formula>. As defined in [<xref ref-type="bibr" rid="b1-sensors-09-10217">1</xref>], let <italic>J</italic><sub>1⊕</sub> and <italic>J</italic><sub>2⊕</sub> denote the Jacobian matrices of the compounding operator with respect to the first and second operands respectively, evaluated at the mentioned linearization points. Then, the covariance can be computed as follows:
<disp-formula id="FD9">
<label>(9)</label>
<mml:math id="mm78">
<mml:semantics id="sm78">
<mml:mrow>
<mml:mi>P</mml:mi>
<mml:mo>=</mml:mo>
<mml:msub>
<mml:mi>J</mml:mi>
<mml:mrow>
<mml:mn>1</mml:mn>
<mml:mo>⊕</mml:mo></mml:mrow></mml:msub>
<mml:msubsup>
<mml:mi>P</mml:mi>
<mml:mi>t</mml:mi>
<mml:mrow>
<mml:mo stretchy="false">[</mml:mo>
<mml:mi>m</mml:mi>
<mml:mo stretchy="false">]</mml:mo></mml:mrow></mml:msubsup>
<mml:msubsup>
<mml:mi>J</mml:mi>
<mml:mrow>
<mml:mn>1</mml:mn>
<mml:mo>⊕</mml:mo></mml:mrow>
<mml:mi>T</mml:mi></mml:msubsup>
<mml:mo>+</mml:mo>
<mml:msub>
<mml:mi>J</mml:mi>
<mml:mrow>
<mml:mn>2</mml:mn>
<mml:mo>⊕</mml:mo></mml:mrow></mml:msub>
<mml:msubsup>
<mml:mi>Q</mml:mi>
<mml:mi>t</mml:mi>
<mml:mi>i</mml:mi></mml:msubsup>
<mml:msubsup>
<mml:mi>J</mml:mi>
<mml:mrow>
<mml:mn>2</mml:mn>
<mml:mo>⊕</mml:mo></mml:mrow>
<mml:mi>T</mml:mi></mml:msubsup>
<mml:mo>+</mml:mo>
<mml:msub>
<mml:mi>P</mml:mi>
<mml:mi>j</mml:mi></mml:msub></mml:mrow></mml:semantics></mml:math></disp-formula></p>
<p>The Mahalanobis distance in <xref ref-type="disp-formula" rid="FD8">Equation 8</xref> is, under Gaussian assumption, a chi-squared distribution with 2 degrees of freedom. Thus, 
<inline-formula>
<mml:math id="mm79">
<mml:semantics id="sm79">
<mml:mrow>
<mml:msubsup>
<mml:mi>p</mml:mi>
<mml:mi>t</mml:mi>
<mml:mi>i</mml:mi></mml:msubsup></mml:mrow></mml:semantics></mml:math></inline-formula> and <italic>q<sub>j</sub></italic> are compatible if and only if 
<inline-formula>
<mml:math id="mm80">
<mml:semantics id="sm80">
<mml:mrow>
<mml:msup>
<mml:mi>D</mml:mi>
<mml:mn>2</mml:mn></mml:msup>
<mml:mo stretchy="false">(</mml:mo>
<mml:msubsup>
<mml:mi>p</mml:mi>
<mml:mi>t</mml:mi>
<mml:mi>i</mml:mi></mml:msubsup>
<mml:mo>,</mml:mo>
<mml:msub>
<mml:mi>q</mml:mi>
<mml:mi>j</mml:mi></mml:msub>
<mml:mo stretchy="false">)</mml:mo>
<mml:mo>&lt;</mml:mo>
<mml:msubsup>
<mml:mi>χ</mml:mi>
<mml:mrow>
<mml:mn>2</mml:mn>
<mml:mo>,</mml:mo>
<mml:mi>β</mml:mi></mml:mrow>
<mml:mn>2</mml:mn></mml:msubsup></mml:mrow></mml:semantics></mml:math></inline-formula>, where <italic>β</italic> is the desired confidence level. Accordingly, for each 
<inline-formula>
<mml:math id="mm81">
<mml:semantics id="sm81">
<mml:mrow>
<mml:msubsup>
<mml:mi>p</mml:mi>
<mml:mi>t</mml:mi>
<mml:mi>i</mml:mi></mml:msubsup></mml:mrow></mml:semantics></mml:math></inline-formula>, the set of compatible points in <italic>S<sub>old</sub></italic> is built. Among them, the corresponding point <italic>q<sub>j</sub></italic> is selected as the one which is closer to 
<inline-formula>
<mml:math id="mm82">
<mml:semantics id="sm82">
<mml:mrow>
<mml:msubsup>
<mml:mi>p</mml:mi>
<mml:mi>t</mml:mi>
<mml:mi>i</mml:mi></mml:msubsup></mml:mrow></mml:semantics></mml:math></inline-formula> in the Mahalanobis sense. That is, the set of correspondences is defined as follows:
<disp-formula id="FD10">
<label>(10)</label>
<mml:math display="block" id="mmm1">
<mml:semantics>
<mml:mrow>
<mml:mi>C</mml:mi>
<mml:mo>=</mml:mo>
<mml:mo stretchy="false">{</mml:mo>
<mml:mo stretchy="false">(</mml:mo>
<mml:msubsup>
<mml:mi>p</mml:mi>
<mml:mi>t</mml:mi>
<mml:mi>i</mml:mi></mml:msubsup>
<mml:mo>,</mml:mo>
<mml:msub>
<mml:mi>q</mml:mi>
<mml:mi>j</mml:mi></mml:msub>
<mml:mo stretchy="false">)</mml:mo>
<mml:mo>∀</mml:mo>
<mml:msubsup>
<mml:mi>p</mml:mi>
<mml:mi>t</mml:mi>
<mml:mi>i</mml:mi></mml:msubsup>
<mml:mo>∈</mml:mo>
<mml:msub>
<mml:mi>S</mml:mi>
<mml:mrow>
<mml:mtext mathvariant="italic">new</mml:mtext></mml:mrow></mml:msub>
<mml:mo stretchy="false">|</mml:mo>
<mml:msub>
<mml:mi>q</mml:mi>
<mml:mi>j</mml:mi></mml:msub>
<mml:mo>∈</mml:mo>
<mml:msub>
<mml:mi>S</mml:mi>
<mml:mrow>
<mml:mtext mathvariant="italic">old</mml:mtext></mml:mrow></mml:msub>
<mml:mo>,</mml:mo>
<mml:msub>
<mml:mi>q</mml:mi>
<mml:mi>j</mml:mi></mml:msub>
<mml:mo>=</mml:mo>
<mml:mo>arg</mml:mo>
<mml:mo>min</mml:mo>
<mml:msup>
<mml:mi>D</mml:mi>
<mml:mn>2</mml:mn></mml:msup>
<mml:mo stretchy="false">(</mml:mo>
<mml:msubsup>
<mml:mi>p</mml:mi>
<mml:mi>t</mml:mi>
<mml:mi>i</mml:mi></mml:msubsup>
<mml:mo>,</mml:mo>
<mml:msub>
<mml:mi>q</mml:mi>
<mml:mi>j</mml:mi></mml:msub>
<mml:mo stretchy="false">)</mml:mo>
<mml:mo>,</mml:mo>
<mml:msup>
<mml:mi>D</mml:mi>
<mml:mn>2</mml:mn></mml:msup>
<mml:mo stretchy="false">(</mml:mo>
<mml:msubsup>
<mml:mi>p</mml:mi>
<mml:mi>t</mml:mi>
<mml:mi>i</mml:mi></mml:msubsup>
<mml:mo>,</mml:mo>
<mml:msub>
<mml:mi>q</mml:mi>
<mml:mi>j</mml:mi></mml:msub>
<mml:mo stretchy="false">)</mml:mo>
<mml:mo>≤</mml:mo>
<mml:msubsup>
<mml:mi>χ</mml:mi>
<mml:mrow>
<mml:mn>2</mml:mn>
<mml:mo>,</mml:mo>
<mml:mi>β</mml:mi></mml:mrow>
<mml:mn>2</mml:mn></mml:msubsup>
<mml:mo stretchy="false">}</mml:mo></mml:mrow></mml:semantics></mml:math></disp-formula></p>
<p>To ease notation, let <italic>C</italic> = {&lt; <italic>a<sub>i</sub>, b<sub>i</sub></italic> &gt;, 1 ≤ <italic>i</italic> ≤ <italic>n</italic>} be the set of established correspondences between <italic>a<sub>i</sub></italic> ∈ <italic>S<sub>new</sub></italic> and <italic>b<sub>i</sub></italic> ∈ <italic>S<sub>old</sub></italic>. The sum of squared Mahalanobis distances between pairs of corresponding points,
<inline-formula>
<mml:math id="mm83">
<mml:semantics id="sm83">
<mml:mrow>
<mml:msubsup>
<mml:mo>∑</mml:mo>
<mml:mrow>
<mml:mi>i</mml:mi>
<mml:mo>=</mml:mo>
<mml:mn>1</mml:mn></mml:mrow>
<mml:mi>n</mml:mi></mml:msubsup>
<mml:mrow>
<mml:msup>
<mml:mi>D</mml:mi>
<mml:mn>2</mml:mn></mml:msup>
<mml:mo stretchy="false">(</mml:mo>
<mml:msub>
<mml:mi>a</mml:mi>
<mml:mi>i</mml:mi></mml:msub>
<mml:mo>,</mml:mo>
<mml:msub>
<mml:mi>b</mml:mi>
<mml:mi>i</mml:mi></mml:msub>
<mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:mrow></mml:semantics></mml:math></inline-formula>, is a good indicator of the degree of matching between <italic>S<sub>new</sub></italic> and <italic>S<sub>old</sub></italic>: the worse the matching, the bigger the sum of distances. However, the importance factor represents the opposite idea: particles that produce better matching should have higher weights. In consequence, the importance factor for particle <italic>m</italic> is computed as follows:
<disp-formula id="FD11">
<label>(11)</label>
<mml:math id="mm84">
<mml:semantics id="sm84">
<mml:mrow>
<mml:msubsup>
<mml:mi>w</mml:mi>
<mml:mi>t</mml:mi>
<mml:mrow>
<mml:mo stretchy="false">[</mml:mo>
<mml:mi>m</mml:mi>
<mml:mo stretchy="false">]</mml:mo></mml:mrow></mml:msubsup>
<mml:mo>=</mml:mo>
<mml:msup>
<mml:mrow>
<mml:mo stretchy="false">(</mml:mo>
<mml:munderover>
<mml:mo>∑</mml:mo>
<mml:mrow>
<mml:mi>i</mml:mi>
<mml:mo>=</mml:mo>
<mml:mn>1</mml:mn></mml:mrow>
<mml:mi>n</mml:mi></mml:munderover>
<mml:mrow>
<mml:msup>
<mml:mi>D</mml:mi>
<mml:mn>2</mml:mn></mml:msup>
<mml:mo stretchy="false">(</mml:mo>
<mml:msub>
<mml:mi>a</mml:mi>
<mml:mi>i</mml:mi></mml:msub>
<mml:mo>,</mml:mo>
<mml:msub>
<mml:mi>b</mml:mi>
<mml:mi>i</mml:mi></mml:msub>
<mml:mo stretchy="false">)</mml:mo></mml:mrow>
<mml:mo stretchy="false">)</mml:mo></mml:mrow>
<mml:mrow>
<mml:mo>−</mml:mo>
<mml:mn>1</mml:mn></mml:mrow></mml:msup></mml:mrow></mml:semantics></mml:math></disp-formula></p>
<p>At this point, our approach to Monte Carlo Localization using sonar sensors has been fully defined.</p></sec></sec>
<sec sec-type="results">
<label>5.</label>
<title>Experimental Results</title>
<sec>
<label>5.1.</label>
<title>Experimental Setup</title>
<p>The experimental results presented in this section are aimed at evaluating the quality of the presented particle filter localization approach and to compare the two proposed measurement models, both in terms of quality and time consumption.</p>
<p>To evaluate the sMCL, a <italic>Pioneer 3-DX</italic> robot, endowed with 16 Polaroid ultrasonic range finders and a <italic>Hokuyo URG-04LX</italic> laser scanner has been used. The robot has moved in three different environments in our university, gathering various data sets.</p>
<p>Each data set contains the odometry information, the sonar range readings and the laser range readings. The laser readings have only been used to obtain ground truth pose estimates. In order to obtain such ground truth, the ICP scan matching algorithm [<xref ref-type="bibr" rid="b13-sensors-09-10217">13</xref>] has been applied to the laser readings. The resulting ICP trajectory has been improved manually to overcome some of the ICP limitations. Finally, the wheel encoder readings have been corrupted with a small amount of Gaussian noise (<italic>μ</italic> = 0<italic>m/s</italic> and <italic>σ</italic><sup>2</sup> = 0.0025) to simulate worse floor conditions.</p>
<p><xref ref-type="fig" rid="f8-sensors-09-10217">Figure 8</xref> shows three of the gathered data sets, each of them corresponding to a different test environment. The first one (top row) corresponds to an area with rough walls, a glass door and two wooden doors. The data sets gathered in this environment are especially problematic to perform localization due to the curved trajectory. In the second environment (middle row), the most part of the walls are covered with wooden bookshelves. The junctions between the bookshelves produce large artifacts when observed with sonar sensors, as it can be observed on the top of the images. Additionally, the small squared room between the L-turn and the corridor is problematic because localization algorithms tend to align its walls with those of the corridor, although not being actually aligned. Finally, the third environment (bottom row) corresponds to two corridors with multiple entrances to offices. The walls are rough and some wooden panels cover them in different parts. Also, there are some wooden and stone columns. The average robot speed was 5.34 cm/s in the first environment, 5.05 cm/s in the second one and 14.5 cm/s in the third one.</p>
<p>In order to quantitatively compare odometry and the different particle filter configurations, the following procedure has been used. First, the trajectories obtained by odometry, particle filter and the ground truth are approximated by polylines. The vertex density of each polyline increases in those regions with significant amount of robot rotation. Also, the maximum robot motion between two vertexes has been set to 1 m. This kind of approximation is useful to overcome the local perturbations in the individual motion estimates, both for odometry, particle filter and ground truth. <xref ref-type="fig" rid="f9-sensors-09-10217">Figure 9</xref> exemplifies the polyline approximation.</p>
<p>Then, the individual edges of the trajectory being evaluated are locally compared to those of the ground truth. The Euclidean distance between their end points is used as a measure of the edge error. Finally, the edge errors for the trajectory being evaluated are summed. This sum is normalized, using the path lengths between vertexes and the number of edges, and constitutes the <italic>trajectory error.</italic> Due to the mentioned normalization, the errors of different trajectories can be compared. It is important to emphasize that, as a result of the mentioned procedure, the evaluation takes into account the whole trajectory, not only its end points.</p>
<p>The sonar-based particle localization algorithm described in Section 3. has also been implemented using a different measurement model. This different measurement model is the well known ICP error, which uses Euclidean distance to establish correspondences. Then, the probability distribution 
<inline-formula>
<mml:math id="mm85">
<mml:semantics id="sm85">
<mml:mrow>
<mml:mi>p</mml:mi>
<mml:mrow>
<mml:mo stretchy="false">(</mml:mo>
<mml:mrow>
<mml:msub>
<mml:mi>z</mml:mi>
<mml:mi>t</mml:mi></mml:msub>
<mml:mo stretchy="false">|</mml:mo>
<mml:msubsup>
<mml:mover accent="true">
<mml:mi>x</mml:mi>
<mml:mo>¯</mml:mo></mml:mover>
<mml:mi>t</mml:mi>
<mml:mrow>
<mml:mo stretchy="false">[</mml:mo>
<mml:mi>m</mml:mi>
<mml:mo stretchy="false">]</mml:mo></mml:mrow></mml:msubsup>
<mml:mo>,</mml:mo>
<mml:msubsup>
<mml:mi>s</mml:mi>
<mml:mrow>
<mml:mi>t</mml:mi>
<mml:mo>−</mml:mo>
<mml:mn>1</mml:mn></mml:mrow>
<mml:mrow>
<mml:mo stretchy="false">[</mml:mo>
<mml:mi>m</mml:mi>
<mml:mo stretchy="false">]</mml:mo></mml:mrow></mml:msubsup></mml:mrow>
<mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:mrow></mml:semantics></mml:math></inline-formula> is defined as the inverse of the sum of Euclidean distances between pairs of corresponding points. Thus, a well-known and widely used algorithm has also been quantitatively evaluated in the described particle filter context and compared to our approach. To distinguish between the two MCL approaches, the one described in this paper will be referred to as the <italic>sonar probabilistic Monte Carlo Localization</italic> (spMCL) and the one that makes use of the ICP error will be named <italic>ICP Monte Carlo Localization</italic> (icpMCL).</p></sec>
<sec>
<label>5.2.</label>
<title>Evaluating the Influence of the Number of Particles</title>
<p>The first experiment evaluates the quality and the execution time of the algorithms with respect to the number of particles, <italic>M</italic>. The values of <italic>M</italic> that have been tested are 10 and 50, to see how the algorithm behaves with a small number of particles, and then 100, 200 and 400 particles. The particles history size has been set to <italic>k</italic> = 100. The trajectory error has been computed for odometry, for the icpMCL and for the spMCL.</p>
<p><xref ref-type="fig" rid="f10-sensors-09-10217">Figure 10a</xref> depicts the mean and the standard deviation of the obtained trajectory errors for all the data sets. The graphical representation of the standard deviation has been reduced to a 20% of its real value, both for particle filters and odometry, to provide a clear representation. Also, although the odometric error does not depend on the number of particles, it has been included on the Figure as an horizontal line with constant standard deviation for comparison purposes.</p>
<p>The first thing to be noticed is that the two measurement models presented in this paper significantly reduce the odometric error. Also, the results provided by the spMCL are significantly better than those obtained when the ICP error is used. Even if only 10 particles are used, the spMCL provides trajectories which are, in mean, a 74.9% better than the odometric estimates and a 42.8% better than the icpMCL. If 400 particles are used, spMCL provides trajectories which are, in mean, a 101.3% better than odometry. Also, the standard deviations of the particle filter trajectories are significantly lower than those of odometry. This suggests that the quality of the particle filter estimates is barely influenced by the errors in odometry. Moreover, the reduced standard deviation also suggests that the trajectory error after the particle filter operation is similar for all of the tested environments.</p>
<p>The second thing to be noticed is that only a very small error reduction appears if more than 200 particles are used. This suggests that the proposed weighting methods are able to accurately select the right particles. It also suggests that using a number of particles between 100 and 200 would be a good choice, more if the execution times are taken into account.</p>
<p>The mean and the standard deviation of the execution times per data set item for the particle filter algorithm using each of the measurement models presented in this paper are shown in <xref ref-type="fig" rid="f10-sensors-09-10217">Figure 10b</xref>. It is important to emphasize that these execution times correspond to a non optimized Matlab implementation. Thus, the absolute values are meaningless, as a C++ implementation will greatly increase the execution speed. The main interest of these results is to see how the execution times evolve with the number of particles and to compare the two proposed measurement models in terms of computational requirements.</p>
<p>It can be observed how the execution times are strongly linear with the number of particles. The small standard deviations suggest that there is a very small dependence on the number of effective readings in each <italic>S<sub>old</sub></italic> and <italic>S<sub>new</sub></italic> and also a very small dependence on the odometric error and the particularities of each environment. Also, the linear relation between time and number of particles reinforces the idea that using between 100 and 200 particles is the better choice: the small improvement of using more particles does not compensate the increase in computation time.</p>
<p>Finally, it is clear that the icpMCL is significantly faster than spMCL in terms of the number of particles. Still, the quality of the pose estimates has to be taken into account when analyzing the time consumption. For example, using only 10 particles in spMCL provides, in mean, trajectories a 10.11% better than those provided by icpMCL when using 100 particles. Moreover, in this case, the probabilistic approach is a 59% faster than the ICP error based approach. As a matter of fact, using 10 particles in spMCL leads to better results than the icpMCL with any of the tested number of particles. Thus, when analyzing the time consumption required to achieve a certain trajectory error, the spMCL also provides significantly better results than the icpMCL.</p></sec>
<sec>
<label>5.3.</label>
<title>Evaluating the Influence of the Local Map Size</title>
<p>The previous experiment has been performed using a local map size <italic>k</italic> = 100. In order to quantify the effects of using different history sizes, a second experiment has been performed. Now, the number of particles is set to 100, as it has shown to be a good choice, and the local map sizes <italic>k</italic> = 25, <italic>k</italic> = 50, <italic>k</italic> = 100, <italic>k</italic> = 200 and <italic>k</italic> = 400 are tested. Both the trajectory error and the execution times are measured. <xref ref-type="fig" rid="f11-sensors-09-10217">Figure 11a</xref> shows the mean and the standard deviation of the trajectory errors, both for odometry and the two particle filter configurations. The standard deviation has been graphically reduced to a 20% to provide a clear representation.</p>
<p>It can be observed that the effects of the local map size are more noticeable than those of the number of particles. For example, in the spMCL case, the trajectory error using <italic>M</italic> = 100 and <italic>k</italic> = 400 is a 19.9% lower than the trajectory error using <italic>M</italic> = 400 and <italic>k</italic> = 100. It can also be observed how the error reduction ratio significantly decreases from <italic>k</italic> = 100 onwards.</p>
<p>The icpMCL does not perform very well when low local map sizes are used. For instance, in the case <italic>k</italic> = 25, icpMCL produces results worse than odometry. To the contrary, even in that case, spMCL greatly improves the odometric results and provides trajectories a 57.9% better than icpMCL.</p>
<p><xref ref-type="fig" rid="f11-sensors-09-10217">Figure 11b</xref> shows the mean and the standard deviation of the execution times per data set item, with respect to the local map size. Similarly to the previous experiment, these times correspond to a non optimized Matlab implementation.</p>
<p>The first thing to be noticed is related to the nonlinear relation between <italic>k</italic> and the execution time. Changes in the computation time should be linear with the local map size. As stated previously, the computations in the measurement model are achieved by comparing the readings in <italic>z<sub>t</sub></italic> to the local maps. As the size of <italic>z<sub>t</sub></italic> does not depend on the local map size, increasing the value of <italic>k</italic> should result in a linear increment of the execution time. However, the times shown in <xref ref-type="fig" rid="f11-sensors-09-10217">Figure 11b</xref> for spMCL seem to contradict this affirmation. Nonetheless, there is no contradiction. It has also to be taken into account the increasing memory requirements to store the local maps and the associated covariance matrices. The time spent by the operating system and Matlab itself for memory management is, in this case, responsible of the non linearities in the execution times.</p>
<p>It can also be observed that the ICP error based approach is significantly faster than spMCL with respect to the local map size. The situation in this experiment is different to the previous experiment. For instance, the computation time for spMCL using <italic>k</italic> = 25 is below the computation time for icpMCL using <italic>k</italic> = 400. However, the quality of the ICP error based for <italic>k</italic> = 400 is better than the one of spMCL using <italic>k</italic> = 10. Thus, in a hypothetical situation in which only <italic>k</italic> could be changed and <italic>M</italic> had to remain unchanged, the ICP error based approach is preferable.</p>
<p>Nonetheless, when taking into account both the number of particles and the local map size, spMCL provides better results. For example, the use of only 10 particles and a local map size of 100 in spMCL provides a trajectory error which is a 5.8% lower than the ICP error based approach using 100 particles and a map size of 200. Moreover, in this case, the spMCL approach is significantly faster than the icpMCL.</p>
<p>Overall, it is clear that spMCL is not as well suited as the icpMCL to deal with large local maps in terms of computational requirements. Still, spMCL is able to provide significantly better results with very reduced numbers of particles and small local map sizes than the icpMCL using larger particle sets.</p></sec>
<sec>
<label>5.4.</label>
<title>Qualitative Evaluation</title>
<p>In order to illustrate the previous results, some data sets have been plotted according to the obtained trajectories for visual inspection. <xref ref-type="fig" rid="f8-sensors-09-10217">Figure 8</xref> shows some examples of the data sets used in the experiments. The left column shows the sonar readings drawn according to the initial odometric estimates. As stated previously, these odometric estimates, which constitute the control vectors <italic>u<sub>t</sub></italic> which have been used to fed the particle filters, are corrupted with Gaussian random noise. The right column shows the sonar readings drawn according to the ground truth trajectory.</p>
<p>According to the previous experiments, the spMCL with only 10 particles lead the particle filter to better results than the use of the ICP error based with much higher numbers of particles. <xref ref-type="fig" rid="f12-sensors-09-10217">Figure 12</xref> illustrates this idea. The left column shows some of the results obtained when using the ICP error based measurement model with <italic>M</italic> = 100. The right column depicts some results obtained when using spMCL with only 10 particles.</p>
<p>There are some details that deserve some attention in this Figure. First, the two measurement models are able to significantly improve the odometric estimates and to provide results which are close to the ground truth. Second, the spMCL is able to match the readings more accurately than the icpMCL. This is especially clear in the second row, where the readings drawn according to the spMCL define thinner walls than those obtained by means of the ICP error based one. Finally, the results provided by spMCL provide, in general, better trajectory estimates for <italic>M</italic> = 10 than those provided by icpMCL using <italic>M</italic> = 100.</p>
<p>In <xref ref-type="fig" rid="f13-sensors-09-10217">Figure 13</xref> the sonar readings have been drawn according to the two proposed measurement models using 400 particles in both cases. The left column shows the results for the ICP error based approach. The results corresponding to spMCL are presented in the right column. It can be observed that spMCL provides better results than icpMCL. Moreover, spMCL is able to generate trajectories which are very close to the ground truth.</p>
<p>Overall, the two sMCL approaches presented in this paper provide significant improvements in the pose estimates with respect to raw odometry. In particular, the spMCL has shown to provide trajectories which are very close to the ground truth. As stated previously, the ground truth has been obtained by manually improving the ICP pose estimates using laser readings. Moreover, the odometry estimates used in the particle filters are worse than those used for the ICP to build the ground truth. Thus, the results obtained with spMCL are comparable to those obtained with the well known ICP algorithm and laser sensors.</p></sec></sec>
<sec sec-type="conclusions">
<label>6.</label>
<title>Conclusions</title>
<p>This paper is concerned to the use of sonar sensors to perform mobile robot localization. To this end, the Polaroid ultrasonic range finder has been experimentally characterized. Thanks to this characterization, parameters such as the resolution, the minimum and maximum ranges, the maximum angle of incidence, the opening or the accuracy have been obtained. Among them, the opening and the accuracy have shown to depend on the range to the detected obstacle.</p>
<p>Afterwards, a novel approach to mobile robot localization using sonar sensors has been presented. This approach relies on the use of particle filters. Each particle is augmented with a set of sonar readings, which is updated during the mission execution. These sets of sonar readings, which constitute the particles' local views of the environment, have two main goals. First, to overcome the sparseness of the sets of readings provided by ultrasonic range finders. Second, to avoid the need for <italic>a priori</italic> maps.</p>
<p>In order to weight the particles, a probabilistic correlation method is proposed. This method models the sonar readings as bivariate Normal distributions, allowing the use of statistical compatibility tests to evaluate the degree of matching between two sets of sonar readings. The parameters of the Normal distributions modeling the sonar readings come from the opening and the accuracy that were previously obtained.</p>
<p>The method has been evaluated by measuring the quality of its estimates for different numbers of particles and history sizes. Our measurement model has been compared to the well known ICP error approach, showing significantly better results. Also, the results show how the proposed sonar-based particle localization approach is well suited to deal with the sparseness and low angular resolution of sonar readings and provide good estimates of the robot pose using sonar sensors without any <italic>a priori</italic> map.</p></sec></body>
<back>
<ack>
<p>This work is partially supported by DPI 2008-06548-C03-02 and FEDER funding.</p></ack>
<ref-list>
<title>References</title>
<ref id="b1-sensors-09-10217"><label>1.</label><citation citation-type="journal"><person-group person-group-type="author"><name><surname>Tardós</surname><given-names>J.D.</given-names></name><name><surname>Neira</surname><given-names>J.</given-names></name><name><surname>Newman</surname><given-names>P.M.</given-names></name><name><surname>Leonard</surname><given-names>J.J.</given-names></name></person-group><article-title>Robust Mapping and Localization in Indoor Environments using Sonar Data</article-title><source>Int. J. Robotics Res.</source><year>2002</year><volume>21</volume><fpage>311</fpage><lpage>330</lpage><pub-id pub-id-type="doi">10.1177/027836402320556340</pub-id></citation></ref>
<ref id="b2-sensors-09-10217"><label>2.</label><citation citation-type="journal"><person-group person-group-type="author"><name><surname>Groβmann</surname><given-names>A.</given-names></name><name><surname>Poli</surname><given-names>R.</given-names></name></person-group><article-title>Robust Mobile Robot Localisation from Sparse and Noisy Proximity Readings Using Hough Transform and Probability Grids</article-title><source>Robot. Auton. Syst.</source><year>2001</year><volume>37</volume><fpage>1</fpage><lpage>18</lpage><pub-id pub-id-type="doi">10.1016/S0921-8890(01)00144-0</pub-id></citation></ref>
<ref id="b3-sensors-09-10217"><label>3.</label><citation citation-type="journal"><person-group person-group-type="author"><name><surname>Burguera</surname><given-names>A.</given-names></name><name><surname>González</surname><given-names>Y.</given-names></name><name><surname>Oliver</surname><given-names>G.</given-names></name></person-group><article-title>A Probabilistic Framework for Sonar Scan Matching Localization</article-title><source>Adv. Robot.</source><year>2008</year><volume>22</volume><fpage>1223</fpage><lpage>1241</lpage><pub-id pub-id-type="doi">10.1163/156855308X338447</pub-id></citation></ref>
<ref id="b4-sensors-09-10217"><label>4.</label><citation citation-type="journal"><person-group person-group-type="author"><name><surname>Hernández</surname><given-names>E.</given-names></name><name><surname>Ridao</surname><given-names>P.</given-names></name><name><surname>Ribas</surname><given-names>D.</given-names></name><name><surname>Batlle</surname><given-names>J.</given-names></name></person-group><article-title>MSISpIC: A Probabilistic Scan Matching Algorithm Using a Mechanical Scanned Imaging Sonar</article-title><source>J. Phys. Agents</source><year>2009</year><volume>3</volume><fpage>3</fpage><lpage>11</lpage></citation></ref>
<ref id="b5-sensors-09-10217"><label>5.</label><citation citation-type="journal"><person-group person-group-type="author"><name><surname>Choi</surname><given-names>Y.H.</given-names></name><name><surname>Oh</surname><given-names>S.Y.</given-names></name></person-group><article-title>Map Building through Pseudo Dense Scan Matching Using Visual Sonar Data</article-title><source>Auton. Robots</source><year>2007</year><volume>23</volume><fpage>293</fpage><lpage>304</lpage><pub-id pub-id-type="doi">10.1007/s10514-007-9046-7</pub-id></citation></ref>
<ref id="b6-sensors-09-10217"><label>6.</label><citation citation-type="confproc"><person-group person-group-type="author"><name><surname>Dellaert</surname><given-names>F.</given-names></name><name><surname>Burgard</surname><given-names>W.</given-names></name><name><surname>Thrun</surname><given-names>S.</given-names></name></person-group><article-title>Monte Carlo Localization for Mobile Robots</article-title><conf-name>Proceedings of the IEEE International Conference on Robotics and Automation (ICRA)</conf-name><conf-loc>Detroit, MI, USA</conf-loc><conf-date>May 10–15, 1999</conf-date></citation></ref>
<ref id="b7-sensors-09-10217"><label>7.</label><citation citation-type="confproc"><person-group person-group-type="author"><name><surname>Montemerlo</surname><given-names>M.</given-names></name><name><surname>Thrun</surname><given-names>S.</given-names></name><name><surname>Koller</surname><given-names>D.</given-names></name><name><surname>Wegbreit</surname><given-names>B.</given-names></name></person-group><article-title>FastSLAM: A Factored Solution to the Simultaneous Localization and Mapping Problem</article-title><conf-name>Proceedings of the AAAI National Conference on Artificial Intelligence</conf-name><conf-loc>Edmonton, Alberta, Canada</conf-loc><conf-date>July 28–August 1, 2002</conf-date></citation></ref>
<ref id="b8-sensors-09-10217"><label>8.</label><citation citation-type="confproc"><person-group person-group-type="author"><name><surname>Hähnel</surname><given-names>D.</given-names></name><name><surname>Burgard</surname><given-names>W.</given-names></name><name><surname>Fox</surname><given-names>D.</given-names></name><name><surname>Thrun</surname><given-names>S.</given-names></name></person-group><article-title>An Efficient FastSLAM Algorithm for Generating Maps of Large-Scale Cyclic Environments from Raw Laser Range Measurements</article-title><conf-name>Proceedings of the IEEE/RSJ International Conference on Intelligent Robots and Systems (IROS)</conf-name><conf-date>October 27–31, 2003</conf-date><conf-loc>Las Vegas, NV, USA</conf-loc><year>2003</year><comment>Volume 1</comment><fpage>206</fpage><lpage>211</lpage></citation></ref>
<ref id="b9-sensors-09-10217"><label>9.</label><citation citation-type="journal"><person-group person-group-type="author"><name><surname>Fox</surname><given-names>D.</given-names></name><name><surname>Burgard</surname><given-names>W.</given-names></name><name><surname>Kruppa</surname><given-names>H.</given-names></name><name><surname>Thrun</surname><given-names>S.</given-names></name></person-group><article-title>A Probabilistic Approach to Collaborative Multi-Robot Localization</article-title><source>Autono. Robots</source><year>2000</year><volume>8</volume><fpage>325</fpage><lpage>344</lpage><pub-id pub-id-type="doi">10.1023/A:1008937911390</pub-id></citation></ref>
<ref id="b10-sensors-09-10217"><label>10.</label><citation citation-type="confproc"><person-group person-group-type="author"><name><surname>Yaqub</surname><given-names>T.</given-names></name><name><surname>Katupitiya</surname><given-names>J.</given-names></name></person-group><article-title>Laser Scan Matching for Measurement Update in a Particle Filter</article-title><conf-name>Proceedings of IEEE/ASME International Conference on Advanced Intelligent Mechatronics</conf-name><conf-loc>ETH Zurich, Switzerland</conf-loc><conf-date>September 4–7, 2007</conf-date><fpage>1</fpage><lpage>6</lpage></citation></ref>
<ref id="b11-sensors-09-10217"><label>11.</label><citation citation-type="journal"><person-group person-group-type="author"><name><surname>Thrun</surname><given-names>S.</given-names></name><name><surname>Fox</surname><given-names>D.</given-names></name><name><surname>Burgard</surname><given-names>W.</given-names></name><name><surname>Dellaert</surname><given-names>F.</given-names></name></person-group><article-title>Robust Monte Carlo Localization for Mobile Robots</article-title><source>Artif. Intell.</source><year>2001</year><volume>128</volume><fpage>99</fpage><lpage>141</lpage><pub-id pub-id-type="doi">10.1016/S0004-3702(01)00069-8</pub-id></citation></ref>
<ref id="b12-sensors-09-10217"><label>12.</label><citation citation-type="confproc"><person-group person-group-type="author"><name><surname>Silver</surname><given-names>D.</given-names></name><name><surname>Morales</surname><given-names>D.</given-names></name><name><surname>Rekleitis</surname><given-names>I.</given-names></name><name><surname>Lisien</surname><given-names>B.</given-names></name><name><surname>Choset</surname><given-names>H.</given-names></name></person-group><article-title>Arc Carving: Obtaining Accurate, Low Latency Maps from Ultrasonic Range Sensors</article-title><conf-name>Proceedings of IEEE International Conference on Robotics and Automation</conf-name><conf-loc>New Orleans, LA, USA</conf-loc><conf-date>April 26–May 1, 2004</conf-date><volume>2</volume><fpage>1554</fpage><lpage>1561</lpage></citation></ref>
<ref id="b13-sensors-09-10217"><label>13.</label><citation citation-type="journal"><person-group person-group-type="author"><name><surname>Lu</surname><given-names>F.</given-names></name><name><surname>Milios</surname><given-names>E.</given-names></name></person-group><article-title>Robot Pose Estimation in Unknown Environments by Matching 2D Range Scans</article-title><source>J. Intell. Robotic Syst.</source><year>1997</year><volume>18</volume><fpage>249</fpage><lpage>275</lpage><pub-id pub-id-type="doi">10.1023/A:1007957421070</pub-id></citation></ref>
<ref id="b14-sensors-09-10217"><label>14.</label><citation citation-type="book"><person-group person-group-type="author"><name><surname>Burguera</surname><given-names>A.</given-names></name><name><surname>González</surname><given-names>Y.</given-names></name><name><surname>Oliver</surname><given-names>G.</given-names></name></person-group><article-title>Mobile Robot Localization Using Particle Filters and Sonar Sensors</article-title><source>Advances in Sonar Technology</source><publisher-name>In-Tech</publisher-name><publisher-loc>Vienna, Austria</publisher-loc><year>2009</year><comment>Chapter 10</comment><fpage>213</fpage><lpage>232</lpage></citation></ref>
<ref id="b15-sensors-09-10217"><label>15.</label><citation citation-type="book"><person-group person-group-type="author"><name><surname>Robotics</surname><given-names>A.</given-names></name></person-group><source>Pioneer 3™ and Pioneer 2™ H8-Series Operations Manual</source><publisher-name>ActivMedia Robotics</publisher-name><publisher-loc>New York, NY, USA</publisher-loc><year>2003</year></citation></ref>
<ref id="b16-sensors-09-10217"><label>16.</label><citation citation-type="book"><person-group person-group-type="author"><name><surname>Kleeman</surname><given-names>L.</given-names></name><name><surname>Kuc</surname><given-names>R.</given-names></name></person-group><article-title>Sonar Sensing</article-title><source>Springer Handbook of Robotics</source><publisher-name>Springer Berlin Heidelberg</publisher-name><publisher-loc>Berlin, Germany</publisher-loc><year>2008</year><fpage>491</fpage><lpage>519</lpage></citation></ref>
<ref id="b17-sensors-09-10217"><label>17.</label><citation citation-type="web"><person-group person-group-type="author"><collab>SensComp</collab></person-group><source>600 Series Instrument Transducer</source><year>2004</year><comment>Available online: <ext-link xlink:href="http://www.senscomp.com" ext-link-type="uri">http://www.senscomp.com</ext-link> (accessed on 16 December 2009)</comment></citation></ref>
<ref id="b18-sensors-09-10217"><label>18.</label><citation citation-type="journal"><person-group person-group-type="author"><name><surname>Moravec</surname><given-names>H.</given-names></name></person-group><article-title>Sensor Fusion in Certainty Grids for Mobile Robots</article-title><source>AI Magazine</source><year>1988</year><volume>9</volume><fpage>61</fpage><lpage>74</lpage></citation></ref>
<ref id="b19-sensors-09-10217"><label>19.</label><citation citation-type="thesis"><person-group person-group-type="author"><name><surname>Blum</surname><given-names>F.</given-names></name></person-group><article-title>A Focused, Two Dimensional, Air-Coupled Ultrasonic Array for Non-Contact Generation</article-title><source>Master's Thesis</source><publisher-name>Georgia Institute of Technology</publisher-name><publisher-loc>Atlanta, GA, USA</publisher-loc><year>2003</year></citation></ref>
<ref id="b20-sensors-09-10217"><label>20.</label><citation citation-type="confproc"><person-group person-group-type="author"><name><surname>Fonseca</surname><given-names>J.</given-names></name><name><surname>Martins</surname><given-names>J.</given-names></name><name><surname>Couto</surname><given-names>C.</given-names></name></person-group><article-title>An Experimental Model For Sonar Sensors</article-title><conf-name>Proceedings of the 1st International Conference on Information Technology in Mechatronics</conf-name><conf-loc>Istanbul, Turkey</conf-loc><conf-date>October 1–3, 2001</conf-date></citation></ref>
<ref id="b21-sensors-09-10217"><label>21.</label><citation citation-type="journal"><person-group person-group-type="author"><name><surname>Harris</surname><given-names>K.</given-names></name><name><surname>Recce</surname><given-names>M.</given-names></name></person-group><article-title>Experimental Modelling of Time-of-Flight Sonar</article-title><source>Robot. Auton. Syst.</source><year>1998</year><volume>24</volume><fpage>33</fpage><lpage>42</lpage><pub-id pub-id-type="doi">10.1016/S0921-8890(98)00020-7</pub-id></citation></ref>
<ref id="b22-sensors-09-10217"><label>22.</label><citation citation-type="book"><person-group person-group-type="author"><name><surname>Lee</surname><given-names>D.</given-names></name></person-group><source>The Map-Building and Exploration Strategies of a Simple Sonar-Equipped Mobile Robot</source><publisher-name>Cambridge University Press</publisher-name><publisher-loc>Cambridge, UK</publisher-loc><year>1996</year></citation></ref>
<ref id="b23-sensors-09-10217"><label>23.</label><citation citation-type="book"><person-group person-group-type="author"><name><surname>Andreu Mestre</surname><given-names>J.</given-names></name></person-group><source>Tuning of Odometry and Sonar in a Mobile Robot for Autonomous Navigation Improvement</source><publisher-name>Graduation project, Departament de Matemàtiques i Informàtica, Universitat de les Illes Balears</publisher-name><publisher-loc>Palma, Spain</publisher-loc><year>2005</year><comment>(in catalan)</comment></citation></ref>
<ref id="b24-sensors-09-10217"><label>24.</label><citation citation-type="confproc"><person-group person-group-type="author"><name><surname>Fox</surname><given-names>D.</given-names></name><name><surname>Burgard</surname><given-names>W.</given-names></name><name><surname>Dellaert</surname><given-names>F.</given-names></name><name><surname>Thrun</surname><given-names>S.</given-names></name></person-group><article-title>Monte Carlo Localization: Efficient Position Estimation for Mobile Robots</article-title><conf-name>Proceedings of the 16th National Conference on Artificial Intelligence</conf-name><conf-loc>Orlando, FL, USA</conf-loc><conf-date>May 1–5, 1999</conf-date></citation></ref>
<ref id="b25-sensors-09-10217"><label>25.</label><citation citation-type="confproc"><person-group person-group-type="author"><name><surname>Smith</surname><given-names>R.</given-names></name><name><surname>Self</surname><given-names>M.</given-names></name><name><surname>Cheeseman</surname><given-names>P.</given-names></name></person-group><article-title>Estimating Uncertain Spatial Relationships in Robotics</article-title><conf-name>Proceedings of 1987 IEEE International Conference on Robotics and Automation</conf-name><conf-loc>Washington, DC, USA</conf-loc><conf-date>March 1987</conf-date></citation></ref>
<ref id="b26-sensors-09-10217"><label>26.</label><citation citation-type="book"><person-group person-group-type="author"><name><surname>Thrun</surname><given-names>S.</given-names></name><name><surname>Burgard</surname><given-names>W.</given-names></name><name><surname>Fox</surname><given-names>D.</given-names></name></person-group><source>Probabilistic Robotics</source><publisher-name>The MIT Press</publisher-name><publisher-loc>Cambridge, MA, USA</publisher-loc><year>2005</year></citation></ref>
<ref id="b27-sensors-09-10217"><label>27.</label><citation citation-type="confproc"><person-group person-group-type="author"><name><surname>Montemerlo</surname><given-names>M.</given-names></name><name><surname>Thrun</surname><given-names>S.</given-names></name><name><surname>Koller</surname><given-names>D.</given-names></name><name><surname>Wegbreit</surname><given-names>B.</given-names></name></person-group><article-title>FastSLAM 2.0: An Improved Particle Filtering Algorithm for Simultaneous Localization and Mapping that Provably Converges</article-title><conf-name>Proceedings of the Sixteenth International Joint Conference on Artificial Intelligence</conf-name><conf-loc>Stockholm, Sweden</conf-loc><conf-date>July 31–August 6, 2003</conf-date></citation></ref>
<ref id="b28-sensors-09-10217"><label>28.</label><citation citation-type="journal"><person-group person-group-type="author"><name><surname>Gustafsson</surname><given-names>F.</given-names></name><name><surname>Gunnarsson</surname><given-names>F.</given-names></name><name><surname>Bergman</surname><given-names>N.</given-names></name><name><surname>Forssell</surname><given-names>U.</given-names></name><name><surname>Jansson</surname><given-names>J.</given-names></name><name><surname>Karlsson</surname><given-names>R.</given-names></name><name><surname>Nordlund</surname><given-names>P.J.</given-names></name></person-group><article-title>Particle Filters for Positioning, Navigation and Tracking</article-title><source>IEEE Trans. Signal Process.</source><year>2002</year><volume>20</volume><fpage>425</fpage><lpage>437</lpage></citation></ref>
<ref id="b29-sensors-09-10217"><label>29.</label><citation citation-type="confproc"><person-group person-group-type="author"><name><surname>Rusinkiewicz</surname><given-names>S.</given-names></name><name><surname>Levoy</surname><given-names>M.</given-names></name></person-group><article-title>Efficient Variants of the ICP Algorithm</article-title><conf-name>Proceedings of the 3rd International Conference on 3D Digital Imaging and Modeling (3DIM)</conf-name><conf-loc>Quebec, Canada</conf-loc><conf-date>May 28–June 1, 2001</conf-date></citation></ref>
<ref id="b30-sensors-09-10217"><label>30.</label><citation citation-type="confproc"><person-group person-group-type="author"><name><surname>Biber</surname><given-names>P.</given-names></name><name><surname>Fleck</surname><given-names>S.</given-names></name><name><surname>Strasser</surname><given-names>W.</given-names></name></person-group><article-title>A Probabilistic Framework for Robust and Accurate Matching of Point Clouds</article-title><conf-name>Proceedings of the 26th Pattern Recognition Symposium (DAGM)</conf-name><conf-loc>Tubingen, Germany</conf-loc><conf-date>August 30–September 1, 2004</conf-date></citation></ref></ref-list>
<sec sec-type="display-objects">
<title>Figures</title>
<fig id="f1-sensors-09-10217" position="float">
<label>Figure 1.</label>
<caption>
<p>(a) Position of an object with respect to the sensor in polar coordinates. (b) Normalized sound pressure as a function of the azimuth. (c) Polar representation of the sound pressure level. The azimuth is expressed in degrees and the SPL in dB. (d) The wedge model.</p></caption>
<graphic xlink:href="sensors-09-10217f1a.gif"/>
<graphic xlink:href="sensors-09-10217f1b.gif"/>
<graphic xlink:href="sensors-09-10217f1c.gif"/>
<graphic xlink:href="sensors-09-10217f1d.gif"/></fig>
<fig id="f2-sensors-09-10217" position="float">
<label>Figure 2.</label>
<caption>
<p>Measured distance vs. actual distance plot. For each actual distance, 100 measurements are shown. (a) Minimum range. (b) Maximum range. The resolution of 1mm can be observed in both images.</p></caption>
<graphic xlink:href="sensors-09-10217f2a.gif"/>
<graphic xlink:href="sensors-09-10217f2b.gif"/></fig>
<fig id="f3-sensors-09-10217" position="float">
<label>Figure 3.</label>
<caption>
<p>(a) Graphical representation of the sonar opening. The horizontal dashed line represents the sensor acoustic axis. The theoretical opening is shown as the two dotted lines. (b) Accuracy. Mean and standard deviation of the errors for different ranges.</p></caption>
<graphic xlink:href="sensors-09-10217f3a.gif"/>
<graphic xlink:href="sensors-09-10217f3b.gif"/></fig>
<fig id="f4-sensors-09-10217" position="float">
<label>Figure 4.</label>
<caption>
<p>Notation used for sMCL. The triangles represent the robot at consecutive poses.</p></caption>
<graphic xlink:href="sensors-09-10217f4.gif"/></fig>
<fig id="f5-sensors-09-10217" position="float">
<label>Figure 5.</label>
<caption>
<p>(a) Example of the particle filter operation. The local maps 
<inline-formula>
<mml:math id="mm86">
<mml:semantics id="sm86">
<mml:mrow>
<mml:msubsup>
<mml:mi>s</mml:mi>
<mml:mi>t</mml:mi>
<mml:mrow>
<mml:mo stretchy="false">[</mml:mo>
<mml:mn>1</mml:mn>
<mml:mo>:</mml:mo>
<mml:mi>M</mml:mi>
<mml:mo stretchy="false">]</mml:mo></mml:mrow></mml:msubsup></mml:mrow></mml:semantics></mml:math></inline-formula> are depicted with black dots. The circles over the local maps represent the current readings <italic>z<sub>t</sub></italic> according to each particle. The black lines on the center represent a short history of the robot poses in 
<inline-formula>
<mml:math id="mm87">
<mml:semantics id="sm87">
<mml:mrow>
<mml:msubsup>
<mml:mi>x</mml:mi>
<mml:mi>t</mml:mi>
<mml:mrow>
<mml:mo stretchy="false">[</mml:mo>
<mml:mi>m</mml:mi>
<mml:mo stretchy="false">]</mml:mo></mml:mrow></mml:msubsup></mml:mrow></mml:semantics></mml:math></inline-formula>. These trajectories are not part of the particle filter, and are only depicted for clarity purposes. Finally, the ellipse represents the 99% confidence interval corresponding to the Gaussian approximation. (b) Detail of the Gaussian approximation.</p></caption>
<graphic xlink:href="sensors-09-10217f5a.gif"/>
<graphic xlink:href="sensors-09-10217f5b.gif"/></fig>
<fig id="f6-sensors-09-10217" position="float">
<label>Figure 6.</label>
<caption>
<p>(a) The proposed sonar model. The ellipses represent the 99% confidence interval of the Normal distributions modeling the readings for different ranges. (b) Relation between the sensor models. The circular sector represents the sonar beam. The dashed cross is the robot reference frame.</p></caption>
<graphic xlink:href="sensors-09-10217f6a.gif"/>
<graphic xlink:href="sensors-09-10217f6b.gif"/></fig>
<fig id="f7-sensors-09-10217" position="float">
<label>Figure 7.</label>
<caption>
<p>Example of sonar readings <italic>S<sub>new</sub></italic>, in red, and <italic>S<sub>old</sub></italic>, in black. The ellipses depict the 99% confidence interval of the associated Normal distributions.</p></caption>
<graphic xlink:href="sensors-09-10217f7.gif"/></fig>
<fig id="f8-sensors-09-10217" position="float">
<label>Figure 8.</label>
<caption>
<p>Some of the data sets using in the experiments. The left column shows the sonar readings according to the initial odometric estimates. The right column shows the sonar readings according to the ground truth trajectory.</p></caption>
<graphic xlink:href="sensors-09-10217f8.gif"/></fig>
<fig id="f9-sensors-09-10217" position="float">
<label>Figure 9.</label>
<caption>
<p>(Top) Fragment of a real trajectory. (Bottom) Polyline approximation. The dots represent the vertexes.</p></caption>
<graphic xlink:href="sensors-09-10217f9a.gif"/>
<graphic xlink:href="sensors-09-10217f9b.gif"/></fig>
<fig id="f10-sensors-09-10217" position="float">
<label>Figure 10.</label>
<caption>
<p>(a) Means and standard deviations of the trajectory errors. The experimental results have been obtained using different numbers of particles and setting the history size <italic>k</italic> to 100. (b) Means and standard deviations of the execution time per data set item on a Matlab implementation. The experimental results have been obtained using different numbers of particles and setting the history size <italic>k</italic> to 100.</p></caption>
<graphic xlink:href="sensors-09-10217f10a.gif"/>
<graphic xlink:href="sensors-09-10217f10b.gif"/></fig>
<fig id="f11-sensors-09-10217" position="float">
<label>Figure 11.</label>
<caption>
<p>(a) Means and standard deviations of the trajectory errors. The experimental results have been obtained using different local map sizes and setting the number of particles <italic>M</italic> to 100. (b) Means and standard deviations of the execution time per data set item on a Matlab implementation. The experimental results have been obtained using different local map sizes and setting the number of particles <italic>M</italic> to 100.</p></caption>
<graphic xlink:href="sensors-09-10217f11a.gif"/>
<graphic xlink:href="sensors-09-10217f11b.gif"/></fig>
<fig id="f12-sensors-09-10217" position="float">
<label>Figure 12.</label>
<caption>
<p>Sonar readings plotted according to the particle filter trajectories. The left column corresponds to icpMCL using 100 particles. The right column corresponds to spMCL using only 10 particles. The local map sizes are <italic>k</italic> = 100 in all cases.</p></caption>
<graphic xlink:href="sensors-09-10217f12.gif"/></fig>
<fig id="f13-sensors-09-10217" position="float">
<label>Figure 13.</label>
<caption>
<p>Sonar readings plotted according to the particle filter trajectories. The left column corresponds to icpMCL. The right column corresponds to spMCL. The local map sizes are <italic>k</italic> = 100 and the number of particles is <italic>M</italic> = 400 in all cases.</p></caption>
<graphic xlink:href="sensors-09-10217f13.gif"/></fig></sec></back></article>
