Significant Risks and Mitigation
The primary risk is integration timing between the three parallel development tracks. The vision pipeline on the KR260, navigation stack on the Raspberry Pi, and motor control system must converge for end to end testing. If any subsystem falls behind, full system validation will be delayed, potentially impacting our Week 9 Hamerschlag Hall demonstration. We are managing this by establishing clear interface specifications including TCP socket communication for human detections, ROS2 topic structures for velocity commands, and serial command protocols for motor control. Each subsystem is being developed with stub nodes and mock data that allow independent testing without dependencies on other components.
Hardware reliability presents ongoing challenges. In our unit testing so far, we are happy with our odometry drift mitigation, but are worried about it for longer routes. We experienced intermittent I2C communication issues with the OTOS sensor that required power cycling to resolve. We are also maintaining backup components for critical sensors where budget allows.
Computational performance on the Raspberry Pi 5 remains a concern. Running Cartographer SLAM, Nav2 navigation stack, odometry processing, and eventual human detection data fusion simultaneously could exceed the Pi’s capabilities. Initial testing shows acceptable performance with SLAM and Nav2, but we have not yet stressed the system with the full sensor suite and motor control running concurrently. Our contingency plan involves optimizing SLAM update rates, reducing Nav2 planning frequency, and potentially offloading some processing to the KR260 if performance degradation occurs.
The switch from slam_toolbox to Cartographer introduced a new risk around loop closure and map consistency during long navigation sessions. Cartographer’s submap approach is more robust to fast motion but requires careful parameter tuning to prevent map drift over time. We are monitoring this through extended mapping sessions and will adjust loop closure parameters if necessary.
Design Changes
We made a significant change from slam_toolbox to Cartographer SLAM this week. The original slam_toolbox implementation experienced severe map distortion when the robot moved faster than walking pace. The entire map would shift and warp, making navigation impossible. Cartographer’s scan matching algorithm with larger search windows and motion prediction from odometry handles rapid movements more robustly. This change required creating a custom Lua configuration file with parameters tuned for our RPLidar A1M8 sensor and modifying launch files to use Cartographer instead of slam_toolbox. The time cost was approximately one day of configuration and testing, but the benefit is substantial improvement in mapping stability during actual robot motion.
Another design decision was abandoning Gazebo simulation in favor of exclusive real hardware testing. We discovered the Raspberry Pi 5 GPU only supports OpenGL 3.2, while Gazebo Harmonic requires OpenGL 3.3 or higher. Rather than purchasing additional hardware for simulation, we elected to conduct all testing on the physical platform. This actually accelerates our progress by forcing earlier confrontation with real-world sensor noise, timing issues, and hardware integration challenges that simulation would not reveal.
A major design shift was moving from UART to TCP socket communication between the KR260 and Raspberry Pi. The original design used UART serial communication for transmitting human detection bounding boxes, but this proved unreliable for the data rates required when multiple humans are detected simultaneously. TCP over WiFi provides higher bandwidth, built-in error checking, and simpler debugging. This change required setting up static IP addressing on the Pi via netplan and implementing socket-based communication on both the KR260 transmit side and the Pi receive side.
We constructed a temporary testing platform using an Elegoo Smart Robot Car V4 chassis to validate the navigation stack with actual movement before the final mechanical design is complete. This allows the navigation and motor control subsystems to develop in parallel with the mechanical assembly. The Elegoo platform uses the same TB6612FNG motor driver as our final design. We debugged the full Nav2-to-motor-control pipeline where Nav2 publishes cmd_vel, a Python ROS2 bridge node computes differential drive kinematics, and sends serial commands over USB. The project remains on schedule. Week 6 milestone for closed-loop navigation has been achieved with the full Nav2 stack running and motors responding to velocity commands. Week 7 priorities include implementing the behavioral FSM, establishing TCP communication for human detections from the KR260, and tuning the NMS post-processing pipeline. Week 8 focuses on system integration testing, and Week 9 remains on track for Hamerschlag Hall demonstration.