1. ROBOT LOCALISATION & MAPPING: MAPPING & LIDAR By James Mead

2. Content  Project Overview  LIDAR  Use of C++ libraries  Program Structure  Wireless data transmission  Data Decoding  Mapping  Positioning  Challenges faced  Conclusion

3. 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 Kinect, Interfacing, IMU, data Transfer James Receiving data/decoding, mapping, positioning Ken Path planning, robot control, Navigation.

4. LIDAR  Hokuyo UTM-30LX  Range of 30m  40Hz scan rate  270º field of view  0.25º resolution(1081/scan)  USB2.0 serial connection

5. 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 portablewell-testedset of librariesapplications

6. MRPT Libraries & Dependencies

7. Program Structure  All input devices are on the Lynx robot:  IMU, LIDAR, Kinect, Wheel Encoders(odometry)

8. 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.

9. 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.

10. 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.

11. 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.

14. 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.

15. 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.)

16. 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.

17. 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!