MGC Mapper

This page is no longer updated - This was left as an example of work on the 2009 Mini Grand Challenge team

A mapping algorithm is an algorithm that takes, as input, a system's sensors (such as vision, laser range finders, etc..) and generates an image, either as a binary or probability map, of it's surroundings as output. Some mapping algorithms allow a "global map" to be generated over time that represents all of the terrain traveled which is useful for certain competitions. Our Mini Grand Challenge and IGVC robots will create a gray-scale probability map over time. This is used for correct path planning. The inputs are laser range finder data, vision data, digital compass data, and vehicle location data (odometry and GPS). The laser and camera data is fused to create more helpful and longer ranging data via the MGC Vis2Laser. The output of this fusion algorithm is a probability map. It is important to note that this algorithm will be, at the end, implemented in a Player driver.

Our technique is based off of the SLAM model: Simultaneous Localization And Mapping. Our algorithm is based off of the "DP-SLAM" approach. It has the following features:
 * Grid-based
 * Contains probability information of obstacles
 * Handles cycles / loops (which is important for outdoors mapping)
 * Does not need special landmarks for orientation (it uses natural obstacles for references)
 * Uses laser range data
 * Uses optometry
 * Uses GPS
 * Uses a particle filter (Particle Filter on Wikipedia)

= Algorithm =

The mapping algorithm takes three high-level steps per each cycle.


 * Perception (Queries sensors)
 * Processing (Interprets sensor data)
 * Fusion (Fuses local sensor data with a global map)

The following algorithm is the formalized version of the above three steps. Input: MGC Vis2Laser, vehicle location. Output: Global probability map (as gray-scale image).


 * 1) Initialize a local probability map with all elements to zero (no obstacles)
 * 2) This map will be of an appropriate size to contain the surroundings of the robot as well it's sensors
 * 3) Query sensors
 * 4) Based on a configuration file, query either directly the laser range finder or the given data from MGC Vis2Laser
 * 5) Generate a local probability map of the above sensor information
 * 6) For each element in the sensor array (since each is a distance between the sensor and object) apply the following function:
 * 7) If distance is greater than a maximum distance threshold, set location in the local probability map to zero
 * 8) Else if distance is within the maximum distance threshold and minimum distance threshold apply an exponential decay function that takes a distance dist and returns a floating point value from 0.0 (no object) to 1.0 (colliding object) to the correct location in the local probability map
 * 9) Else distance is within the minimum distance threshold apply the location in the local probability map to 1.0
 * 10) Using an sub-image searching/matching algorithm, find the location of the local probability map within the global probability map
 * 11) Superimpose the local probability map into the global probability map with the help of currently assumed vehicle positioning; save the new sub-image location
 * 12) Return global probability map
 * 13) Return new odometry data

Please note that odometry data will actually be updated via this mapping algorithm to help the vehicle determ, more correctly, it's position. GPS and pure odometry is not a trusted source as both of these contain inherent errors over time.

= Object Oriented Design =

The following classes are part of the design of this component:


 * MGMapper.cpp/h: The Player driver class that completes the standard player interfaces for a mapping driver
 * Mapper.cpp/h: A class that implements the main logic and data query.
 * LocalMap.cpp/h: A representation of the current local map. Given to global map over a time cycle.
 * GlobalMap.cpp/h: Representation and memory manager of the global map. Saves to the image files over a time cycle.
 * Localization.cpp/h: Implements the pattern matching between the local and global map.
 * Example.cpp: Code that tests the mapping algorithm.

