Wuyang Li’s Status Report for 03/07/2026

This week, I finished writing the design proposal with my teammate Xinyu. We each were responsible for some sections, and I particularly worked on the later sections, i.e., testing, project management, summary, related works, etc. I also did some research into how to implement the speed controller, and started to implement it.

Generally, I’m still on schedule, although I haven’t entirely finished the speed controller implementation which should have been done by this week. However, this was mainly due to the spring break, and I still have time tomorrow to complete it.

By next week, I hope to have the entire motor mobility module completed. This includes the basic mobility and the speed controller. I will also try to write some coverage tests to ensure that it works.

Xinyu Li’s Status Report for 03/07/2026

This week I focused on getting the YOLO object detection model running on our Raspberry Pi so that we can start testing the vision component of SafeFollow. I worked on setting up the runtime environment, installing the necessary dependencies, and running initial inference with the camera input. One challenge I encountered was the frame processing rate. Because the Raspberry Pi does not have a dedicated AI accelerator, running YOLO on the CPU can result in very low frame rates, sometimes only a few frames per second, which makes real-time tracking difficult.

To address this, I experimented with reducing the input image resolution and adjusting the camera capture settings to balance accuracy and speed. I also explored using lighter YOLO model variants and optimizing the inference pipeline. These adjustments helped improve the processing speed somewhat, although performance tuning is still ongoing. Next week, I plan to continue optimizing the pipeline and integrate the detection output with our person tracking module.

Xinyu Li’s Status Report for 02/21/2026

This week, I focused on improving our multi-person tracking design. Previously, our system relied on a single speculative guessor based mainly on motion speed and past positions, which was not robust when multiple people were present. I worked on extending this approach by designing additional guessors, such as color based tracking, and integrating them under a meta selector that can dynamically choose the most reliable prediction. This design improves robustness against occlusion and ambiguity.

I also continued coordinating with my teammate on system integration planning. We developed the design review presentation slides, and I presented themin class. My progress remains on schedule, and next week I plan to begin implementing and testing the meta selection framework.

Team Status Report for 02/21/2026

The most significant risks would be the technical challenges we will face in the following month or so. In the next month, we will work on motor mobility and vision pipeline, which are two core functionalities of our product. We expect both to be challenging, especially the vision pipeline for person detection. We had a criterion of mAP@0.5 > 90% for person detection. If it fails, we have a mitigation plan of doing resolution tuning. Of course, this comes with increasing workload, so we will also need to manage our time carefully if we need to execute this mitigation plan.

We didn’t make any change this week to the existing design, because we already adjusted it last week when we considered our overall design for the design presentation. Based on the feedback we receive for our design presentation, we will then decide if any further change needs to be made. Our schedule also remains the same as we are currently on schedule.

Wuyang Li’s Status Report for 02/21/2026

This week, I completed the design presentation slides with Xinyu and wrote peer reviews for other groups. I also received the ultrasonic sensors we bought on Amazon, and ensured that they can be connected to our existing hardware setup. However, I decided to leave them separate for now, as we probably will test individual functions of person tracking and obstacle avoidance. I also started to research how to implement the motor controller, and got started on it myself. Below shows some progress I made this week.

My progress is currently on schedule. Next week, I will continue to work on the motor controller, and hopefully I can get the basic motion working. I can try to do some local tests to ensure its functionality.

Team Status Report for 02/14/2026

Most significant risks and mitigation plans: The most significant technical risk is failing to meet our real-time requirements, especially sustaining ≥15 FPS while running YOLOv8 on Raspberry Pi and achieving ≤200 ms stop response when an obstacle is detected. If inference latency is too high, it could degrade tracking stability and distance control. We are managing this risk by benchmarking early, selecting appropriate YOLOv8 model sizes, and optimizing preprocessing resolution before full system integration. Another risk is integration complexity between hardware and software, particularly reliable GPIO timing for ultrasonic sensors and stable PWM motor control under load. To mitigate this, we are testing subsystems independently (vision-only loop, motor control test, ultrasonic timing test) before merging them. As contingency plans, if the full YOLOv8 model cannot sustain target FPS, we will switch to a smaller variant or reduce input resolution; if ultrasonic timing proves unstable, we can simplify the safety logic to a conservative stop threshold and prioritize fail-safe behavior over precision.

