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.