= Questions & Answers =


 * Should the probability map be initialized to all drivable or to all collisions? JBridon 20:53, 14 February 2009 (UTC)
 * Should each element returned from the distance range finder (laser/image/fusion) be positioned on the map? JBridon 19:34, 14 February 2009 (UTC)
 * One distance related to one element of the map? JBridon 19:34, 14 February 2009 (UTC)
 * Should there be a "line" between each element within the map? JBridon 19:34, 14 February 2009 (UTC)
 * Should we dilate every data point we find for the map? Rich
 * Other methods? Rich
 * Answer: Dilation might be best. Connecting data points together might hide edges because of a too-low resolution (Think about a corner between two laser range points). JBridon 22:59, 13 February 2009 (UTC)
 * Dilation would certainly be helpful in the path planner, as it increases the cost of going near an obstacle and thus smooths out the path. However, should this dilation be done in the mapper, or in the path planner, thus keeping the global map an accurate representation of how we perceive the world?  I'm not saying one way is better, but it is something to consider Adam.brockett 04:25, 14 February 2009 (UTC)
 * What is the "averaging" function between the local map and the global map when adding both? JBridon 19:34, 14 February 2009 (UTC)
 * Using a Geometric Mean seems a good place to start. It would also be nice to take into account the "age" of data in the global map (ie. "new" global map data isn't much more reliable than the local map.  However, "old" global map data definitely is more reliable) Rich
 * Ask Zack about his work matching laser scans and odometry data JBridon 19:34, 14 February 2009 (UTC)
 * Answer: Zack's algorithm is roughly the same, it boils down to the local to global image matching algorithm we choose. JBridon 22:59, 13 February 2009 (UTC)
 * Incorporate vehicle model (predicted trajectory) and compass data into averaging function Rich
 * How / why is this helpful? The compass will be used for local to global map orientation, but predicted trajectory might be more path planning. JBridon 19:34, 14 February 2009 (UTC)
 * Helpful to give a baseline for map matching. Determines vehicle's approx. displacement in the global map based on position, body orientation, and ackermann orientation Rich 00:20, 14 February 2009 (UTC)
 * Use shades of gray to indicate reliability of global map data? Rich
 * I though about this, but gray already means reliability of it being a obstacle. Or are these just two ways of saying the same thing? Adam.brockett
 * Answer: The "gray" simply means the reliability of something being an obstacle. The data representation will be an unsigned byte from 0 - 255. The resolution is by far good enough. JBridon 22:59, 13 February 2009 (UTC)
 * Are these shades of grey even useful to our path planner? D* only works on filled/non-filled cells.  Could be useful if we modify the basic D* algorithm to take advantage (outside scope of this thread) Rich 00:20, 14 February 2009 (UTC)
 * D* handles shades of grey perfectly fine (It uses a cost function, and the cost for an arc can be any number). In fact, as mentioned about dilation, I believe D* would work better under shades of grey. (And yea, getting a little off-topic) Adam.brockett 04:25, 14 February 2009 (UTC)
 * What are the exponential decay function's constants? Rich
 * How should global map be stored? Rich
 * On the hard drive? (Yes, because it will be that big) Rich
 * As one massive file? Rich
 * As many small files dealing with a "cell" of the overall map? Rich
 * Pros: We don't need to store information about areas we know nothing, and will know nothing about (such as the center of the lake). Allocate new map cells as we need them, so we don't have to build one massive file that is mostly information we'll never use.  Can use average obstacle density of cells as a source of coarse path planning information? Rich
 * Cons: Have to deal with issues when working at the edges of these "cells". But perhaps that will only be an issue when writing the global file to hard disk, and perhaps we can treat the entire area as though the map exists, and let the map driver filling the requests sort out merging multiple files.
 * Grey-scale images should be easily compressible, do we want to to store image in .jpeg or other compressing format? And deal with possible slowdowns when loading up many images into Bitmaps? Adam.brockett 04:25, 14 February 2009 (UTC)
 * Should we keep the immediate area in memory, having the map driver precache/pre-allocate cells quietly in the background as we approach them? Rich
 * Answer: All global map interfaces will be hidden by a class that will support a set of standard access functions. The class will manipulate a current "arena", or square sector, the robot is in. This will change over time. If the mapping algorithm needs to access data outside of a square, it will buffer them up appropriately. After a certain amount of data updates, the class will dump this updated arena into a single file. After either an explicit function call, or over a set amount of time, or during the program's release: a final map of all "arenas" are stitched together and built into a final image. JBridon 22:59, 13 February 2009 (UTC)

= References =


 * Introduction to SLAM
 * [[media: dpslam1.pdf]] DP-SLAM 1
 * [[media: dpslam2.pdf]] DP-SLAM 2
 * A linear time algorithm of the above two approaches
 * Open Source Implementation of DP-SMAL
 * Open source SLAM implementations
 * Wikipedia Article: Link
 * Mapping paper: Link