It is very important that Sensor Fusion performs correct data association when creating fusion cones. This can be tested in the simulation as the cones have been given a unique id. In simulation, when the camera and Lidar sensors "observe" these cones, the cone observation they create for it also stores the id of the real cone it has observed. This allows data association to be tested as when two cone observations pass the threshold and are merged, the test checks the ids of both cones. If the ids are the same, the data association is correct and it shows that sensor fusion is merging the correct cones. Currently, the data association is working properly and merging correct cones. The ids are a new feature of the simulator allowing for more testing in the future. One idea for the next team to implement will be using the ids to check if any duplicates of the same cone have slipped through the threshold.
Testing SLAM can be particularly tricky since you essentially need to use steps like data association which happen in SLAM to test it. This can result in code testing itself in a sense which is not particularly useful. Fortunately, one of the other capstone projects is dedicated to developing a simulator which has been used extensively to qualitatively evaluate the SLAM code. The simulator is capable of displaying information important to evaluating SLAM, such as the ground truth map which shows the actual location of the cones in the environment. It can also show the cones that are passed into SLAM from the sensor fusion module at each time step. This allows the map that is generated by SLAM to be compared closely to what it should produce. Additionally the simulator can show the covariance associated with each landmark in its map so that the confidence in the cone locations can be evaluated.
Screenshot of simulator showing cone covariances with purple circles
Screenshot of simulator showing cones the vehicle has picked up with sensors in the blue/yellow circles
The Restricted Distance function is defined above, each case covering an operation of the Damerau–Levenshtein distance
To test if the generated boundaries are close enough to the real ground truth, each cone is given a unique number and the edit distance between the sequence of generated boundaries and real track data is checked. By performing an edit distance calculation on the order of these identifiers and the order of the real boundaries, the accuracy of the boundaries generated by the algorithm can be calculated. The test procedure uses the Damerau–Levenshtein distance, which allows four operations on the sequence. These operations include deleting, adding, substituting, and swapping elements in the sequence, and at the end outputting the minimum number of edits necessary to make the two sequences the same.