This week, I used BreeySLAM (a SLAM package in python) while moving the robot with commands in real time over SSH to generate several different maps –

with scans from a single point, the SLAM was not accurate and noisy.

With multiple scans generated from the robot moving in a line, the map is more coherent although the dimensions look a little off (the map looks too small to represent my room, so the SLAM seems to be extrapolating the positions of walls)

With the roomba moving from my room into the hallway, as well as moving back and forth and making rotations, the map wasn’t quite as smooth. While the generated map does seem to have captured that the robot was moving from a room to the hallway (see corner on top on top of map), it is quite noisy possibly due to the non linear movement of the robot.

In contrast, the above map was generate along the same route (bedroom to hallway) but was much more smooth since the robot moved in a straight line.

This final image maps an uncluttered corner of my bedroom, as well as noise generated by surrounding objects. Although this map is relatively smaller than the other, I think it is relatively more accurate in stitching together scans at different positions. This was because I fed it “dead reckoning” odometry where I would provide the SLAM algorithm the speed I set the robot at. In this case, I hardcoded the speed and simply moved the robot in a vertical line.

The team agreed that we would definitely be able to generate better maps by giving the the SLAM algorithm real time “dead reckoning” odometry data. This coming week, I plan to write a script that would enable me to both move the robot and feed the SLAM odometry data in real time. If the generate maps are still not accurate, I plan to explore other methods of providing odometry including:
– Calculate speed from consecutive lidar scans
– soldering on an IMU
– using a phone IMU
– looking further into the roomba wheel encoders (they were pretty inaccurate the last time I tried to use them).