Design changes and rationale: We refined our system block diagram to explicitly include physical interfaces (USB, GPIO, PWM + DIR) and restructured the internal Raspberry Pi pipeline to ensure strictly downstream signal flow with a single safety override merge point. This change was necessary to remove ambiguous or incorrect feedback paths and to better align the architecture with our quantitative requirements. The cost of this change is additional time spent redesigning diagrams and revisiting control flow assumptions, but it reduces long-term integration risk and improves clarity for the design review. No fundamental performance requirements were altered; rather, the architecture was clarified to better justify them.

Updated schedule: No major milestone deadlines have shifted, but we have reordered internal tasks to prioritize early benchmarking of the vision pipeline before full motor integration. This allows us to validate the ≥15 FPS constraint sooner and adjust model size or resolution if needed. Hardware integration will proceed in parallel, with ultrasonic sensors incorporated immediately upon arrival. Overall, we remain aligned with the semester schedule.

Progress highlights: This week, we finalized a clean interface-included architecture diagram and completed a detailed review of YOLOv8’s architecture and deployment feasibility on Raspberry Pi. We also prepared the updated design presentation slides reflecting the corrected block diagram and clarified safety path. These artifacts demonstrate measurable technical progress beyond planning and position us well for the upcoming design review.

This week specific items: 

Part A was written by Xinyu Li. Part B was written by Wuyang Li. Part C was written by both of us.

Part A: Our system improves safety and well-being by providing an indoor mobile assistant that follows an elderly user and carries items, reducing physical strain and fall risk. The robot enforces a maximum speed limit and includes a dedicated obstacle-detection stop mechanism to prevent collisions. All sensing and control are processed locally, ensuring predictable behavior and minimizing unexpected hazards. These design choices directly support user safety, physiological health, and independent daily living.

Part B: Social considerations include operation in shared home environments and interaction around multiple people. The system is designed to reliably track the intended user while avoiding disruptive behavior in multi-person settings. By performing computation locally rather than relying on cloud processing, we also reduce privacy concerns, which improves social acceptance. The robot’s predictable motion and non-intrusive behavior are intended to support comfortable integration into everyday household life.

Part C: Economically, the system uses widely available and cost-effective components such as a Raspberry Pi, USB camera, and ultrasonic sensors, helping control production costs. We rely on open-source software to avoid licensing expenses and reduce long-term maintenance barriers. In addition, the design does not depend heavily on complex or fragile global supply chains; the hardware components are standardized and can be sourced or manufactured domestically, improving resilience and scalability. By balancing performance with affordability and supply stability, the system aims to be economically realistic for assistive applications.

Xinyu Li’s Status Report for 02/14/2026

What I personally accomplished this week on the project: I focused on validating our architecture and proposal numbers with real interfaces and a clean internal pipeline. I mapped all hardware interfaces (USB camera to Raspberry Pi, ultrasonic TRIG/ECHO to GPIO, PWM + direction to motor driver, and power to the base) and corrected the Raspberry Pi internal flow to be strictly downstream (capture → preprocessing → YOLOv8 → detections → tracking → distance/bearing → controller → safety gate → motor commands). The following is our design’s architecture with modules and interfaces.

I also analyzed whether our quantitative targets (≥15 FPS, ≤200 ms stop under 30 cm, ≤1 m/s speed, and 1.25 m ± 0.25 m following distance) are technically plausible given compute latency and signal paths. In addition, I studied YOLOv8’s architecture and why it is suitable for real-time indoor person detection, and I learned how to implement and structure its inference loop on Raspberry Pi.

 

Is my progress on schedule or behind: I am on schedule for my assigned vision and benchmarking tasks. This week reduced architectural risk by grounding our design in concrete interfaces and confirming that our stated requirements align with subsystem responsibilities. I now have concrete artifacts (architecture diagram with interfaces and YOLOv8 architecture reference) ready to include as evidence in the status report and website.

