| Item No. | Date Initiated | Date Resolved | Participants | Description | Alternative Options | Resolution | Justification |
| 1 | 2/4/2025 | 2/5/2025 | Tom, Kshitij, Abhishek | The interface between perception and planning subsystems needs to have commonly defined messages to avoid version mismatches and integration issues. | – Create additional repository housing commonly defined message types (Chosen) – Create and manually sync data types on both sides (likely to mismatch) | We created a Pepper.msg datatype and defined it to contain a Header, a Fruit, and a Peduncle, the latter two containing a Pose and a SolidPrimitive for shape and pose. | Subsystem leads established common understanding of what the data represents, and having one source of truth is good practice compared to separately defining message types. |
| 2 | 2/10/2025 | Pending | Tom | Our usage of the xarm_ros repository results in high dependency on their framework and large amounts of files involved in builds | – Fully map out package dependencies and only import from xarm_ros what is strictly necessary (Chosen) – Continue working in our fork of xarm_ros repository and build additional packages around it (messy) | We are still working on migrating our code out of xarm_ros, but several packages from this repository are critical to operation and must be used. | Getting rid of unused dependencies simplified the codebase and makes it more understandable. |
| 3 | 3/20/2025 | 4/3/2025 | Abhishek | The gripper end effector was damaged, and needs to be manufactured and reassembled, which depends on sponsor knowledge | – Ask sponsor for updated CAD files, and run through production of each spare part at least once (Chosen) – Only manufacture what is broken at the moment | With help from the lab personnel, spare parts for each part of the end effector were manufactured with the lab printer and assembled. | This allows us to reduce the grey area of knowledge that we need to fetch from Dominik ahead of his departure. |
| 4 | 3/20/2025 | 3/22/2025 | Tom | There is no simple way to make sure build environments are identical between the lab PC and teammate laptops. There is a high demand for time on the shared lab PC between everyone | – Create a Dockerfile that encompasses all dependencies and have team members develop using this docker (Chosen) – Use an access schedule to ration access to the PC (restricts efficiency) | A Dockerfile was created with all dependencies for each subsystem, and used each time software is developed on team member computers. The dockerfile is updated as more packages are needed. | This allows us to parallelize our work and avoid resource constraints so that everyone can work on their own devices. The standardized dependencies in the docker allows safer development as well, as the containers can be re-created. |