Risk Assessment & Management
The most significant risk currently facing the project is system integration complexity. The robot now combines several independent subsystems: the KR260 vision pipeline, ROS 2 communication bridge, Nav2 navigation stack, Google Cartographer SLAM, and the VNH5019 motor driver, all of which must operate reliably together in real time. A failure or timing issue at any interface point can break the full navigation and detection loop. This risk is being managed through incremental integration testing: each subsystem was validated in isolation through unit testing before being connected to the stack, and the team is actively debugging edge cases such as the RPLiDAR initialization timing issue that was identified this week.
A second significant risk is hardware reliability. The RPLiDAR serial timeout failure demonstrated that a single faulty component can halt progress across multiple dependent subsystems. We fixed this by replacing it with a new unit, which restored LiDAR, SLAM, Nav2, and motor control functionality, but a single fragile moving component completely crippling our implementation is a concern. Going forward, the contingency plan is to maintain awareness of which components are single points of failure and, where feasible, have spare units or fallback sensor configurations available before the final demonstration. Looking back, we could have treated the sensor with a bit more care…
A third risk is schedule pressure ahead of the interim demo. The pan-tilt camera integration and full end-to-end validation between the vision and navigation systems are still outstanding. If camera tracking integration takes longer than expected, the contingency is to demonstrate autonomous navigation and human detection independently. The core navigation stack is already functional, and our bluetooth speaker plays the correct audio, so we feel that we will have a strong interim demo even if certain parts are not ready for the final demo.
Design Changes & Their Implications
One notable change to the system design was the addition of bounding box aspect ratio analysis to the pose detection pipeline on the KR260. The original detection approach relied primarily on pose keypoints, but this proved insufficient for reliably identifying persons in a lying-down orientation without generating false positives from partial body detections. The heuristic was refined to combine bounding box size, position within the frame, and aspect ratio to improve classification accuracy. This change was necessary to make the laying-down detection practically usable rather than noisy. The cost is added complexity in the detection pipeline and additional tuning effort, but this is mitigated by the fact that the change is contained entirely within the vision subsystem and does not affect the ROS 2 interface or downstream navigation behavior.
No changes to the high-level requirements or system block diagram have been made. The overall architecture KR260 for vision, Raspberry Pi 5 for compute and motor control, RPLiDAR for mapping, and Nav2 for navigation remains as originally specified.
One minor additional change that will be made is the addition of fillets and thicker joints for our bucket due to how it is mounted. 3D printed structures have vastly different strength depending on which way you stress them.
