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/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.

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

This week, I focused primarily on project planning, requirement analysis, and initial hardware preparation. At the beginning of the week, I worked with my teammate to prepare and refine our project proposal, helping to define the technical goals, system architecture, and evaluation metrics. After the proposal presentation, I continued collaborating to clarify design details, especially those related to usability and safety for elderly users.

I then analyzed the use-case requirements in more depth and translated them into concrete technical parameters. In particular, I evaluated what following speed, camera field of view, frame rate, and computational capability would be necessary to reliably track a person indoors. Based on these requirements, I compared available hardware options and helped determine that a Raspberry Pi 5, a USB camera with sufficient resolution and field of view, and a UGV robot base would meet our needs. I reviewed the specifications of these components to ensure they could support real-time YOLO inference and safe obstacle avoidance.

Finally, I worked with my teammate to finalize the list of required materials and submit equipment requests. We are currently slightly behind the original hardware setup schedule, mainly due to the time needed to research appropriate components and the ordering process. However, given the long overall project timeline and the fact that this delay is largely logistical rather than technical, the setup delay is acceptable and should not affect major milestones. For next week, I plan to begin software setup on the Raspberry Pi, start building the vision pipeline, and assist with initial hardware integration once the components arrive.