ROBOT LOCALISATION &
MAPPING:
MAPPING & LIDAR
By James Mead
Content










Project Overview
LIDAR
Use of C++ libraries
Program Structure
Wireless data transmission
Data Decoding
Mapping
Positioning
Challenges faced
Conclusion
Project Overview

The initial Plan
 Completely
Autonomous robot capable of SLAM.
 Working in a group of 3, each member has a specific area.

Project Breakdown
Robot
Scott
James
Ken
Kinect, Interfacing,
IMU, data Transfer
Receiving
data/decoding,
mapping, positioning
Path planning,
robot control,
Navigation.
LIDAR

Hokuyo UTM-30LX
 Range
of 30m
 40Hz scan rate
 270º field of view
 0.25º resolution(1081/scan)
 USB2.0 serial connection
Using code Libraries



Needed an efficient way of creating an occupancy grid to
store data and also return data when needed for path
planning.
Building the program structure from the ground up would
be a project in itself. Using available libraries reduces
excessive workload.
MATLAB, ros.org, MRPT
MRPT more windows friendly, great API, easier to get started.
Mobile Robot Programming Toolkit (MRPT) provides C++ developers an extensive,
portable and well-tested set of libraries and applications which cover the most common
data structures and algorithms employed in a number of mobile robotics research areas:
localization, Simultaneous Localization and Mapping (SLAM), computer vision and
motion planning (obstacle avoidance).
-MRPT.org/about


MRPT Libraries & Dependencies
Program Structure

All input devices are on the Lynx robot:
 IMU,
LIDAR, Kinect, Wheel Encoders(odometry)
Wireless Data Transmission

Data processing is very computationally expensive
Occupancy grid map requires large amount of memory as the map
grows.
 Path planning is very CPU intensive


FIT-PC unable to handle all the calculations, so they are done
on a base PC which will also display the map.


Data is sent to base PC via TCP connection & drive commands are
sent back to the robot.
Both UDP & TCP protocols were written, but TCP used because
it is reliable, requires no error checking and the added
overhead doesn’t affect the program at all.
Data Decoding

Wireless data received from robot is encoded.
 1084
float values sent at a time
 1081x
scan values from LIDAR
 1x IMU float value
 2x Encoder wheel integer values

Each value represented by 3 bytes, so all data is received
in block of 3252 bytes.
 Block
is split into 1084 segments of 3 bytes then decoded.
 Since data is transmitted via TCP, there is no need for error
checking at the received end.
Mapping
 Occupancy
Grid map, what is it?
 Mapping
is done by representing the environment as a large
collection of cells. (Like the pixels in an image file)
 Each cell has a value from 0.0 to 1.0, with 0.0 representing an
unoccupied cell (empty space) and 1.0 representing occupied space
(solid wall or object). Unknown space has a value of 0.5, which is
how all cells start.
 Map
can be easily converted to a 2D array(maxtrix) for use in
path planning.
Mapping Continued




LIDAR range data combined with Yaw reading and
odometry data to form an “observation”
MRPT libraries allow the insertion of an observation
straight into the grid map.
The grid map cells get updated, along with the updated
position of the robot.
The map is saved as a .bmp image, and then the image is
passed to the display window.
Positioning in the Environment





Need to implement some form of algorithm/filter to
increase accuracy of environmental positioning.
Without it small odometry errors will compound to the
point of rendering the map useless.
The Extended Kalman filter (EKF) or Particle filter (Marcov
localisation) can be implemented through the MRPT
libraries.
Robot design makes the filter even more important for
accurate positioning.
Will be implemented & tested over the next couple weeks.
Work still to do




Implement a localisation filter.
Fusing my program with Ken’s path finding program.
Real-time testing on the robot.
Make the program more robust (error handling in
connection dropouts, general optimization.)
Issues faced along the way

LIDAR only arrived 2-3 weeks ago
 Before
this we had to work with “faked” data scans and
theoretical values.
 More work done in the last 2 weeks since acquiring the LIDAR
than in the 3 months before that.



Scott’s work done in C# & mine in C++, creating
compatibility issues.
My program is very dependant on Scott’s, so any
unforseen delay in his work slows me down and vice versa.
Difficult to work on my section solo.
Personal issues, slowed the group work down.
Conclusion





As with most large projects, we’ve had to deal with
unforseen issues and challenges.
Still a lot of work to be done but progress is coming along
quickly.
Working in a group has had it’s challenges, but also had a
lot of benefits.
Initial hurdles such as working with different programming
languages have become a benefit (C, C#, C++, Objective
C) as work is coming along quicker now that they all work
together.
Robot will be functioning at the Expo, come check it out
then!