Up to this point, we have already completed our product as we have assembled the components together and did extensive tests to ensure that the robot works as intended. The only thing that can jeopardize our success would be some unexpected failures on the demo day. For example, there may be accidents where people unintentionally damage the robot, causing the wires to disconnect or the basket to fall. However, we plan to keep the robot in a safe corner when it’s not operating and closely track it while it is moving. We also have backup videos to show the audience. The other risk would be unexpected behaviors due to some edge cases in the crowded environment on the demo day. However, we did our best to extensively test all kinds of scenarios, which we will specify in the additional section.
We made a small change to the physical assembly of the robot. Previously, we planned to have one pipe attached to the robot base to support the basket, but when we actually assemble it, we found that the basket does not seem stable and balanced when there is only one pipe to support it. Therefore, we instead used two pipes front and back to support the basket, which made the basket much more stable, as seen below. We didn’t make any system change on the software side.
Since we are on schedule and successfully completed our product before the final week, we did not make any change to our schedule.
Additional section of testing:
We conducted both unit tests on full system validation tests (Table 1) and individual subsystems (Table 2) to experimentally evaluate the SafeFollow system. The unit tests covered YOLO-based person detection, bounding box stability, stereo depth estimation, PID motor control, ultrasonic sensing, and communication stability. These tests verified that each subsystem meets its design requirements under controlled scenarios such as hallway tracking, multi-person environments, and varying lighting conditions. The system-level validation tests evaluated integrated performance across key metrics including detection accuracy, frame rate, following distance, obstacle response time, person re-acquisition, and achievable following speed under realistic scenarios.
From the test results, several important findings were observed. The system performs reliably in perception accuracy, smooth following, and obstacle detection, indicating that the vision pipeline and safety mechanisms are well designed. However, failures and partial passes revealed limitations in following distance, re-acquisition time, and maximum speed. In particular, we are using linear speed control commands in our PID control modules, with a mapping from [0, 255] to [0, 0.5] m/s, which constrains the achievable speed range. Additionally, although the robot provides a PID speed control command (ID 2) in its JSON instruction set to manually set a reserved maximum speed parameter, the robot base does not respond to this command, further limiting speed performance. Following distance errors occur during sharp turns or obstacle avoidance, suggesting insufficient responsiveness in dynamic scenarios, while re-acquisition delays are caused by the need for full scanning in worst-case conditions.
Based on these findings, we made several design improvements. We further tuned the PID controller to improve responsiveness and reduce lag, incorporated ultrasonic sensing as a safety override for obstacle handling, and refined the interaction between perception and control to improve stability in edge cases. We also adjusted system expectations by prioritizing stable and safe operation over achieving higher speed, given the hardware constraints. These changes improve robustness and ensure the system better meets real-world usage requirements.
