Dead reckoning (DR), also known as Deduced Reckoning, is the process of measuring the position of a moving body based on its relative position or velocity to its previous state (Hofmann-Wellenhof et al., 2003). The concept of DR is simple and it is commonly applied in different areas of navigation, such as vehicle navigation, robotic tracking, aircraft navigation as well as pedestrian navigation (Fry and Wells, 1954; Azenha and Carvalho, 2008; Duan et al., 2014; Bao and Wong, 2014). Pedestrian dead reckoning (PDR) algorithms are DR applied to navigating or tracking a pedestrian based on the measurements that are obtained from walking patterns. PDR typically consist of three steps: step detection, step length estimation and position update. PDR requires the relative distance and direction measurement between two consecutive steps which is usually obtained by low-cost inertial sensors or even just accelerometers (Godha and Lachapelle, 2008; Kim et al., 2014). The analysis of acceleration measurements is also known as gait cycle detection, common step detection methods are autocorrelation, peak detection and zero crossings where all of them rely on identifying the frequency pattern of a typical step (Kim et al., 2004; Weimann et al., 2007; Zampella et al., 2011; Altun and Barshan, 2012).
3.2. Pedestrian dead reckoning
low-cost foot-tracker to measure inertial measurements by fixing the unit on the user’s foot during walking (Abdulrahim et al., 2012). Inertial data can be logged by any mobile device which is able to connect to the unit through Bluetooth or USB connector. A Raspberry Pi single-board computer is used here which provides a more portable solution for obtaining inertial measurements from IMUs. Figure 3.1 plots the total acceleration of the foot movement measured by the foot-tracker during a normal walk. A random noise can be observed at the beginning when the sensor is just turned on. To stabilise the sensor, an initialisation phase is carried out each time the sensor is turned on and before the actual data collection. Any still body on the Earth will experience the g-force, which is approximately 9.8m/s2, thus the detected step acceleration starts off just above −10m/s2.
The acceleration of the walking phase consists of cycles of very similar patterns with few minor jumps where each cycle represents a step.
Figure 3.1: ZUPT step detection
In INS navigation, ZUPT correction is applied to minimise sensor errors. During ZUPT, a step detection has to be carried out to find the moment when the velocity of the foot should be vf oot = 0m/s. Step detection is
also the first major requirement for PDR navigation. In the ZUPT applied here, steps are detected by comparing and correlating the foot acceleration measurements with a model of a single step acceleration model which is modelled prior to the navigation phase. Any cycle that matches with the step model is detected as a step, as indicated by magenta circles in Figure 3.1. However, human behaviours are not always predictable, and neither is the environment that we walk in. Any unexpected turning, foot swaying, slipping or jumping will cause anomalies in the acceleration pattern which could cause step detection errors. Figure 3.2a gives an example of under- detection during the walking phase, when the foot movement may have
suddenly reduced. Figure 3.2b is an example of over-detection when the foot may have swayed in the air while no step was taken. While small anomalies in the step acceleration pattern are hard to model, we can only detect steps that follow typical patterns. The number of mis-detections should be minimised to achieve better IMU based positioning. However, it is hard to completely eliminate such errors. To produce better positioning results, corrections should be applied based on the situation.
(a) Under-detection
(b) Over-detection
Figure 3.2: Mis-detection of steps during ZUPT
The estimation of the actual step length is a more difficult task as it is highly dependent on different height and weight of the person wearing the foot-tracker as well as the actual step pace and the terrain. Even if the details of the environment are fully available, it will still be hard to correctly estimate the exact step length. To simplify the process, a constant step length model which assumes the step length is a constant value with a zero mean Gaussian noise is usually applied (Ladetto, 2000; Kim et al., 2004; Khan, 2011; Zampella et al., 2011; Nishiguchi et al., 2012; Valentin
3.3. Map matching
and Mahesh, 2013). When a step is detected, the estimated step length with a directional measurement is fed into the DR model in Eq.3.1 to update the pedestrian position.
" ˆ xk ˆ yk # = " ˆ xk−1+ ˆsk|k−1cos ˆθk|k−1 ˆ yk−1+ ˆsk|k−1sin ˆθk|k−1 # (3.1)
where [ˆxk, ˆyk] is the estimated position at time step k, ˆsk|k−1is the estimated
length of the step taken from time k −1 to k, ˆθk|k−1is the measured heading
from time k − 1 to k. The procedure of the application of the DR model during a step is as shown in Figure 3.3.
Figure 3.3: Dead reckoning during a step
3.3
Map matching
As maps are widely available in urban areas, they are commonly im- plemented in the navigation filter through map matching. Maps provide the details of roads, junctions, construction sites and natural landscape, etc. Map matching integrates this information into the positioning sys- tem to aid navigation performance as the moving user is only allowed to travel according to certain rules according to the map (Morisue and Ikeda, 1989; Quddus et al., 2007; Bao and Wong, 2013). It was introduced in
military aviation for terrain contour matching and later widely applied in road based transport navigation. Map matching minimises and constrains positioning errors by eliminating estimations that fall outside the road boundary or any other features that allow the vehicles to travel on.
In pedestrian navigation, map matching is applied based on the general rule that humans must walk on the ground and the only possible way to get from one side of the wall to the other is by going through doors. This means that if the navigation estimation of a pedestrian is crossing walls or jumping through floors then something must be wrong. When map
information is known beforehand and ready to be integrated in positioning systems, it provides a good constraint on pedestrian navigation by prevent- ing estimations going to the wrong places (White et al., 2000). Indoor maps can be expressed by many different methods, such as schematic maps, CAD maps or polygons. Polygons are the most straightforward representa- tion of rooms and corridors while directions could be easily extracted as well.
The map information applied throughout this thesis is based on poly- gons that are stored in a matrix format. The rooms are represented by polygons which describe the coordinates of each corner of the room and the doorways in the sides of the polygon. Doors are represented by the coordinates of the middle point of the door. In the matrix, the ID of the wall that it sits in and the rooms that are on either side of the door are given. An example of the polygon matrix is shown below.
Table 3.1: Example of a map matrix
(a) Room polygon-wall relationship Polygon No. Wall position Door No.
1 x1 w1 y 1 w1 x1 w2 y 1 w2 .. . ... x1 wn y 1 wn 1 2 x2 w1 y 2 w1 x2 w2 y 2 w2 .. . ... x2 wn y 2 wn 2, 4 . . . ... ... m xm w1 ymw1 xm w2 ymw2 .. . ... xm wn ywnm k (b) Door-room relationship
Door No. Door position Linked Rooms
1 [x1, y1] [1, 11] 2 x2 y2 x4 y4 [2, 11] . . . ... ... k [xk, yk] m
This is a simple way to store the building map information and apply it to different platforms. This format can be stored as a kml file and used for visualisation in Google Map as well as Matlab. The user can easily find its position within the building matrix and extract useful information, such as