What deliverables do I hope to complete in the next week: I will finalize a clean architecture diagram with correct signal flow and a single safety override merge point, implement a minimal YOLOv8 vision loop on Raspberry Pi and log sustained FPS to validate the ≥15 FPS target, and integrate a lightweight tracking layer so the output becomes a stable target state for the controller.

Wuyang Li’s Status Report for 02/14/2026

This week, I worked with Xinyu to finish ordering the last item we need for our project that cannot be found at ECE inventory — the ultrasonic sensors. We also received the items we ordered from the ECE inventory. Then, I did some research for the hardware setup requirements as I am responsible for hardware setup, and hopefully I will be able to finish this step by this weekend. I also read through the complete feedback we received for our proposal presentation, and worked with Xinyu to address those questions, and hopefully we can address those questions in our design presentation. I also started making the design presentation slides, which will hopefully be done by tomorrow.

Generally, we are on progress, but depending on if I can finish the hardware setup task tomorrow. We still haven’t received the ultrasonic sensors so the hardware setup cannot be fully done, but it will be easy to attach the sensors to our existing setup once we get them. Below is a picture of my research showing how to connect them.

Raspberry Pi - Ultrasonic Sensor | Raspberry Pi Tutorial

Next week, we will finish our design presentation, software and hardware setup, and hopefully I will finish motor integration according to our schedule. Also, I should incorporate the ultrasonic sensors into my existing hardware setup.

Team Status Report for 02/07/2026

We think the most significant risk is our time management. According to our original schedule, we should have finished all the setup by this week, but since we need to order materials first, we couldn’t catch up our original schedule. Therefore, this would result in cutting the time we have for later tasks, most likely testing. However, testing is crucial to ensure the functionality of our product, so this is something we should be careful of, trying to leave substantial testing time even though we are currently behind our schedule. We currently decide to make the change of cutting one week of testing time, leaving two weeks for it, but if we fall further behind, we should aim for getting previous things done faster instead of further cutting the testing time.

In addition to schedule concerns, another important risk is system performance and reliability once the hardware arrives. Our project depends on real-time person detection and stable motion control on a Raspberry Pi, which may be computationally constrained. To manage this risk, we have already analyzed camera requirements and processing needs in advance, and we plan to begin early benchmarking as soon as setup is complete. If performance proves insufficient, we are prepared to optimize the vision pipeline or simplify the tracking algorithm as a contingency.

We presented our proposal on Monday, and received some feedback about our product. Based on the feedback, we decide that our current technical design should be able to work for the most part, but we make a minor change where we want to further specify the height of the basket on our SafeFollow robot to be around 1m, so that it is convenient for elderly to grab items from it. The cost remains the same despite this change, as there’s not really any structural change to it or any additional items required.

Our updated schedule:

Wuyang Li’s Status Report for 02/07/2026

In the beginning of the week, I helped to complete the team proposal presentation, particularly focusing on the use case, use case requirement, and schedule on my end. Then, I presented the proposal on Monday as a representative of the team. Later on, based on the feedback, I worked with Xinyu to finalize some details about our project such as making sure our basket is at a height that can be conveniently grabbed by the elderly, who is our main group of target audience and who may struggle to bend their body. Then, I started to list out the required materials. I first looked through the ECE inventory to see if there is anything we can make use of, and did some research to see what each item can do. I determined with Xinyu and finally submitted requests for RPi 5, camera, and UGV robot base, which according to research would be useful.

I am currently behind our schedule. According to our schedule, I should have done the hardware setup, but I figured out that clearly we were to ambitious about this, since we need more time to think about what items we need to purchase. To make up for this, I should work with Xinyu early next week to finalize the things we need to purchase that do not appear on ECE inventory, and submit these requests through the form. Then hopefully I can have some time at the end of next week to finish the hardware setup if we can receive them. While I wait for the materials to be received, I can also do some research on how to set up the hardware and be prepared to do so once they arrive. Hopefully, I can finish the hardware setup by next week.