Team B7: SafeFollow

This week, we focused on integrating the robot hardware with the vision pipeline on the Raspberry Pi while preparing for the interim demo. A large portion of our time was spent resolving system-level issues, including version mismatches across camera drivers, libraries, and the robot control interface. These integration challenges required debugging at the OS and dependency level to ensure the camera, perception pipeline, and robot base could operate together reliably.

On the perception side, we worked on improving depth estimation using stereo disparity maps, which provide more stable and structured distance information compared to simpler approaches. On the control side, we developed a draft of the emergency stop logic to ensure that safety overrides can immediately halt the robot when necessary. Overall, this week involved shifting from mostly software development to hands-on system integration, and although progress was slower due to unexpected technical issues, these steps are essential for enabling full system testing in the upcoming weeks.

The most significant risk remains the integration between motor mobility and the vision pipeline, especially the coordination between target tracking and obstacle detection, and while we have made some progress by starting ultrasonic sensor integration, the system has not yet been tested as a whole in real scenarios. Another important risk is that most of our testing so far has been done in software through unit tests, with very limited testing on actual hardware, which means there may be unexpected issues when the robot operates in real environments. To manage these risks, we will start hardware testing as early as possible even before full integration is complete. As a contingency plan, if the full system does not perform reliably, we will simplify the behavior so that the robot prioritizes safe stopping instead of complex navigation.

There are no major new design changes this week, but we continued implementing the previous change where the robot automatically moves around obstacles instead of requiring user input, and we also started integrating ultrasonic sensors to improve obstacle detection. This change was necessary to improve the usability and safety of the system based on feedback, but it introduces additional integration effort and requires more time for tuning the interaction between sensors and control logic.

There are no major changes to the overall schedule at this point, as we still expect integration to be completed in less than one week and testing to take around two to two and a half weeks. However, we plan to start hardware testing earlier than originally planned as soon as partial integration is ready, which allows us to identify issues sooner while keeping the overall timeline unchanged.

The most significant risk that could jeopardize this project will be the integration of the motor mobility and vision pipeline, and the interconnection between target tracking and obstacle detection. Right now, we have the motor mobility and most of the vision pipeline done, and they seem to work independently, at least for simple tests. The challenge is therefore how the robot reacts to complex circumstances once everything is done, e.g., when the person comes back and forth in front of the robot. We currently plan to have two weeks for such extensive tests, but we would like to extend it slightly to at least 2.5 weeks, as integration probably can be done in less than a week.

We made a slight change to our system, where we now plan to have the robot to remain moving if it faces an obstacle to try to go around it, instead of requiring the user to manually press a button to make it move. This is to address the feedback we got for the design proposal for increased convenience. This will likely take more time to implement, so we will try to squeeze more time for this change.

As discussed above, we would like to extend tests from 2 weeks to at least 2.5 weeks, as integration probably can be done in less than a week. However, this is not definitive, and we’d like to start testing as soon as integration is done. Therefore, we will leave the schedule unchanged for now but we will be aware that test can be started early if possible.

Right now, the most significant risk is time management. Because the past week was Spring break, our team was a little bit behind our schedule. However, we are generally on track and will have the chance to make up for it in the following day or two. Also, the current stage revolves around the middle of the implementation of our two key modules — motor mobility and vision pipeline, so as long as we meet the deadline of these modules in a few weeks, we would still be on schedule.

In the past week, we didn’t make any change to our design system, but to address some feedback we got in the design presentation, we chose to add a state diagram to better showcase and remind ourselves how our system works on a high level.

We didn’t make any change to our schedule because we are only a little bit behind our progress, which can hopefully be caught up by the end of this week, but we need to keep in mind that we must catch up to our current schedule by the end of next week. Otherwise, changes should be made.

 

A was written by Xinyu Li, B was written by Wuyang Li, and C was written by Xinyu Li.

Part A: Our SafeFollow system is designed as a low-cost indoor assistive robot that follows a user and carries items in a basket mounted on the robot. One global factor influencing our design is the increasing aging population in many countries, which creates demand for assistive technologies that help elderly individuals maintain independence. To address this need, we specifically designed the system around widely available and relatively inexpensive components such as a Raspberry Pi for computation, a camera for person detection using YOLO, and a differential-drive robot base. This hardware choice keeps the system affordable and avoids dependence on specialized infrastructure such as cloud computing or expensive sensors. As a result, the solution can be deployed in typical homes across different regions rather than only in well-resourced environments.

Part B: Cultural factors also influenced our design decisions, particularly the way the robot interacts with the user. In many communities, elderly individuals prefer to remain independent in daily activities while still receiving subtle assistance. Our SafeFollow robot supports this by automatically following the user and allowing them to easily access items stored in the robot’s basket. We also specified the basket height to be approximately one meter so that elderly users can comfortably reach items without bending down. This design consideration reflects the goal of maintaining dignity and independence while minimizing physical strain, and it avoids requiring users to learn complicated interfaces or wear additional devices.

Part C: Environmental factors were considered in how the robot navigates and operates inside typical household environments. The system combines camera-based person detection with ultrasonic sensors for obstacle detection so that the robot can safely move around furniture and other obstacles commonly found in homes. The design focuses on indoor operation on flat surfaces such as kitchens and living rooms, which reduces mechanical complexity and energy consumption compared to outdoor robotic platforms. By using lightweight hardware and an embedded computing platform, the robot operates with relatively low power requirements while still maintaining real-time perception and safe navigation within residential spaces.