If we had more time, we could do the following:

1) We could create a wrapper node that acts as an intermediary between the robot and our code. Instead of each module needing to account for the run_on_robot flag, this node could put the information into a standardized format regardless of if the robot is real or in simulation. This node could be run on the robot allowing the use of the Interbotix python package.

2) We could add redundancy to the arm controller module. If both the drive controller and the occupancy grid are accurate, the arm controller can simply move the arm to the target point P to grab or release blocks. However, if one or both of the systems are not accurate, the arm controller would fail. Thus, we can add redundancy by using blob detection directly on the camera feed in addition to the occupancy grid to locate the block and tell the arm where to go in robot-space, bypassing the need for highly-accurate driving and occupancy detection.

3) We could integrate our controller onto the multi-robot simulation. By having multiple robots running in parallel, we can test for unaddressed edgecases in our collaborative method.

4) Once the previous steps are implemented, we could run physical tests using two Locobots at once, to test for sim-to-real errors in our collaboration.

5) Incorporate machine learning techniques to optimize the robot's strategy during gameplay.