MUR Blog - Mapping Module Validation

After arduous work in programming and design a basic slam implementation has been completed. Much work remains to implement and validate the system so that it works and will perform optimally. This blog post describes the beginnings of an approach to slam validation.

ROS simulators and comparisons

As the final product will be deployed on a system that runs ROS I will utilise ROS as the testing environment. The gif below simulates a basic world with a number of cones and a dummy race car that drives around at random and detects cones with some error. This measurement is then passed along to the actual slam algorithm which then outputs a pose.

1

This simulation is very basic and has a number of noted limitations. It will work for basic validation but not for a more sophisticated verification of the slam modules' performance. Especially given that the forward kinematics model and that the inverse sensor model is very naive. Fortunately, the open-source community provides a number of useful tools. One source that I have drawn on was sourced from the preeminent team at AMZ racing (ETH Zurich’s team): Souce code here

Unfortunately, this simulation is designed to interface with the AMZ autonomous stack so another layer of interfacing is necessary to make this all work in ROS. The simulation released by AMZ publishes point cloud data where the slam algorithm receives messages of the type shown here. A simple intermediary python script resolves this; taking in ros pointcloud2 type messages and outputting the custom MUR message to be ingested by slam. We can see all of this happening in the following ros graph. The simulation contains a number of complex nodes that are unused, the useful slam related stuff is above.

About the Author:

JackMcRobbie

Jack McRobbie
Spatial & Perception Engineer, 2020