This week, I worked almost entirely in meetings with Shanel and Aditi. We integrated all the subsystems into one central program. This program runs each module in a separate thread:

• Main thread for control flow and navigation
• SLAM thread for reading LIDAR data and doing SLAM stitching
• Movement thread for giving commands to the robot
• Obstacle thread to interrupt movement when obstacle bumped

The SLAM thread is constantly running and updating the map, but we don’t do additional navigation processing unless either we arrived at our destination and need a new path, or have bumped into an obstacle and need to repath.

When we decide we need a repath, the main thread grabs the map from the SLAM thread and does all the map processing on it, choosing a new destination and routing a path. These routing instructions are sent to the movement thread. When they are all consumed, a new path is requested, and so on.

Overall, I would consider our system as a whole to be fully integrated for the first time. There are still many edge cases and optimizations required.

 

Next week, I plan to optimize the program. There are some small instances of lag that I would like to fix, since every little bit of movement lag decreases our map accuracy. There are also several areas where we kind of band-aided the code. The A* search is currently partially bugged, which Shanel is working on right now and we will work on together next meeting.

 

The major risks I foresee are the band-aids I mentioned. For one, we use a recursive flood-fill to check for map completion, but had to increase the Python recursion limit from 1000 to 3000 for it to cover our map. This currently poses no threat as our recursive function is extremely lightweight, but will become exponentially more expensive as we increase map resolution.

Additionally, there seem to be several edge cases in our code. For example, if we start the program with an obstacle directly in front of the robot, it freezes up for some reason. These will require testing.