autonomous simultaneous localization and...
TRANSCRIPT
PROJECT IN MECHANICAL ENGINEERING or MECHATRONICS
Group Members: B. Eastwood (Convener)
M. McCauley
A. Carrell
J. Mills
Supervisor: A. Veale
Department of Mechanical Engineering
University of Auckland
05 June 2015
AUTONOMOUS SIMULTANEOUS LOCALIZATION
AND MAPPING ROBOT
Group 14
Project Report MT00-2015
ii
ABSTRACT
The project task is to design and build an autonomous SLAM robot with the
intent of completely covering an unknown environment as well as map this
environment. An omnidirectional robot powered by an Arduino processor as well
as a number of displacement sensors and actuators have been provided for the
purpose of completing this task.
A very good background of the SLAM concept was developed throughout the
course of this project as the goal was to implement a full working model. Two
separate functional models were developed for common SLAM algorithms, wall
detection and obstacle identification. It was eventually discovered that due to the
limitations in the processor capability, sensor performance and inaccuracies, as
well as time constraints, integration of these algorithms into a single system was
not feasible. Thus a model that was more suited given these limitations was
produced.
A full odometry model was developed to provide motion control of the robot
through linear and rotational speed commands. This was utilised to implement a
positional controller, where the desired position could be entered. The
combination of speeds inputs and position targets was used to direct the robot on
a prior planned path to cover as much of the board as possible.
Higher levels of control were added to specify the robot’s performance in certain
states, including finding a corner at the beginning of the run, and orientation to a
wall when one was encountered. A low level of obstacle avoidance was tested and
implemented however, again due to tie constraints it was not present in the final
system.
Overall, separate functionality for various different possible robot situations were
developed, and acceptably accurate motion control was achieved, but planning
did not account for the time it would take to integrate these separate subsystems.
Thus the performance of the final system was far less than the potential of the
combined subsystems.
iii
Table of Contents
Table of Figures .................................................................................................................................... iv
Table of Tables ..................................................................................................................................... iv
Glossary of Terms ................................................................................................................................. v
Abbreviations ......................................................................................................................................... v
1 Introduction .................................................................................................................................. 1
2 Project Description and Specifications ....................................................................................... 1
2.1 Literature Review ......................................................................................................................................... 1
3 SLAM ............................................................................................................................................ 2
3.1 Introduction to SLAM .................................................................................................................................. 2 3.2 SLAM Summary ........................................................................................................................................... 2 3.3 SLAM Models .............................................................................................................................................. 3 3.4 SLAM Concepts ........................................................................................................................................... 4 3.5 Intended SLAM ............................................................................................................................................ 5
4 System Design and Integration .................................................................................................... 6
4.1 Initial System ................................................................................................................................................ 6 4.2 Additional Hardware .................................................................................................................................... 6
4.2.1 Ultrasonic Range Finder ...................................................................................................................... 6 4.2.2 Servo ..................................................................................................................................................... 7 4.2.3 IR Sensors ............................................................................................................................................. 7 4.2.4 MPU ...................................................................................................................................................... 9
4.3 Final System ............................................................................................................................................... 10
5 Software design and implemented algorithms ......................................................................... 11
5.1 Mecanum Motor Modelling & Odometry ................................................................................................... 11 5.1.1 Base Level Motor Control ................................................................................................................... 11 5.1.2 RPM Conversion to PPM .................................................................................................................... 11 5.1.3 Linear Speed Conversion to RPM ....................................................................................................... 12 5.1.4 Heading Control ................................................................................................................................. 13 5.1.5 Drift Rejection ..................................................................................................................................... 14 5.1.6 Speed Correction Factor ..................................................................................................................... 14 5.1.7 Coercion into Range for Odometry ..................................................................................................... 14 5.1.8 Odometry Calculations ....................................................................................................................... 15 5.1.9 Position Controller ............................................................................................................................. 16 5.1.10 Accuracy limitations ......................................................................................................................... 16
5.2 Landmark Extraction .................................................................................................................................. 16 5.2.1 Spike .................................................................................................................................................... 17 5.2.2 RANSAC .............................................................................................................................................. 17
5.3 Landmark Association ................................................................................................................................ 18 5.4 Mapping ...................................................................................................................................................... 19 5.5 Path Planning .............................................................................................................................................. 20
5.5.1 Finding the Initial Corner ................................................................................................................... 20 5.5.2 Map Covering ..................................................................................................................................... 21 5.5.3 Obstacle Avoidance Algorithm ........................................................................................................... 22
5.6 Arduino Program Structure ......................................................................................................................... 22 5.6.1 General Structure................................................................................................................................ 22 5.6.2 Robot Motion ...................................................................................................................................... 23 5.6.3 Main Robot Motion Functions ............................................................................................................ 23
6 Testing & Results ........................................................................................................................ 25
6.1 Heading Control ......................................................................................................................................... 25 6.1.1 Method ................................................................................................................................................ 25 6.1.2 Results ................................................................................................................................................. 25
6.2 Linear Speed Testing .................................................................................................................................. 26
iv
6.3 Positional Controller Testing ...................................................................................................................... 27 6.4 Spike Testing .............................................................................................................................................. 27 6.5 RANSAC Testing ....................................................................................................................................... 28
7 Discussion .................................................................................................................................... 30
7 Recommendations ....................................................................................................................... 31
7.1 Algorithm Development ............................................................................................................................. 31 7.2 Sensor Improvements ................................................................................................................................. 31 7.3 Proposed Odometry Improvements ............................................................................................................ 32
8 Conclusions ................................................................................................................................. 33
9 References ......................................................................................................................................... 34
Table of Figures
Figure 1: PuTTY Output for Matrix Calculations ................................................................................................... 5
Figure 2: Mecanum Wheel Schematic ..................................................................................................................... 6
Figure 3: Possible Ultrasonic Range Patterning ...................................................................................................... 7
Figure 4: Medium IR Sensor Characteristic ............................................................................................................ 8
Figure 5: Final Robot Configuration ..................................................................................................................... 10
Figure 6: Relationship Between PPM Sent to Motors and Output RPM ............................................................... 11
Figure 7: Right Rear Motor Forward RPM to PPM Model ................................................................................... 12
Figure 8: Mecanum Inverse Kinematics ................................................................................................................ 12
Figure 9: Right Rear Inverse Kinematics Calculation ........................................................................................... 13
Figure 10: LabView Ground Station Front Panel .................................................................................................. 19
Figure 11: Robot Locating a Corner and Traversing First Wall ............................................................................ 21
Figure 12: General Traversing and Strafing Plan .................................................................................................. 21
Figure 13: Obstacle Avoidance Planning with Return to General Motion ............................................................ 22
Figure 14: Robot Scanning then Aligning to a Wall ............................................................................................. 24
Figure 15: Initial Position for Heading Control Test ............................................................................................. 25
Figure 16: Heading Error for ‘X’ Motion .............................................................................................................. 26
Figure 17: Speed Correction Factors ..................................................................................................................... 26
Figure 18: RANSAC Test Data Output ................................................................................................................. 28
Figure 19: IR Sensor Corner Inaccuracies Visualisation ....................................................................................... 29
Table of Tables
Table 1: IR Range Error Testing ............................................................................................................................. 9
Table 2: Heading Error with & without a Controller............................................................................................. 25
Table 3: Positional Controller Errors ..................................................................................................................... 27
v
Glossary of Terms
Yaw Rotation about the axis perpendicular to its plane of motion.
Drift Unwanted motion perpendicular to the desired direction.
Omnidirectional Allowing movement in all directions.
Abbreviations
SLAM Simultaneous Localization And Mapping
PPM Pulse Position Modulation
MPU Motion Processing Unit
PID Proportional Integral Derivative
IR Infra-Red
EMI Electro Magnetic Interference
I2C Inter-Integrated Circuit
EKF Extended Kalman Filter
IMU Inertial Measurement Unit
IDE Integrated Development Environment
vi
1
1 Introduction
For complete autonomy, a robot needs to be able to navigate while simultaneously localizing
itself within an unknown environment. This has been one of the significant road blocks for
autonomous systems and is still a major area of research to date. This process, known as
SLAM, is the concept of simultaneously locating a robot within an unknown environment,
and mapping that environment. It can be adapted in many different ways depending on the
situation. This is the concept that will be used to complete the project task given.
The aim of the project is to design and build an Autonomous SLAM robot for “room vacuum
cleaning”. The robot is to cover a set area while avoiding obstacles in the shortest time
possible. The less defined, and open-endedness of this problem leaves a vast number of ways
in which the task can be completed. Both systems thinking and integration will become key
factors during the course of the project.
An omnidirectional robot, powered by an Arduino Mega 2560 has been provided, for the
purpose of completing the task. Multiple paths were attempted throughout the progression of
the project. This report discusses the approach taken to complete the assigned task including
concepts which were unnecessary or un-useable. The report covers the implemented
algorithms, receiving sensor data, and sending the robot appropriate commands.
2 Project Description and Specifications
The Autonomous SLAM Robot design project draws on knowledge from a wide variety of
subjects including mechanical, electrical, electronic engineering, and computer technology.
An in depth understanding of motion actuation, sensing, signal processing, programming, and
microcontrollers is needed in order to complete the required task.
The main project task include designing an autonomous SLAM robot, capable of deciding its
own path of movement, while building a map of the surroundings. A number of cylindrical
objects are to be placed randomly about the 1200 x 2000 mm board. Collision with any of
these objects or the walls, is not permitted. The robot must record the map of the path
travelled in order to show complete coverage of the board. Assessment will be based on area
covered, and the time taken to complete this.
A mobile, agile, and highly manoeuvrable robot chassis has been provided. The chassis has
suitable space for all the necessary components needed. Sensors, motors, control circuits and
interfaces have also been provided. Thus, to complete the project task, the microcontroller
needs to be programmed to read sensor data and apply appropriate motor signals to affect the
robot’s behaviour accordingly.
2.1 Literature Review
It has become generally acknowledged that a truly autonomous robot must be able to
navigate, travel and arrive at a location, independent of external commands [1]. When
extended to an unknown environment, this requires both mapping, and localisation, within
that map. If this is performed simultaneously, it is called SLAM [2, 3, and 4]. SLAM
however is not a simple task as it requires a very accurate knowledge of sensor
characteristics, and sensor errors that are introduced in different conditions [5]. Furthermore,
the use of an extended Kalman filter (EKF), requires large matrix operations that can be very
computationally expensive.
2
Beevers and Huang [2] utilise low cost IR sensors and a microcontroller to implement SLAM,
recognising the inaccuracy of such sensors, especially their inability to completely identify
map features in one scan. They, along with Abrate et al. [3], utilise the idea of a ‘multiscan’,
which combines data from several scans on the same map area to improve sensor
performance. Brunner et al. [5] have characterised general IR sensor characteristics, and
present conditions where IR sensors work far better than vision systems or ultrasonic range
finders. Furthermore, they conclude that if appropriate sensor fusion or data manipulation is
performed, adequate readings can be taken from most sensors in a wide variety of conditions.
Huang and Song [1] use simplified SLAM algorithms and increase the reliance on previous
environment scans to reduce the complexity of EKF calculations. Essentially, by restricting
the scan range and only scanning new areas, the amount of data that must be processed by the
EKF is reduced, also reducing computational requirements. Beevers and Huang [2] also
simplify the EKF calculations by exploiting symmetry of covariance matrices, values that are
multiplied by zero and using lookup tables to avoid full matrix multiplication. This drastically
reduces computational load, and allows SLAM to be executed even on a microcontroller.
Finally, Wang et al. [4] have developed a linearisation technique to manipulate motion
models in preparation for use with an EKF. These papers [1, 2, and 4] prove that SLAM, even
with an EKF, can be performed with limited computational power. Manipulation and
simplification of SLAM algorithms and equations is required however, generally exploiting
characteristics of these equations that avoids simplistic calculations.
Sheu et al. [6] acknowledge the strict requirements of indoor navigation, and accordingly
have developed methods of speed and pose correction, to ensure actual motion matches
desired. Specifically, they have used a gyroscope to give heading readings, and calculated the
error with an initial heading to equate additional rotational movement of the robot
supplementary to primary linear motion.
3 SLAM
3.1 Introduction to SLAM
Localization is the process of a robot moving through a known environment, while using
knowledge of the environment, as well as on-board sensors to find its absolute position.
Mapping is the process where absolute position of the robot is known, and from on-board
sensors, the environment through which it is navigating is modelled. Both of these individual
problems are conceptually derivative. However, when a robot is placed in an unknown
environment, with no knowledge of its own position, both must be computed simultaneously,
thus making the task much more difficult. This problem is known as SLAM. The robot
attempts to move through an unknown environment, using imperfect motion, while also
trying to build a map of this environment, and locating itself within the map. It is currently
one of the biggest problems faced by completely autonomous systems. SLAM is made up of
multiple sub-problems, each of which being very difficult for engineers to solve.
3.2 SLAM Summary
SLAM is one of robotics largest problems, and consequently a large amount of research is
present for this particular field of interest. Because of the broad scope of SLAM, many
different solutions exist of various levels of robustness, difficulty, and computational
expense. There are many different parameters that must be taken into consideration, each of
which influence the required robustness of the implemented algorithm. For example, if
landmarks in the environment are incredibly sparse, then a more accurate motion model is
3
required. Conversely, if there are many different obstacles in the environment then accurate
sensors are required to not only distinguish them, but to help in associating landmarks to
others previously seen. All implementations of SLAM are based on a key architecture which
is described in the Section 3.3 SLAM Models.
3.3 SLAM Models
SLAM is the process of a robot moving through an unknown environment with uncertain
motion. When the process begins, the robot is either given its initial position, or no
information at all. In either case the robot builds its map relative to this initial position.
For a robot operating on a single flat plane, the locations can be described by a 3x1 vector.
This is the robots x and y positions as well as its rotation about the z-axis.
𝑥𝑡 = [𝑥𝑦𝜃
]
Over the course of SLAM the robot’s path for each discrete time step, 𝑡, can be described by:
𝑋𝑡 = {𝑥0, 𝑥1, 𝑥2, … , 𝑥𝑡}
The robot’s first location is known, but the rest are only correct to a certain degree. Full
SLAM involves evaluating the most likely robot path over the entire run, while online SLAM
is the simplification of this problem that only tries to estimate the current robot position.
In order to evaluate the robot path, most implementations use a probabilistic approach that
fuses data between odometry and sensor readings. The odometry of the robot uses a physical
motion model to estimate the current position of the robot within the map. This can either be
through wheel encoders, on-board motion sensors or assuming motion commands give
accurate odometry.
𝑢𝑡 is characterised by the motion between time 𝑡 − 1 and time 𝑡, which over the course of the
implementation is represented by:
𝑈𝑡 = {𝑢1, 𝑢2, 𝑢3, … , 𝑢𝑡}
For complete noise-free motion, 𝑈𝑡 would be enough to infer position, but for almost every
physical solution there exists some uncertainty between desired or measured motion and the
actual motion. Because of this, the robot also needs to sense the environment around it.
The map, denoted 𝑚, represents the true map of the environment such as landmarks, objects,
surfaces etc. This is regularly updated during each discrete time interval of the robot and is
typically assumed to be time invariant. This means the map often deals with passive rather
than active objects. Measurements of the surroundings give the relationship between 𝑚, and
the robot location 𝑥𝑡. 𝑍𝑡is used to describe observations of the map, and is the combination of
all prior observations:
𝑍𝑡 = {𝑧1, 𝑧2, 𝑧3, … , 𝑧𝑡}
A SLAM model can thus be considered a problem of evaluating a map, 𝑚, from the sequence
of robot locations 𝑋𝑡 using the data obtained from odometry and measurements.
As previously mentioned, SLAM can be broadly broken into two areas. One area which aims
to retrieve the robots full path from all previous readings, and another which only obtains the
current robot position. The first, full SLAM, obtains more accurate results. However this
method uses vast amounts of computational power which grows as the algorithm continues to
4
run. Often this method of SLAM is used in conjunction with a stationary groundstation, to
which previous data is sent to, and then does not require continual on board processing
resource. Full SLAM can be represented as shown:
𝑝(𝑋𝑡, 𝑚 | 𝑍𝑡 , 𝑈𝑡)
Online SLAM is the method of only calculating the current pose of the robot from the last
series of measurements and locations. This is a much simpler algorithm, and the computation
effort stays constant independent of how long the algorithm is run for. This is represented as:
𝑝(𝑥𝑡, 𝑚 | 𝑍𝑡 , 𝑈𝑡)
Algorithms for this are usually incremental and process one point at a time.
In order to solve SLAM, the robot needs at least two mathematical models. Firstly, a motion
model to relate the encoder values from the motors or voltages sent to those motors to
displacement. This mathematical model accounts for noise to give a probabilistic distribution
on where the robot is located. This function is denoted:
𝑝(𝑥𝑡 | 𝑥𝑡−1 , 𝑢𝑡)
The second model, relates the measurements to the environment and the robot location. This
function also uses probability theory and is shown below:
𝑝(𝑧𝑡 | 𝑥𝑡 , 𝑚)
In this problem, the exact robot location is unknown, there exists three main paradigms for
solving the SLAM problem. These are Extended Kalman Filter based, Particle Filter based or
Graph based.
3.4 SLAM Concepts
SLAM consists of multiple different facets. These facets include:
Landmark extraction - obtaining information on the points of interest of the robot’s
environment from raw sensor data.
Landmark association - recognized as one of the hardest problems in SLAM. This
problem attempts to associates already observed landmarks in the environment with
landmarks observed once the robots position has changed.
State estimation - attempting to accurately locate the robot given the motion and
orientation of the robot.
The final major subset of SLAM is how the associated error of the landmarks are updated
given how often they have been seen. Many of these different problems depend on the
environment and the sensor data, for the purposes of this discussion, an indoor 2D motion
robot is used.
The SLAM calculation process occurs at discrete time steps, and attempts to take in all of the
information from all different facets of the robot. A good SLAM algorithm can use all of this
information and evaluate exactly where the robot is within the environment. An EKF is
integrates the two models required for a SLAM algorithm. It takes in the statistical noise for
the sensor readings and state estimation and converts this into the most accurate estimate of
the robot’s position. The EKF also keeps track of the uncertainty in this estimate which grows
as the robot continues to move, and decreases as more landmarks are re-observed.
5
Unfortunately, an EKF requires a very large amount of computational effort. It involves many
large matrix multiplications which grow exponentially with the amount of landmarks in the
system.
The EKF involves many different matrices which are all used in different ways to update the
robot position. The first matrix, X, contains the information of the robot state, as well as the X
and Y positions of all of the observed landmarks. The size of this matrix is a one column
vector with 3 + 2𝑁 rows, where 𝑁 is the number of observed landmarks. The next of the
matrices for the EKF is the covariance matrix, 𝑃. This is a very important matrix in the
performance of the system. The covariance is a measure of the correlation between any two
variables and is used to measure the linear dependence between variables. For the purposes of
SLAM the covariance matrix contains the covariance between all elements, and therefore it
has 3 + 2𝑁 columns and 3 + 2𝑁 rows. The Kalman gain matrix , 𝐾, is computed every
discrete time interval to evaluate how much the newly observed landmark values are trusted.
This Kalman gain is calculated the Riccarti equation. The equation considers the levels of
noise present in both the range measurement models and the odometry models to give the
weighting for each value. This value is the perfect compromise between how much the state
estimation is trusted, and how much the landmark observations are trusted. For example, if
the sensor observations are very poor, and the state estimation is very accurate then the
Kalman gain is very low and vice versa. This matrix has two columns, and 3 + 2𝑁 rows,
where the first column represents the range gain and the second column the bearing gain. This
allows a differing amount of accuracy to be placed on either measurement. There are multiple
extra matrices used for the EKF process, and all are needed for this implementation.
For the purposes of the robot vacuum cleaner project, and the need to deal with three
obstacles as well as four corners, the maximum sized matrix calculation needed to be
performed is a 17 x 17 matrix multiplication. As the processing power available for this
project is relatively low, it was decided to assess the speed required to perform this
calculation, checking the feasibility, before continuing this approach.
Just one calculation of these 17 x 17 matrices takes 100ms. The time for calculation is shown
in Figure 1. Each 17 x 17 matrix of floats is 1156 bytes, the Arduino MEGA only has 8192
bytes of dynamic memory. So this one matrix alone takes up 14% of the maximum dynamic
memory for the processor. As this time is only a small portion of the maximum calculations
that the SLAM process needs to perform, as well as the limited dynamic storage of the
Arduino MEGA, it was decided to abandon the attempts for an EKF and focus on an
implementation of SLAM that is possible with the given hardware.
Figure 1: PuTTY Output for Matrix Calculations
3.5 Intended SLAM
The processing power, as well as the dynamic storage of the supplied processor was such that
the EKF implementation of SLAM would not be possible. A more simplified SLAM
algorithm needed to be designed which would not need complex matrix multiplications, but
would still provide an accurate knowledge of the robot’s position which would be updated
both through state estimation and landmark locations.
6
It was decided to use an algorithm which was based on the SLAM for Dummies algorithm
proposed by Riisgaard and Blas [7], but instead of an EKF, a weighted average would be used
between the state estimation values and the values obtained from the landmark association
algorithms. A Spike algorithm, discussed in Section 5.2.1 Spike, was intended to be used for
extracting landmarks from the raw sensor data. As well as Spike, the RANSAC algorithm
obtained from the same reference [7] was intended to be used to accurately map the
environment and approximate lines for the walls of this environment.
The intersection points of these walls as well as the extracted landmarks from spike were to
be filtered through a landmark association algorithm which takes the observed landmarks
over multiple iterations of the algorithms and only considers them true landmarks when they
have been seen multiple times. These values would be used to create an accurate map of the
system, and through this a simple path planning algorithm described in Section 5.5 was
intended to be used for moving through the environment.
The RANSAC algorithm will also be used to align the robot to the walls to correct gyroscope
drift.
4 System Design and Integration
4.1 Initial System
As described in Project Description and Specifications, the robot chassis has been provided.
The chassis includes:
4 VEX motors and motor drivers
4 Mecanum wheels
An Arduino Mega 2560
A Bluetooth module and computer dongle
2200 mAh LiPo
The Mecanum wheel, pictured in Figure 2, are the source
of the robots manoeuvrability. By orienting the wheels in
a specific way to the chassis, complete omni-directional
motion can be achieved. The robot can move in any
direction within the XY plane, as well as rotate about the
Z axis. The wheels are controlled by VEX motors which
in turn are controlled by their respective motor drivers
through a PPM signal. These motors are all powered by
the 2200mAh Lipo Battery.
An Arduino Mega 2560 is used as the main processing
unit for the system. The microcontroller is based on the ATmega2560, and is configurable
through the Arduino IDE. Wireless serial communication to the microcontroller is made
possible through the Bluetooth module, and Bluetooth dongle.
4.2 Additional Hardware
4.2.1 Ultrasonic Range Finder
The LV-MaxSonar-EZ0 is a high performance sonar range finder. The sensor takes an input
voltage of 2.5 - 5.5V and provides a very short to long-range detection. The sonar detects
Figure 2: Mecanum Wheel Schematic
7
objects from 6-inches to 254-inches with a 1-inch resolution at 20Hz. The sonar can output in
analog, pulse width, or serial.
The sonar has 4 types of use, each of which
change the beam pattern. The approximate
patterns are displayed in Figure 3.
From initial testing, the sonar readings were
found to be quite inaccurate. With the
manufacturers proposing 1-inch resolution the
power supply was thought to be the issue. Thus,
a low-pass filter was added to clean the sensors
input power and stabilize range data. The
manufacturer recommended a 100-ohm resistor
connected in series with the voltage line, and a
100-microfarad capacitor connected in parallel
between voltage and ground. This resulted in a
cut-off frequency of:
𝑓𝑐 =1
2𝜋𝑅𝐶=
1
2 × 𝜋 × 100 × 100 × 10−6= 15.92𝐻𝑧
The results of this low-pass filter seemed to aid the sensor to some degree but further
inaccuracies made it not very practical for use, including the lower end of its range being only
6 inches.
4.2.2 Servo
The provided actuator is a micro A0090 9g microservo. The servo motor can be set to move
any rotation angle within is specified range of 180o but testing proved the effective range to
be 167o. The servo motor does not have any form of feedback, but keeping the last position
sent to the motor in memory was a useful enough measure.
4.2.3 IR Sensors
Supplied Hardware
Three possible IR proximity sensors were made available for the project, designated short,
medium and long based on their respective relative ranges:
Short: 4-30 cm
Medium: 10-80cm
Long: 20-150cm
The sensors were sourced from Sharp, a manufacturer of optoelectric devices, along with
associated data sheets for each different type. The sensors draw (ideally) 5V and output and
analogue voltage which is generally less than 3.5V. The sensors are connected to the Arduino
Processor by three pins; ground, Vcc, and a third, which the output can be read from. Analog
Pins 13, 14 and 15 are used for the three sensors used.
Sensor Characterisation
Prior to full integration and use of the sensors for robot tasks, such as mapping or obstacle
avoidance, readings had to be generated and interpreted. Furthermore, the reliability and
Figure 3: Possible Ultrasonic Range Patterning
8
accuracy of readings had to be defined and assessed for their level of usability. Taking initial
readings presented the following issues:
The relationship between output voltage
and distance to object is not one-to-one.
This can be seen on Figure 4, as a reading
of 2V could be interpreted as 3.6 or 11.1
cm. This is the reason that the sensors
have a minimum range, anything
measured within that range appears to be
further than it actually is.
There is a nonlinear relationship even in
the usable range. This requires additional
curve fitting, using either a high order
polynomial or power model.
In order to remove the inaccuracies caused by the
obstacles within the lower range limit, the
different ranges of sensors were modelled and
compared to ascertain whether the use of two
sensors could provide a level of redundancy. This
would work by eliminating one reading if a
second sensor could identify when the first was
out of range. This line of development was scrapped as the modelling and testing was too
difficult, and the use of redundant sensors would be inefficient. The sensors were placed on
the robot so that objects could not come into the lower range, thus eliminating the source of
error.
Software Interpretation
Code was sourced from the ‘Arduino Playground’, an open source collection of repositories
for use with Arduino processors. The specific library used is called ‘Sharp IR Sensors library
for Arduino’ produced and copyrighted by Rd. Marcal Casa-Cartagena, in 2014. Whilst this
code performed relatively well, modifications and additions were made to improve the
accuracy of the readings.
The basic code structure was maintained throughout use of the library, and consists of one
‘SharpIR’ class, which has functions to read, interpret and average the readings from the pin,
designated at initialisation. This reading functions in two stages as follows:
Power Modelling
A power model is fitted to the readings of each sensor to determine the range in mm.
Medium: 𝐷𝑖𝑠𝑡𝑎𝑛𝑐𝑒 = 277.28 × (𝐴𝑛𝑎𝑙𝑜𝑔 𝑉
1000⁄ )−1.2045
Long: 𝐷𝑖𝑠𝑡𝑎𝑛𝑐𝑒 = 615.73 × (𝐴𝑛𝑎𝑙𝑜𝑔 𝑉
1000⁄ )−1.1068
Short: 𝐷𝑖𝑠𝑡𝑎𝑛𝑐𝑒 = 103.98 × (𝐴𝑛𝑎𝑙𝑜𝑔 𝑉
1000⁄ )−0.924
Figure 4: Medium IR Sensor Characteristic
9
The long and medium power models were supplied with the Sharp IR Sensors Library, and
appeared to provide adequate results. These power models also solved the aforementioned
issue of the nonlinear relationship between voltage and distance.
The short range IR sensor model was not covered in the library, thus had to be produced
through modelling. This was done using Excel and a power model to follow the implemented
system as closely as possible. Short sensors were not used in the final solution, due to their
ineffective range.
Multiple Sample Averaging
As the IR sensors tend to fluctuate for a single reading, the sourced code contains averaging
functionality, taking a number of readings and ensuring that they agree to within a certain
percentage. Values for number of readings and percentage tolerance are specified at
initialisation, 50 and 95% are used in the project respectively.
IR Testing & Calibration
The sensors were tested, statically, on a material similar to that of the final ‘room’. This was
achieved by placing the sensors a known distance from an object, taking three readings and
averaging them. The results are presented in Table 1, with all distances in cm. The sensors are
relatively accurate, displaying error ≥5cm for most values. The long range sensors are more
accurate, especially in the 20-55cm range. The inaccuracy at low range can readily be seen
here, as 10cm reads as 22 from the long range sensor.
Table 1: IR Range Error Testing
Actual: 5 10 15 20 25 30 35 40 45 50 55 60 65 70
Long Range: - 22 20 22 25 29 34 40 46 51 57 64 70 75
Short Range: 5 8 13 17 22 27 32 37 43 48 - - - -
Using the process described above to convert the outputted voltage to range, still gave invalid
readings. From further inspection it was found that these values still held a relative constant
value, but offset. Thus a function was developed to convert the output reading to the correct
value. The function varied between sensors and therefore had to be developed individually.
Output readings were mapped to the actual measured values and a trendine was fit using
excel. A linear trendline was sufficient with an R2 value of at least 0.99, this function was
then implemented in Arduino code, returning the corrected values back.
3D printed tunnels were initially used to increase the accuracy of the IR readings. This was
found to prevent random obscure readings from happening, but also introduced other
problems to the sensor. Measurements that were known to be flat, i.e. walls, appeared curved
when mapped on to an XY graph. The reason for this error is still unknown.
4.2.4 MPU
MPUs are rapidly becoming an essential hardware component in the majority of ‘smart’
devices, as users find added value in the ability to measure acceleration, tilt, angular velocity,
and orientation. The applications of these readings are nearly unlimited, but all relate to
assessing the pose or change in pose of the system in which it is attached. The functional unit
of an MPU is an IMU, which typically combines an accelerometer, gyroscope and
magnetometer for linear and rotational measurements. In this case, the IMU is part of a larger
10
integrated circuit, which reads the sensors, processes the signal, and stores data until it is read
by the main processor. The MPU consists of the IMU, integrated circuit and peripheral
communication system.
The MPU provided is the MPU-9150 manufactured by InvenSense. The MPU-9150 has a 3
axis accelerometer, gyroscope and magnetometer, as well as a temperature sensor. The
magnetometer can be used to supplement gyroscope readings for orientation, and provide
absolute heading information relative to Earth’s magnetic field. Communication with off-
board processors is achieved through I2C protocol.
The SLAM robot is limited to motion in the horizontal plane, assuming the test surface is flat,
the only readings that are relevant to the project are; X and Y accelerations, Z rotational
velocity and orientation. In the final solution only orientation is used, for heading control and
realignment at the start of the program.
Libraries for reading the data from the MPU were provided. The libraries use a read function
to initialise I2C communication and receive data sent from the MPU registers Readings from
the MPU have been utilised in the directional control functions.
4.3 Final System
The final setup of the robot is
relatively simple, with only three
displacement sensors beings used.
The three chosen sensors are
medium-range IR sensors. These
were used in conjunction with the
servo to provide a 360o field of view
to the robot. As displayed Figure 5,
the IR sensors have been connected
to the servo through a 3D printed
mount. The sensors have been set up
with 120o displacement between
them, thus with one 120o sweep the
full 360o field of view can be
covered. The decision to go with
three sensors was chosen since the
servo motor didn’t have a complete 180o range, as two sensors could have easily been used to
give the same outcome, if the range was larger. The servo is incremented after the IR has
completed one full reading, this is then repeated 120 times. As the project task progressed,
more accurate readings were needed, therefore the IR sensors were set to average 50 values.
This made the full 120o sweep relatively long, in turn showing that the choice of three sensors
over two was the right option. This particular setup, with the 360o view, enabled the robot to
move in any direction, with sensor feedback in that direction. This allowed the robot
complete its planned path, without rotating. The IR mount has been screwed in to the servo to
prevent it from disconnecting during fast sweeps. Height of the servo was also taken in to
careful consideration. Initially it was placed too high, which was one of the main sources for
bad readings, as the offset angle relative to the horizontal plane caused the IR to read outside
of the board. Thus the servo was mounted as low as possible without receiving interference
from the robot itself.
This configuration for the IR sensors was chosen as it gave complete coverage around the
robot as well as a good set of data for the intended landmark extraction algorithms.
Figure 5: Final Robot Configuration
11
As shown in the right of Figure 5, the MPU has been placed towards the front on a raised
mount. The mount needed to be low enough to not obstruct the IR sensors, but high enough to
not to affected by the electromagnetic disturbances. This placement was chosen by trial and
error.
5 Software design and implemented algorithms
5.1 Mecanum Motor Modelling & Odometry
Mapping an environment, and by extension SLAM, requires an estimation of landmarks,
given the robot’s poses. Thus, increasing the accurate knowledge of the robot’s poses, will in
turn increase the accuracy of the map produced.
The Mecanum robot used in this project presents the following key difficulties in estimating
its pose:
Non-linear relationship between the PPM voltage values sent to the motor and the
RPM of the wheel.
Indeterminate slip, skidding and differing resistance forces, all stemming from the
design and structure of Mecanum wheels.
Different and indeterminate motor characteristics and discrepancies in the mechanical
design connecting the wheels to the motors.
The following models have been developed with the end goal of providing accurate and
reliable odometry across a range of velocities, in the process eliminating the difficulties
mentioned.
5.1.1 Base Level Motor Control
The motors are PPM, however on the software level this control is achieved through writing a
microsecond value to the motor either side of 1500, to make the motor turn forward or
backwards. Unfortunately input of a certain PPM gives an indeterminate wheel RPM, and
does not correspond to a linear speed either. Furthermore, input of the same PPM to each
motor doesn’t result in the wheels spinning at the same RPM. The first correction required is
a linearisation of output RPM from PPM sent to the motors.
5.1.2 RPM Conversion to PPM
The model relating PPM and RPM was formulated by sending PPM values between -350 and
350 in increments of 10, and measuring the RPM of each wheel, with a tachometer.
-150
-100
-50
0
50
100
150
-400 -200 0 200 400
Wh
eel R
PM
PPM Sent to Motors
Right Rear
Right Rear RR F RR R
Figure 6: Relationship between PPM Sent to Motors and Output RPM
12
The results for the right rear motor are shown in Figure 6.
The model shows three distinct regions, forward and reverse relationships as well as a
deadband region between. In this case PPM values between -60 and 60 resulted in no motion.
The forward and reverse relationships are clearly non-linear, and could be described by
power, exponential or polynomial models, however to minimise computational resource
requirements a polynomial was chosen.
As this relationship, albeit a piece-wise one, is one to one, it was a simple task to switch the
model to obtain PPM as a fourth order polynomial function of (desired) wheel RPM. This can
be shown in Figure 7 again modelling the right rear motor, however only showing the
forward relationship.
Whilst modelling was initially performed using Microsoft Excel, the accuracy of the ‘fitted’
line and the actual points did not align. This was identified when the models were applied to
the physical robot, and the resulting motion did not match the linear performance it should
have. The final models were produced in Matlab, due to its higher computational power, and
resulting improvement in accuracy. The models were then validated by the robot’s
performance, which displayed linear performance for a given RPM, with minimal disturbance
from the initial heading. At this stage linear speed of the actual robot was completely
unknown.
Implementing these models in software was relatively simple in its final form. Whilst several
iterations were produced, the final design is modular, with separate functions for each motor,
and an additional function to perform the polynomial calculations.
5.1.3 Linear Speed Conversion to RPM
To generate RPM from desired linear speeds,
Mecanum wheel inverse kinematics were used,
as shown in Figure 8.
Implementation of these equations in software
is relatively simple, especially as the motor
Figure 7: Right Rear Motor Forward RPM to PPM Model
Figure 8: Mecanum Inverse Kinematics
13
models had already been separated into individual function calls. Desired speeds, in mm/s, in
two directions (X, Y), and in rad/s (in the Z direction) are sent to each model, where they are
manipulated into a single RPM value. For example, the RPM for the right rear wheel (also
denoted wheel 4), is generated using the following equation:
�̇�𝑹𝑹 =(𝒗𝒙 + 𝒗𝒚 + (𝑳𝑬𝑵𝑮𝑻𝑯𝑺) × 𝝎)
𝑹𝒘×
𝟏𝟖𝟎
𝝅
The software implementation uses the equation shown in Figure 9:
In this case, ‘LENGTHS’, ‘RADIUS’ and ‘RAD2RPM’ are constants, defined as macros, and convert
between values of different units.
5.1.4 Heading Control
Whilst aggregation of the first two conversions gave approximately linear motion in all
direction, the robot still encountered yaw, and drift. These values were not large, but with
respect to the scale of the target ‘room’, the level was unacceptable, and accurate odometry
would be extremely time-consuming and difficult to implement, let alone test.
Compensation for yaw was solved using a digital controller. Initially, PD control was used,
and results were extremely positive. The gains were determined using a rough form of
Zeigler-Nichols Closed-Loop Method, with a priority of stability. As increasing amounts of
code were introduced into the system instabilities grew to the point where the gains calculated
made the system unstable, and caused the response be too rapid. This is likely due to the
reliance of digital controllers on previous error and output values. Thus if not updated at a
high enough frequency, delays, which became increasingly prevalent, can cause the controller
output to grow to unstable levels. The result of this was overshoot and oscillations. To
prevent this, the proportional gain was reduced and derivative removed, but it was not
possible to have a stable system that also had a high enough gain to correct error. The end
solution was to increase the proportional gain to 10, but limit controller output to 2rad/s. This
ensured a higher level of control for small errors, without overloading the system for large
ones.
The controller was designed using standard digital controller theory, and the following
algorithm is used to implement the software form of the controller. All heading values are
fused Euler pose readings from the MPU.
If the robot is stopped:
o Set all errors (digital controllers require current error, and errors from the two
previous cycles) and output speeds in each direction, to zero, and update the
desired heading.
If the robot is moving:
o Update the errors, with each error value moving back by one, and the current
error calculated from the current heading
o Ensure the current error is within –pi → pi, otherwise the robot may attempt to
complete a turn in the longer direction to restore heading
o Correct X and Y speeds using the current error, in terms of world coordinates.
This ensures the robot continues at the desired heading, rather than in a
direction relative to its orientation
Figure 9: Right Rear Inverse Kinematics Calculation
14
o Update rotational speed with digital controller, using heading errors and
previous speed value
o Update previous speed value
The initial iteration of the controller used the magnetomer on the MPU in the fused Euler
angle reading, but this made the reading fluctuate heavily. Additionally the reading varied
heavily based on interference from wiring, electrical devices, and ferrite based objects.
Eventually, the magnetomer was discarded from the fused Euler pose giving fairly good
results, specifically a deviation error of 10mm over 50mm. This was deemed acceptable
especially given the precision of testing and the error that it would have produced.
5.1.5 Drift Rejection
The heading controller reduced yaw disturbances, but could not account for drift. The likely
cause is overpowered motors on one side of the robot. To compensate this, forward and
reverse values were ‘trimmed’, either increasing or decreasing the RPM value entered into the
motor models. This method of altering the relative rotation of specific motors kept the
solution adaptable, without major testing or redesign. An extra level of trimming was added
for motion in the Y direction, adding a significant proportion of X motion, to prevent drift.
The trim values are equated in software just before the RPM values are converted to PPM,
and are declared as macros, so that they can be easily altered without finding each and every
instance.
5.1.6 Speed Correction Factor
Even after adding the preceding models, converting linear speed to RPM, then PPM, heading
control to remove yaw, and trimming the RPM values to account for drift, the input speed
was found to be far slower than the actual speed of the robot. This could be due to the motor
models representing a relationship, but not exact values, or due to the additional control
effort, however a correction factor accounts for the discrepancy regardless.
Through testing and comparing the input speed to the actual linear speed of the robot models
were formed to correct the difference. The test method and results are discussed in Section
6.2 Linear Speed Testing, after which the following equations were able to be produced.
Forward:
o 𝑋 𝑆𝑝𝑒𝑒𝑑 = 0.511 × (𝐷𝑒𝑠𝑖𝑟𝑒𝑑 𝑆𝑝𝑒𝑒𝑑) + 18.073
o 𝑌 𝑆𝑝𝑒𝑒𝑑 = 0.528 × (𝐷𝑒𝑠𝑖𝑟𝑒𝑑 𝑆𝑝𝑒𝑒𝑑) + 38.282
Reverse:
o 𝑋 𝑆𝑝𝑒𝑒𝑑 = 0.489 × (𝐷𝑒𝑠𝑖𝑟𝑒𝑑 𝑆𝑝𝑒𝑒𝑑) − 18.959
o 𝑌 𝑆𝑝𝑒𝑒𝑑 = 0.517 × (𝐷𝑒𝑠𝑖𝑟𝑒𝑑 𝑆𝑝𝑒𝑒𝑑) − 39.956
These relationships are linear, proving that the linearisation steps and inverse kinematics are
correct, but suggesting that there is at least one last motor characteristic, which is not
modelled.
5.1.7 Coercion into Range for Odometry
Finally, in order to use the input speeds for accurate odometry, the speeds are coerced into a
range that is:
High enough that the robot actually moves – speeds below ~50mm/s do not result in
the robot moving – but would be registered by the odometry.
15
Not too high that the motors are over saturated, and do not turn any faster for
increases in speed – again this would result in the Odometry estimating the robot is
moving faster than it actually is, giving inaccuracies at high speeds.
The solution is to set speeds lower than 50mm/s to zero and if the total speed is greater than
300 (thus presenting a chance to over saturate on of the motors), the speeds are scaled back.
This scaling factor is the same ratio for each direction, thus ensuring the total vector is in the
same direction
5.1.8 Odometry Calculations
Odometry was achieved by integrating an acceleration and speed values in each direction.
Due to the computational resource available, and in general speed inputs are constant or step
functions, integration was limited to the following approximations:
𝑣 = 𝑎 × ∆𝑡
𝑠 = 𝑣 × ∆𝑡
Fusion of MPU and Robot Commands
The first odometry model attempted to use acceleration readings from the MPU (integrated
twice) to generate changes in X and Y position. The algorithm was as follows:
Read acceleration from MPU
Integrate over time period since last reading to give velocity
Fuse MPU ‘speed’ with output speed
Integrate again to give ‘position’
Update position
It became immediately obvious that the value produced was completely unusable, because the
MPU did not give a constant reading, even when stationary. This resulted in a constantly
increasing absolute value of position. Furthermore the Accelerometer had these issues:
‘Drift’ / constant increase in reading
Vibrations when moving, particularly at low speed
Indeterminate Conversion from output to acceleration value
Calibration requirements and increased reliance on MPU
Requirement of integrating twice – increasing the error at each stage
Because of the magnitude of these combined issues, it was simpler to redesign and test a
different method, than attempt to eliminate MPU errors.
Pure Robot Commands
Thus the solution was to eliminate MPU readings altogether, and only integrate output
velocity, using the following algorithm (which was made more accurate by including a
trapezium approximation for velocity):
Update current velocity, and time information
Calculate average of current and previous velocity – trapezium approximation
Integrate average speed over time step (since last integration) using same integration
method, giving position
Update ‘previous’ values (speed and time) in preparation for next loop – set to current
This method gave accurate enough readings to not warrant further development.
16
Additionally, accuracy was increased by updating the odometry, once at the start of the loop,
then once again at the end, after all the speeds have been manipulated.
5.1.9 Position Controller
Once accurate odometry information was available, it became a simple task to produce a
position controller that would automatically direct the robot to a specific point. This is
extremely useful for path planning, as it simplifies the requirements of such an algorithm, all
it then needs to generate is a set of points.
The obvious controller to use is a digital one, repeating the form used for heading control.
Unfortunately, this type of controller did not translate to position control with the same
accuracy. This was because of the variable speed outputs of the controller, which were not
necessarily in the ideal range for odometry, thus decreasing the accuracy of the odometry
model and producing sub-par results.
Alternatively, it was noted that the robot could move responding to step functions of speed
for periods of time, and maintain odometry accuracy. Thus a simple ‘bang-bang’ or on/off
controller is used with a deadband of 3mm. Whilst this isn’t the most elegant solution, it is
computationally very efficient, accurate to an acceptable level, and with appropriate
tolerances for obstacle avoidance will integrate well with path planning.
5.1.10 Accuracy limitations
Whilst the entire system was designed to give complete omni-directional accuracy, testing
showed that fusing X and Y speed vectors:
Produces less accurate odometry
This inaccuracy makes achieving a working positional controller too difficult,
requiring increasing complexity to overcome the inaccuracy
Additionally, because of the trimming and correction factors for speed, the optimal speed
range (in terms of odometry accuracy) to use was roughly 150 – 220mm/s in all four
directions. The robot was tuned around these values to maintain accuracy whilst also moving
as fast as possible around the environment. Thus, movement was limited to X and Y
directions separately, with a preference to the X (FWD & REV) direction, as this was more
accurate than Y, and using speeds of 200mm/s where appropriate. The biggest issue was drift
(without change in heading) especially at low speeds, in all directions as the heading
controller does not account for this.
5.2 Landmark Extraction
Both landmark extraction algorithms work off a circular array built by the IR sensors and
servo. A full 360 field of view is given to the robot by this circular array as a global variable,
which is thus accessible by any of the necessary algorithms requiring it. The two main
landmark extraction algorithms are explained further below.
In order to build a good knowledge of the surroundings of the robot, it was essential to
convert the raw Infrared sensor readings produced by the rotating sensor into useable data for
the rest of the SLAM algorithm. One aspect of this is to sense where the main obstacles in the
surroundings are, and another aspect is to sense where the walls of the enclosure are.
To extract the location of the main obstacles an algorithm called spike was used, and to
extract the equation for the lines an algorithm called Random Sample Consensus, or
RANSAC, was used.
17
5.2.1 Spike
The spike landmark extraction algorithm is used for detecting outstanding objects from the
surroundings. By passing through IR sensor data and comparing differences in range, these
objects can be detected.
Spike proposes a simple landmark extraction algorithm but lacks robustness. The algorithm is
fully dependent on sensor readings and accuracy, as fluctuations in readings can easily be
mistaken as landmarks. Additional conditions have been added to the algorithm to increase
suitability and robustness given the limitations of the current sensors, but a plateau has been
hit where further additions will jeopardise valid landmarks from being detected.
The implemented algorithm is as follows:
Cycle through circular array
Check if the current and previous readings are valid
Take the difference of these two values
If the current value is smaller than the previous, i.e. an edge has been detected from its
surroundings, and is greater than the landmark detection range of 200mm
Cycle through the next 30 values searching for the other edge of the object
Reset values above 360 to the correct circular value
Check if the current value and the next value are valid readings
If the current is smaller than the next value, and is greater than the landmark detection
range - a landmark has been located
Set the bearing and range in memory for the located landmark
The range has been set using another simple algorithm. Initially, range was set by taking the
IR value from halfway between the two edge bearing readings. Due to the fluctuation of the
sensors, this value taken was often false. Thus the new implemented algorithm cycled through
the readings between both edges and took the most common values, within a set tolerance.
The range then became the average of these values.
Under the assumption that all incorrect landmarks are due to fluctuations in sensor readings,
which is valid given the project task, incorrect landmarks should not pose a problem as a
landmark is only considered fit for use if it has been observed more than a set amount of
times. It is very unlikely that a fluctuation will occur in the same relative place twice.
5.2.2 RANSAC
The RANSAC algorithm uses the data extracted from the three rotating IR sensors, and
converts it into lines of the form 𝑦 = 𝑚𝑥 + 𝑐. The algorithm initially works by having an
unsorted array of raw absolute position data representing one value for each separate degree
around the robot. Firstly, a random point from the 360 degrees is chosen, and a sample of 10
unique degrees surrounding it are chosen using the inbuilt Arduino random function. Once
the sample points are chosen, a line of best fit is fit between these points. The algorithm then
cycles through all points of the 360 degree array and gets the distance from these points to the
line fit through the sampled data.
If this distance is less than some specified-variable tolerance then these data points are added
into an array which is the consensus for this line of best fit. The amount of data points in the
consensus is then compared to a pre-defined limit, and if there are more of them than a
required number, this constitutes enough to represent a line. As these data points were chosen
about a line which most likely included random outlier values, a new line of best fit is created
only through the consensus points. All members of the consensus of the newly found line are
18
then indicated that they have been sorted. The data for the lines is stored in global arrays
which can be further accessed by other parts of the robot software.
The algorithm then repeats itself, but ensures than any values previously sorted into a line are
not chosen or selected for further iterations of the algorithm. This will be repeated until a
large portion of the points are sorted into a line, or if the algorithm has been performed too
many times.
In order to ensure correct operation of the algorithm, the same code was ported onto a C++
Visual Studio 2013 project for the purposes of real-time debugging and processing.
Artificially built rectangles were used for testing, and it was found that the line of best fit
algorithm would crash when trying to fit data to a perfect vertical line. Although this was
almost impossible in a real-world situation, measures were implement to remove the
possibility of the code crashing if this were the case.
The Arduino language is based on C++, and so very little changes were required in order for
the code to be operational. Once the code was performing as required, the code was returned
to the Arduino language and testing of the algorithm was performed on artificially-produced
IR sensor data before finally implementing using the raw data on the actual system.
The results from testing the RANSAC algorithm are discussed in Section 5.5.2 Map
Covering.
6.5 RANSAC Testing. Because of the results, the actual implementation of the algorithm
differed from that described above. The final implementation is described below.
The RANSAC algorithm was intended to be run after every motion of the robot, so that it
could be used for building an accurate map as well as ensuring the robot was aligned to the
walls. However it was found that under dynamic conditions, which are further discussed in
Section 6.5 RANSAC Testing, that the lines the robot found were not as accurate as the angle
obtained from the gyroscope. It was decided to use a modified version of RANSAC to align
to the walls which eliminated the effect of the random noise by telling the algorithm where
the wall was most likely to be. This was run every time the robot stopped near a wall in the
map coverage algorithm, which is discussed in Section 5.5 Path Planning.
The robot would perform a scan which spanned 30 degrees in the direction which it was
aligning to, and the case structure of its implementation was only performed when there was
definitely a wall located there. The 𝑦 = 𝑚𝑥 + 𝑐 line was obtained, and the inverse tangent
was performed on the gradient to obtain the necessary angle of bot rotation. This algorithm
performed very well in rotating the robot back to the perfect orientation.
5.3 Landmark Association
The landmark association algorithm aims to identify similarities between inputted landmark
data, thus recognizing the same landmark at different points in time. This enables landmarks
to be marked as more reliable if they have appeared in sensor data multiple times. This
functionality stops misinterpreted data or landmarks only visible within a certain range, from
affecting the robots behaviour. A landmark is only considered verified, and therefore taken in
to account for path planning, if it has been observed more than X amount of times.
The algorithm first checks the landmark data that has been previously collected and
determines which of the stored landmarks is closest to the new data inputs. It then checks if
the new landmark data is within a set margin of error, of the closest landmark. If so, then the
previously observed landmarks observation count is incremented, otherwise the landmark is
added as a new, separate, landmark to be compared with future data inputs.
19
5.4 Mapping
The given task requires the robot to record the map of the paths travelled, as well as the
surroundings. Storing all this data within the Arduino is not feasible due to the small memory
capacity, thus a real time logging application was written. The logging application works on
the basis of Online SLAM, where the current estimates and pose are computed on the robot,
and then sent to the ground station to be further interpreted. The chosen IDE was LabVIEW.
The logging application, directly connects to the robot through serial communication via the
Bluetooth modules. Both reading and writing is capable from the application. The front panel
of the application is displayed in Figure 10, below.
As shown in Figure 10, the application lets the user select the correct COM port. The byte
count, or the number of bytes read per scan is also selectable. Lengthy lines exceeding the
byte count would return random ASCII characters, thus this configurability was needed. A
read buffer is shown towards the top right, this works exactly like the buffers used in PUTTY
or even the Arduino serial communications application. Write communication has been made
available directly above this and as displayed the XY graph is placed below. The graphs
updates all relative data in real-time, including plot configurations. The current graph shows
the mapped path from one of the initial testing runs. The path is shown in red, and the
approximated walls in white. Initially the robot tries to locate a wall so it can align itself with
this wall. This is shown in the top left portion of the path. From there the robot moves back
and forth down the length of the map. This path planning algorithm is explained in more
detail in Section 5.5.
Data to be mapped is sent to the application via the serial communication. Line by line this
data is interpreted and placed on the map accordingly. Each line has a unique identifier which
Figure 10: LabView Ground Station Front Panel
20
determines the way this data is interpreted. In the case of the robot path, the identifier
“PATH” is written at the beginning of the line, as well as the x and y co-ordinates. These co-
ordinates are then appended to the path array and then is the placed on the real-time graph.
The other forms of identifiers accepted include walls, IR readings, and interpolated lines
outputted from RANSAC. The identifier setup within the program was made relatively simple
so that if extras could easily be added, saving time in the future.
An error dialog has been placed on the bottom left. This was added to provide the user with
any connection issues that may occur whilst running. Usually the user isn’t notified until run-
time is over.
5.5 Path Planning
The following section describes the algorithm implemented for completing full room
coverage, which has been proposed. As the program has been decomposed into many series
of very logical steps, the algorithm described below is presented in a series of bullet points
that describe what the robot does at each step.
The robot begins the SLAM problem by having a random position in an unknown map that is
known to be a rectangular shape. This is shown in the top left (‘1’) of Figure 11.
The first step of the algorithm is to find the first possible wall, and then traverse along this
until the first corner is reached.
5.5.1 Finding the Initial Corner
The robot moves forward until it detects an object in front of it which can either be an
obstacle or a wall
Checks if this object is an obstacle or a wall
o If it is a wall the robot rotates its body until it is perpendicular to this wall
o If it is an obstacle the robot begins a function which will take it around the
obstacle until it reaches a wall
Once the first wall is found, the robot orientates itself perpendicular to the wall
It then strafes right until there is a wall to the right of the robot
Once the robot has found the initial corner, it enters the next process which is the algorithm
used to cover all of the map possible. Finding the initial corner is depicted by ‘1’ and ‘2’ of
Figure 11.
21
Figure 11: Robot Locating a Corner and Traversing First Wall
5.5.2 Map Covering
The map coverage algorithm works by the robot moving forwards or backwards until it
encounters a wall, and then strafes left by the width of the robot before continuing in the other
direction. The general motion plan is described in Figure 12.
The robot moves in the x-direction until it encounters a wall
Once a wall is encountered, the robot strafes left by the width of the robot
The robot then continues in the opposite x-direction until it encounters the other wall
Whenever the robot discovers an object, it performs a check to see whether this is an
obstacle or a wall and acts accordingly.
Figure 12: General Traversing and Strafing Plan
22
5.5.3 Obstacle Avoidance Algorithm
This algorithm is only entered once the robot has encountered something either in front or
behind it, and checks if this is an obstacle or a wall.
The robot updates the current y-position as the master y-position which represents the
final y-position that the robot will have before the algorithm is exited
The robot then checks if there is an object to its left, and if there is not then it will
move by one width of the robot to the left.
Otherwise it will try move by the same amount to the right.
After strafing sideways, the robot then checks to see if it can move forward
o If it cannot, then it continues moving sideways and this step is then repeated
o If it can, then it moves forward by two times the length of the robot
Once the robot has moved forward, it then checks to see if it can return back to the
master y-position mentioned before
o If it can, then the robot strafes back until it is at the original y-position on the
state estimation
o If it can’t then it continues to move forward until it can strafe in the desired
direction
When the robot reaches the desired y-position, the algorithm is finished and the
original map coverage algorithm is continued
Figure 13: Obstacle Avoidance Planning with Return to General Motion
5.6 Arduino Program Structure
5.6.1 General Structure
The program code used for the implementation of the robot vacuum cleaner has been written
using the Arduino IDE. The language used in this environment is closely related to C++ with
a few small changes in order for it to be run on an embedded system. Every Arduino program
consists of a setup function which is run once on start-up and then a loop function which is
called continuously throughout normal operation. The robot vacuum cleaner program code
23
uses these two functions to build the core of the code, and it is within these two that all of the
custom function calls are made.
Many different software libraries have been obtained online, which have been included into
the Arduino libraries for use with the project. These libraries are used to interface with the
MPU, IR sensors, and servo motor. All libraries have been included at the beginning of the
program code at the top of the main Arduino file.
Most functions written for the purpose of implementing SLAM have been consolidated into
other files which are also included into the Arduino program at the beginning of compilation.
This has been done to reduce file size, speed up compilation, add modularity, and to make
debugging simpler. The included files are discussed below, the most important of them being
‘Variables.h’. This header file houses all global variables which are used throughout the
operation of the program. Although this can make it difficult to understand where each
variable has been altered, the sheer number of different values needed made this a necessity
and thus careful programming was performed in order to ensure variables are only changed
where necessary.
5.6.2 Robot Motion
The main two modes of motion for the robot are either moving straight in the forward and
backwards direction or strafing left and right. These modes of motion keep the robot
orientated in the same direction during operation, orientation is only changed initially during
the first mode of motion to align perpendicular to the wall. While the robot is moving, there is
active collision avoidance which is achieved through sweeping the IR sensors through the
direction in which it is moving.
5.6.3 Main Robot Motion Functions
RotateToWall()
The rotate to wall function scans a range of 30 degrees about the central direction of the wall.
A least squares regression line is then fit to these points, the relative offset angle to this wall
is then calculated by the inverse tangent of the gradient of this line. This basic concept is
shown in Figure 14 below:
24
Figure 14: Robot Scanning then Aligning to a Wall
ForwardMoveScan()
This function can perform motion in the robot x-position in either direction. A control
Boolean can be passed as an input thus allowing two different functionalities within the one
function. With this Boolean false, the robot will continue moving in the given direction until
the IR sensor detects an object. If the Boolean is true, the robot will attempt to move a
specified distance unless an object has been detected.
StrafeMoveScan()
Strafe move scan operates under the exact same principle as ForwardMoveScan, except the
motion is in the robot y-direction. These were split for debugging purposes under the
intention that the perfectly working system could them merged into one again.
CheckObstacle()
Check obstacle is called within either StrafeMoveScan or ForwardMoveScan when an object
has been detected. This function is used to check the characteristic of the object which has
been detected. It performs a scan from −25° to 25°, and calculates the objects parallel
distance away. The maximum and minimum are then obtained from this data set. From this
maxima and minima, the object can be characterised. If the two values are similar, it is most
likely a wall, If this object is an obstacle, the difference will be large. This function will also
return a flag if a false reading has been obtained.
MoveToCorner()
The move to corner function is the first to be called out of all the explained functions.
ForwardMoveScan is called until a wall has been encountered. The robot then uses the
RotateToWall function to align to this wall, upon completion, the robot calls StrafeMoveScan
until a wall to the right has also been encountered. The robot should now be located within
the top right corner. The robot now begins the map coverage algorithm.
25
6 Testing & Results
6.1 Heading Control
After the heading controller was implemented it was essential to test its effectiveness over the
range of a standard run, as these values could be used to assess the controller gain
performance.
6.1.1 Method
The robot was set at a desired heading, and
made to run at 180mm/s, as this value was
roughly in the middle of the range of
accurate speeds. At intervals of 10cm, the
position of the front left wheel was noted, on
the test platform. At the end of the run
(100cm), the positions of the front left wheel
relative to the original heading were
measured. The initial position is shown in
Figure 15, with every 100mm noted, so the
error at those positions can be recorded.
The raw absolute values are shown in Table
2, as well as the percentage of total X movement.
Table 2: Heading Error with & without a Controller
Dist. From Start (D) (mm) 0 100 200 300 400 500 600 700 800 900 1000
Error Controller (mm) 0 2 3 5 7 10 13 14 18 21 24
% of D 0% 2.00% 1.50% 1.67% 1.75% 2.00% 2.17% 2.00% 2.25% 2.33% 2.40%
No Controller (mm) 0 5 8 14 24 38 54 83 122 173 215
% of D 0% 5.00% 4.00% 4.67% 6.00% 7.60% 9.00% 11.86% 15.25% 19.22% 21.50%
6.1.2 Results
The controller provides a marked improvement, by keeping deviation to an average of 2.01%
of primary motion. This was acceptable, as even 2.4cm could be accounted for in tolerances
without major loss in coverage. Conversely without the controller the deviation was an
average of 10.41% over the tested range, but increases constantly. The results can be seen in
Figure 16, without a heading controller the error grows to an unusable >20cm. This would
have placed increased reliance on obstacle avoidance, and introduced a large uncertainty into
path planning.
Figure 15: Initial Position for Heading Control Test
26
6.2 Linear Speed Testing
Testing to compare the linear speed of the robot to the desired user speed was performed.
Input Speeds were tested between 50 and 200 for each of the four directions (FWD, REV,
LFT, RGT), giving actual robot speeds between 25 and 350mm/s. The relationship between
input speed in each direction and actual robot speed can be seen in Figure 17, including the
equations which model each relationship.
The results and associated models are used to correct for the difference in desired and realised
output speeds, as discussed in Section 5.1.6 Speed Correction Factor.
y = 0.5111x + 18.073R² = 0.9964
y = 0.4889x - 18.959R² = 0.9956
y = 0.5284x + 38.282R² = 0.9968
y = 0.5165x - 39.956R² = 0.9951 -250
-200
-150
-100
-50
0
50
100
150
200
-400 -300 -200 -100 0 100 200 300 400
Inp
ut
Spee
d
Robot Speed (mm/s)
Speed Correction Factor Models
FWD: REV: RIGHT: LEFT:
Linear (FWD:) Linear (REV:) Linear (RIGHT:) Linear (LEFT:)
Figure 17: Speed Correction Factors
0
50
100
150
200
250
0 200 400 600 800 1000 1200
Hea
din
g Er
ror
(mm
)
X Position Relative to Start (mm)
Heading Error for 'X' Motion
Error: w. Controller Error: w/out Controller
Figure 16: Heading Error for ‘X’ Motion
27
6.3 Positional Controller Testing
The position controller was tested by sending the robot to four different locations, and then
returning it to home. At each location, actual distance from the origin in each axis was
measured. The error was then computed, presented in Table 3.
Table 3: Positional Controller Errors
Desired Position Assumed Position Actual Position Error
(mm from start) (mm from start) (mm from start) (difference in mm)
X Y X Y X Y X Y
0 0 0 0 0 0 0 0
350 350 349.25 350.8 310 335 40 15
1500 350 1499.5 350.8 1370 270 130 80
1000 -80 1000.6 -80.6 940 -80 60 0
-100 -150 -99.8 -150.4 -105 -165 5 15
0 0 0.94 0.78 10 -10 -10 10
Whilst the position controller shows appreciable physical error in each direction, the assumed
position is accurate to within the set dead band. This suggests that either the odometry
integration estimation is invalid, or that the speed correction is incorrect. Either way further
testing would be required to eliminate these errors, but this was not deemed necessary in the
time frame of the project, as the robot did not move great enough distances that these errors
became appreciable.
6.4 Spike Testing
The spike algorithm was tested on both long and medium range sensors. It was found that
long range sensors had a higher tendency to pick out landmarks. For out of range readings,
the medium sensor was found to fluctuate. These fluctuated readings often prevented an edge
from being detected. With long range sensors, this the range was less often exceeded, thus
making edge detection a lot easier. Spike was tested with long range sensors, and the
implemented data association code and was found to correctly extract, and associate the set
cylindrical landmarks, both static and dynamic tests were made with the robot, i.e. associating
from the same position, and different position, this was found to give positive results also.
The decision to change to medium range sensors was made as the project plan varied at late
stages of the project. Although spike implemented with landmark association and long range
sensors proved to work well, it was hard to integrate with path planning. The absolute
position of the landmark is passed as an output for spike which almost proved useless without
a full SLAM implementation. From the inaccuracies of this landmark position as well as the
position error, it is very likely that collisions will not be avoided. Also, Long range sensors
have a very high lower range detection limit, this made it almost impossible to get into close
proximity with the walls therefore affecting the map coverage. Because of these two issues,
28
medium range became the better choice of sensor. Instead of locating all landmarks, the
medium range sensors were swept across the direction that the robot was travelling in and
were accounted for as they came within an intolerable distance, as discussed in Section 5.5.2
Map Covering.
6.5 RANSAC Testing
Extensive testing of the RANSAC algorithm was performed using the rotating IR sensors to
obtain a full 360o view about the robot. This algorithm performed well on the raw sensor data
it received, but the supplied data itself was not perfect. Custom models were made for each
IR sensor and so distance values obtained from them were accurate under static testing
conditions. However under dynamic conditions, with some parts of the map in shadow and
others not, as well as the servo imparting motion onto the sensors the readings were not as
accurate as desired. For example, Figure 18 below shows the raw sensor data with RANSAC
line values superimposed over the top.
Figure 18: RANSAC Test Data Output
As can be seen, the values obtained from IR sensors which represent the walls of the test
centre are very accurate along the length of the line. However, the values obtained from the
corners of the test data are incredibly inaccurate which sways the lines obtained from the
RANSAC algorithm. This is undesirable, as the corners are the points of the most interest for
performing this algorithm. The values obtained from the IR sensors at the corners are wrong
for a few reasons. The lighting conditions are always worse in the corners which can read to
inaccurate readings. As well as the infra-red beam sent from the sensor also has the
-500
-400
-300
-200
-100
0
100
200
300
400
500
-500 -300 -100 100 300 500Y
X
RANSAC with Fitted Lines
29
possibility of bouncing off the corner, hitting the wall on the opposite side and going back to
the IR sensor having travelled a longer distance, this would therefore take longer and make
the IR sensor read the value as larger than the actual distance. This phenomenon is shown
clearer in Figure 19.
Figure 19: IR Sensor Corner Inaccuracies Visualisation
From analysing the data further, one can notice sudden discontinuous jumps which is where
data from two sensors are joined. The discontinuity is mainly due to the angle of the servo not
being perfectly accurate as well as the sensor models having slight inaccuracies. The angle of
the servo motor was used to calculate the X and Y positions from the range using simple
trigonometric functions. These X and Y position arrays are what the RANSAC algorithm
operates on.
In the right most line shown in Figure 18, the line should be very nearly vertical. It isn’t and
this is mainly due to the discontinuities between the data when two different sensors are used.
The line fits the bottom half of data very well, and where it begins to diverge heavily from the
sensor data is where the discontinuity can be clearly seen.
RANSAC could estimate which direction relative to the robot was the closest corner very
well, however the actual location of this corner varied a lot more than how much the sensor
data varied. This was mainly due to the algorithm finding this corner from a line which was
fit to data points a very long way away from the corner location. This exact problem can be
seen in Figure 18.
The algorithm was initially tested for obtaining the location of the starting corner off-board
the robot using the same 360° IR sensor and servo arrangement before accurate control of the
robot was possible. The RANSAC algorithm would be performed, and then specify to the
user that the system should be moved half of the distance to the nearest intersection point that
the robot had located. The algorithm was then run again and this was performed until the
location of the found corner would not change. Through this method of testing, the position of
the closest corner could be found within 20mm in both the x and y directions.
30
7 Discussion
Unfortunately due to unforeseen problems with the Arduino board, and problematic IR
sensors, the intended SLAM algorithm could not be perfected in the specified time. The
actual simultaneous localisation and mapping from the system built a map as the robot moved
through the environment, and used this map to align itself every pass of the map. The exact
location of the robot was only evaluated through the dead-reckoning of the robot state
estimation system, and this was updated with the built map by aligning to the walls on each
passing.
A higher emphasis should have been placed on integrating all sub-components of the project.
A lot of work was performed without any in depth thought of the concept and the benefit to
the entire system. For example, both spike and RANSAC worked well in both theory and
individually testing. But when it came to integrating these with the overall system it was
difficult use this data to produce a useful control output. Integration of these two components
in to the system proved to be a lot more work than what was initially expected, thus they
became unused.
Towards the end of the project, it was decided to remove all use of the magnetometer. The
interference to be too much to give any reliable feedback from the sensor. Further
classification should have been made in order to eradicate these errors. The use of ferrite
beads for EMI rejection or relocating the sensor to a less susceptible position could have
resulted in more reliable readings, but the decision was made to use the gyroscope instead.
Mounting the MPU in a higher location (away from any electrical disturbances) was not an
option as this would obstruct the view of the IR sensors. The magnetometer would have been
the better option of rotation sensor as it gave absolute and relative position feedback.
The Mecanum wheels were very hard to predict, thus the odometry model was not as accurate
as what would be desired. Any form of direct relative positioning feedback would have been
more ideal in this case as the robots pose could only be estimated and not actually measured.
Encoder or tachometer feedback could have proved to be very useful as the velocity vectors
are directly dependent on the angular velocity of the wheel. Or the use of a spherical encoder
could have aided the odometry problem greatly. Further problems were encountered with the
motors as they would only work under certain unknown conditions. In the odd case, values
were sent to the motors, but no actuation took place. The reason for this error is still not
known, and many hours went into fixing this problem by trial and error.
The IR sensors were the main cause of most of the encountered errors. It was because of the
inaccuracies in these sensors that made both landmark extraction algorithms un-useable.
Initial planning went on the assumption that the IR sensors are ideal, this was not the case as
tuning had to happen on a regular basis to keep the inaccuracies at a minimum. On top of this,
many of the sensors needed to be replaced during the duration of the project. It was unclear
what was causing the issue with these sensors, but nonetheless the difficulty with them was a
large set back to the project.
31
7 Recommendations
7.1 Algorithm Development
The SLAM aspects of the overall algorithm should be improved so that the system
updates its known position based on the environment it is moving through. For
example, the overall position of the robot could be updated every time the robot
reaches the first main wall so as to eliminate the drift in the state estimation values
The RANSAC algorithm should be incorporated into both the mapping and the first
corner finding algorithm to improve the robot’s response to changing map sizes by
finding closest possible corner first. Measures should then be included to not have the
robot always strafing left during the general map coverage, and to incorporate the
algorithm so that the robot can strafe left, if the first corner it finds is to the left of the
robot
The Spike algorithm should be tuned for the medium-range IR sensors, and this
should be incorporated in the data association algorithm for building the map of the
environment. This could then be used for identifying obstacles that can be used for the
obstacle avoidance algorithm to recognise if an object in front is an obstacle or a wall,
and therefore determine how the robot should act accordingly
The RANSAC algorithm should be used to align with any possible walls mid-way
through the traversing of the wall. The real system map size could be a lot larger, and
so relying on dead-reckoning for the straight-line performance might not be as
accurate as possible.
The RANSAC algorithm should also be improved to ignore the distance values of
1000, which correspond to the IR sensor sensing out-of-range. These should not be
used for the algorithm building the lines and this may sway the gradients of the lines
out and make them more inaccurate.
The RANSAC and spike algorithms should be rewritten to allow for them to be run in
parallel with the motion of the robot. This would reduce the need for the robot to stop
for these algorithms to be run, and the performance of the system would be improved.
If this were the case, the scan would need to be able to be performed fast enough so
that the obstacles in front are not collided into if they are in the blind spot of the
sensors.
7.2 Sensor Improvements
The errors in the servo angle should be mapped through testing, so as to remove the
discontinuities from the built X and Y map that came about from the use of merging
three different sets of sensor data.
If the servo still proves to be not as accurate as required, then an accurate stepper
motor would work well for this system, and it would not be difficult to implement
The errors that originated from the MPU when trying to perform the rotate to wall
function should be identified, and then the function should be improved so that the
robot does not randomly rotate 180° only some of the time that the rotate to wall
function is called.
The functions used for the robot motion should incorporate the functionality of the IR
sensors actively scanning a 50° area in the desired direction of motion. This would
32
allow the robot to pick up obstacles that currently go unseen and that hit the wheels of
the robot.
The reason for IR sensors failing after being used for a short period of time should be
investigated, and the possibility of using more robust and consistent range-sensing
devices should be considered for further implementation of this project. If a new
range-sensing device is purchased, it should be more accurate and be able to sense
much larger distances
7.3 Proposed Odometry Improvements
At the software level, the full solution is produced in the following stages:
Input speeds in X, Y directions, and rotational speeds are drawn from the user, or
from the positional controller
Input speeds are coerced into a range appropriate for odometry
Coerced speeds are corrected so the output motion of the robot matches the input
Control is applied to all three speeds to maintain heading
RPM values are generated for each wheel using controlled linear speeds and
Mecanum inverse kinematics
RPM values are converted to PPM values, which are sent to the motors themselves
As described above, the complete model is lengthy, complicated, and requires a redundant
number of corrections and manipulations. In hindsight a better solution for motor control and
odometry, would have been to:
Characterise the relationships between PPM and wheel RPM, in the same manner
Find the relationship between output robot speed and input wheel RPM,
experimentally. This would give a single correction factor for conversion between
desired linear robot speed and required wheel RPM.
Fine tune the system for a smaller range of values – for example speeds between 100
and 200mm/s – and limit speeds to be within these values – this would have increased
relationship accuracy for less testing , whilst ensuring the robot still moved around the
board at an acceptable speed
This solution would have been faster, computationally more efficient, and easier to
implement. Furthermore, it would have been a far simpler task to tune or trim the system. In
all likelihood, a PID controller would have worked in this set-up too.
Finally, had an odometry and robot pose been realised earlier, even in an inaccurate form, it
could have been integrated with other SLAM elements sooner. SLAM integration would have
given a more definitive scope for the required accuracy, without which development was
aimed at absolute accuracy. This took a large amount of time and effort that may have been
wasted, if the level of accuracy achieved is unnecessary.
33
8 Conclusions
The solution presented in this report can be applied to the original goal of an autonomous
vacuum cleaner. The solution showed particular characteristics that made it both highly
practical and novel. Specifically, the following design considerations and features:
The real-time logging software that was designed using the LabVIEW software package
worked perfectly at telling the designer what was happening on the robot at any one time.
This functionality could be further enhanced if the docking station of the robot had some form
of a processor to supply feedback on the operation of the system. This could provide valuable
information to the user and improve the marketability of the system.
The decision to mount the three sensors on the rotating servo gave the ability to see all of four
directions of motion easily, and allowed for the robot to scan in these directions without the
need for having four sensors. By reducing the amount of sensors used the cost of the system
was less, as well as providing a simpler implementation. The final robot had a very
minimalistic design because of using only these three sensors. It also lead to a much smaller
profile than many other concepts.
The robot path planning algorithm works in a very predictable way, which is desirable for a
home situation where the home owner can see where it is operating, and they know it will not
move from its path until it reaches the end wall. The robot also operates in a systematic way,
so once it has left an area for cleaning that entire area would have been covered.
34
9 References
1. Huang, F. and Song, K. (2008). ‘Vision SLAM Using Omni-Directional Visual Scan
Matching’. Paper presented at 2008 IEEE/RSJ International Confernece on Intelligent
Robots and Systems, Nice, France
2. Beevers, K. and Huang, W. (2008). ‘An Embedded Implementation of SLAM with Sparse
Sensing’. Paper presented at the 2008 IEEE International Conference on Robotics &
Automation (ICRA 2008)
3. Abrate, F., Bona, B. and Indri, M. ‘Experimental EKF-Based SLAM for Mini-rovers with
IR Sensors Only’. Dipartimento di Automatica e Informatica, Politecnico di Torino,
Torino, Italy
4. Wang, K., Xia, G., Zhu, Q., Yu, Y., Wu, Y. and Wang, Y. (2012). ‘The SLAM Algorithm
of Mobile Robot with Omnidirectional Vision Based on EKF’. Paper presented at the
International Conference on Information and Automation, Shenyang, China
5. Burnner, C., Peynot, T. and Underwood, J. (2009). ‘Towards Discrimination of
Challenging Conditions for UGVs with Visual and Infrared Sensors’. Paper presented at
the Australasian Conference on Robotics and Automation (ACRA), Sydney, Australia
6. Sheu, J., Wang, Y. and Huang, T. (2012). Implementation of Indoor Wireless Positioning
System in an Omni-wheel Robot Based on Gyroscope. Advanced Materials Research,
482(2): 126-135.
7. Søren Riisgaard and Morten Rufus Blas. 2005. SLAM for dummies. [ONLINE] Available
at:http://ocw.mit.edu/courses/aeronautics-and-astronautics/16-412j-cognitive-robotics-
spring-2005/projects/1aslam_blas_repo.pdf. [Accessed 20 May 15].