This week, we focused on testing the fully wireless version of TrashDash as part of our final validation phase. While the system remains functionally integrated, we identified power consumption as a major issue, particularly due to the high energy demand of running ML model inference on the onboard hardware. This currently limits stable untethered operation and is our primary bottleneck moving forward. We are exploring potential optimizations and hardware solutions to address this constraint while maintaining system performance. In parallel, I am taking full responsibility for designing and finalizing the demo poster to clearly present our system, results, and key contributions for the final demonstration.
Tag: Status Report
Team Status Report for 4/25
System Progress
This week we completed our final presentation and transitioned into the final testing and validation phase of TrashDash. The system is fully integrated, and we have verified that core functionalities including voice activation, gesture recognition, motor control, and obstacle avoidance—work together in a complete pipeline. We are now focusing on robustness and demo readiness. I am primarily responsible for the demo poster and edge-case testing to ensure reliability under non-ideal conditions.
System Design & Changes
The overall system architecture remains unchanged, but we identified a key limitation in the power subsystem. The current onboard battery cannot reliably support simultaneous operation of the camera and ToF sensors, preventing fully untethered operation. In response, we are exploring higher-capacity battery options and software-level optimizations such as reducing sensor load and managing duty cycles. A fallback option using external power is also prepared for demo stability.
Testing & Verification
We conducted both unit testing and system-level testing:
- Unit Tests
- Voice Module: Verified wake word and stop command detection across varying distances and noise levels (met latency and accuracy targets in controlled settings).
- Gesture Recognition: Tested detection of thumbs-up (move) and fist (stop) under different lighting conditions; performance degrades slightly in low light.
- Motor Subsystem: Validated movement commands (forward, backward, turning, rotation) and confirmed stable response from the motor driver.
- ToF Sensors: Tested obstacle detection at different distances; confirmed correct triggering of avoidance logic.
- System-Level Tests
- End-to-end pipeline: voice → gesture → motion → obstacle avoidance → stop/resume
- Edge-case scenarios: low lighting, delayed commands, cluttered environments, and continuous operation
Findings & Design Changes
- Power limitation is the main bottleneck → investigating stronger batteries and power optimization.
- Slight degradation in vision performance under low light → considering parameter tuning and controlled demo environment.
- System latency and responsiveness meet requirements under normal conditions → no major redesign needed.
- Added fallback strategies (external power, controlled demo setup) to ensure reliability.
Risk & Mitigation
The primary risk is system instability due to insufficient power during full operation. Mitigation includes upgrading the power supply, optimizing component usage, and preparing a wired fallback for the demo. Additional risks include edge-case failures in perception, which are being addressed through targeted testing and controlled demo conditions.
Next Week’s Plan
Next week, we will finalize testing, stabilize the power system, and complete the demo setup. I will finalize the demo poster and continue edge-case validation. The goal is to deliver a smooth, reliable demonstration that clearly showcases all core features of TrashDash.
Yilu’s Status Report for 4/18
This week, we made significant progress on system integration and hardware assembly. All components were successfully mounted onto the car chassis, resulting in a fully integrated platform. We implemented and validated obstacle avoidance, enabling the system to safely navigate around objects while moving toward the user. In addition, I developed an emergency stop and resume feature, allowing the system to halt immediately when needed and continue operation smoothly. The motor subsystem was thoroughly tested, confirming reliable movement in multiple directions, including forward, backward, lateral shifts, and rotation. Overall, the system is now functioning as a cohesive unit with core mobility and safety features in place.
During this process, I had to quickly learn several new tools and concepts, especially related to ROS2 integration, hardware-software interfacing on Raspberry Pi, and sensor-based navigation logic. I relied heavily on practical learning strategies such as reading official documentation and debugging through trial and error. I also used tutorial videos and example projects to understand system integration patterns. This hands-on, iterative approach was very effective, allowing me to rapidly identify issues and apply solutions directly to our system.
Yilu‘s Status Report for 4/4
This week, our team completed the interim demo, where we showcased the integration of the voice, camera, and motor subsystems, demonstrating that the system can respond to voice commands and trigger movement based on camera input. Since the ToF sensors were not yet mounted, we presented the obstacle detection functionality separately using an Arduino setup for better clarity. In addition to the demo, we ordered additional components including a UPS for the Raspberry Pi and camera mounts to securely attach the camera on top of the trash bin for improved stability.
As we move into the verification and validation phase, I will be focusing on the motor subsystem by testing basic motion commands (forward, backward, lateral movement, and rotation) to ensure correct response to control inputs, as well as evaluating consistency and responsiveness under repeated trials. For verification, I plan to measure latency from command to actuation and compare actual vs. expected movement (e.g., direction accuracy and speed consistency) to ensure the motor controller meets our design requirements. For validation, we will test the fully integrated system by evaluating whether the robot can reliably move toward a detected hand within the required time and accuracy constraints in realistic environments. There were no major changes to the system design, but integration and mounting remain potential risks, which we plan to address through early assembly and incremental testing.
Next week, we will focus on mounting all components onto the chassis and begin implementing the follow-human logic as the next key feature.
Team Status Report for 3/28
System Progress
This week we successfully tested all major subsystems on the Raspberry Pi and achieved initial system integration. The motor driver is fully functional, supporting forward/backward movement, lateral shifting, rotation, and turning. The OAK-D depth camera can reliably detect different hand gestures, and the voice recognition module successfully detects the wake word “hi trashdash.” We integrated the car chassis, camera, and voice module into a working pipeline: after the wake word and confirmation (“throw trash”), the system activates, moves forward upon detecting a thumbs-up gesture, and stops when a fist gesture is recognized. Additionally, preliminary obstacle avoidance logic using ToF sensors has been validated in a simulated setup.
System Design & Changes
There are no major changes to the overall system architecture. We continue to use the Raspberry Pi as the central controller coordinating voice, vision, and motor subsystems. One practical adjustment is prioritizing early integration of gesture-based control (thumbs-up to move, fist to stop) to demonstrate an end-to-end workflow for the interim demo, before fully implementing continuous hand tracking and navigation.
Risk & Mitigation
The main risks currently are hardware integration and system latency. Mounting all components (camera, ToF sensors, and wiring) onto the chassis may introduce instability or connection issues; this will be mitigated through secure mounting and incremental testing after each component is installed. Another risk is latency between voice input, gesture recognition, and motor response, which could affect responsiveness; we plan to optimize processing pipelines and reduce unnecessary computation. Finally, obstacle avoidance is not fully validated yet since ToF sensors are not mounted; we will mitigate this by conducting real-world testing once installation is complete and refining thresholds for reliable detection.
Next Week’s Plan
Next week, we will focus on physically mounting and securing all components onto the chassis and ensuring stable system operation. After full hardware integration, we will implement and test hand-following behavior so the robot can continuously track and move toward the user’s hand instead of only responding to discrete gestures. In parallel, we will prepare for the interim demo: Siying will cover the introduction and voice module, Qimeng will present the camera and ToF sensing, and Yilu will present the motor system and outline plans for the next three weeks.
Yilu’s Status Report for 3/28
This week I made some solid progress on the car subsystem. At the beginning, we encountered several setup issues with the Raspberry Pi since none of us had prior experience, but we were able to resolve these within a day through troubleshooting and documentation. On Thursday, Aislinn and I tested the chassis and confirmed that the motor control driver is working reliably. We also began initial integration of the voice wake-up system with the camera and motor control, establishing a basic pipeline for interaction.
For the upcoming interim demo, I will be responsible for presenting our progress on the motor system and outlining our next steps, including further integration and system-level testing.
Yilu’s Status Report for 3/21
This week, I assembled the car chassis and researched how to interface it with both the Raspberry Pi and STM32 board. I also set up the development environment and wrote some preliminary motor control code to test basic functionality. In addition, our team attended an ethics lecture, which prompted us to think more carefully about potential issues such as user safety, privacy, and reliability. For example, since our system involves autonomous movement and sensing, we need to ensure it avoids collisions reliably and does not unintentionally collect sensitive data from users or their surroundings.
Overall, there are no major blockers at the moment, but we are slightly tight on time with the interim demo approaching. The car chassis arrived later than expected, which caused a small delay in hardware testing. To stay on track, we plan to increase our workload next week and focus on accelerating integration and testing progress.
Yilu’s Status Report for 3/14
This week we made progress on the hardware side of the project. The car chassis and the voice recognition module arrived, which is such a relief as we were worried that it’s not going to arrive on time. I spent time assembling the car chassis platform and bringing up the motors to verify that they work properly. I tested the basic motor functionality and confirmed that the chassis and motors operate as expected, which will allow us to start integrating the control system in the next stage. In addition, I worked on the ethics assignment, which made me reflect on the broader impact of TrashDash, especially in terms of user safety, reliability, and how autonomous devices interact with people in everyday environments. Overall, the project is still on schedule and we are ready to move toward further hardware and software integration.
Team Status Report for 3/7
System Progress
This week we completed the design presentation and finalized the design report for the TrashDash project. Siying delivered the design presentation, which went really well! The team collaborated to complete different sections of the report based on our responsibilities. Yilu wrote the Abstract and Introduction, Project Management, Ethical Issues, and Related Work, and also worked on the Mobility subsystem implementation, which includes the Raspberry Pi control, motor controller design, and overall software integration for the movement system. Siying was responsible for the Use-case Requirements, Design Requirements, Voice subsystem, and Test, Verification, and Validation sections. Qimeng contributed to the Architecture / Principle of Operation, Design Trade Studies, and Summary sections. The System Implementation section was written collaboratively, covering the main subsystems: the vision subsystem (hand detection and localization), the voice subsystem, and the mobility subsystem.
System Design
No significant changes were made to the existing system design, requirements, block diagram, or specifications this week. We confirmed that the Raspberry Pi will serve as the main computation unit to coordinate all subsystems in TrashDash, while the STM32 microcontroller will act as a backup controller for low-level motor control if needed. This decision was made because the Raspberry Pi simplifies integration of vision and voice models, while STM32 provides a reliable fallback option for motor control and hardware interfacing.
Risk and Mitigation
One potential risk for the TrashDash project is delays in hardware delivery, particularly the motor platform and other components required for testing. If these parts arrive later than expected, it may delay system bring-up and integration. To mitigate this risk, we are preparing the software components in advance, such as developing the motor control driver and reviewing the chassis documentation, so that testing can begin immediately once the hardware arrives.
Another risk is related to system reliability and integration, including potential issues with voice recognition in noisy environments and coordination between the vision, voice, and mobility subsystems. To mitigate this, we plan to test each subsystem independently before integration and evaluate the voice module under different noise conditions. Incremental testing and clearly defined interfaces between modules will help reduce integration issues and improve overall system stability.
Plan for Next Week
Next week we plan to begin initial hardware testing. We will test the voice recognition module to evaluate its usability and responsiveness for triggering TrashDash. In addition, we will bring up the motor platform once it arrives and test the custom motor controller driver to verify that the motors can be properly controlled through our system. These tests will help us validate key subsystems before moving forward with full system integration.
Part A (Yilu): TrashDash also needs to be considered in the context of global factors, particularly accessibility, hygiene practices, and differences in living environments. While the project is designed for university dorm rooms, similar needs exist in many settings worldwide where convenience and sanitation are important, such as small apartments, elderly care facilities, and shared living spaces. In regions where waste management and hygiene practices are critical to public health, technologies that make trash disposal easier may help reduce littering and improve cleanliness. At the same time, the system assumes access to certain resources such as reliable electricity, voice interaction in supported languages, and familiarity with technology, which may limit usability in some global contexts. Considering these factors is important to ensure that systems like TrashDash are designed with broader accessibility in mind, including support for different languages, varying noise environments, and users with different levels of technological experience.
Part B (Siying): Cultural factors are also considered in the design of this system. In many student communities, especially in shared dormitory environments, maintaining cleanliness and respecting shared spaces are important social expectations. TrashDash supports these values by making proper waste disposal easier and more accessible. In addition, the system uses natural interaction methods such as voice commands and hand gestures, which accommodate different language preferences and levels of technological familiarity among users. The design also considers rules of behavior in indoor environments, such as minimizing noise and ensuring safe navigation around people and furniture. By aligning with these cultural expectations, TrashDash aims to provide a practical solution that fits naturally into everyday student life.
Part C (Qimeng): Environmental factors are also important to consider in the design of TrashDash. The system aims to encourage more consistent and convenient waste disposal, which can help reduce litter and improve cleanliness in indoor living environments such as dormitories or small apartments. By making it easier for users to throw away trash without leaving their workspace, TrashDash may help prevent waste from accumulating in shared spaces and reduce potential hygiene issues. In addition, the design considers energy efficiency and hardware usage. The system uses low-power embedded components such as a Raspberry Pi and microcontroller-based motor control, and it only activates mobility when necessary, which helps limit unnecessary power consumption. The project also relies on commercially available electronic components and a reusable robotic platform, which reduces the need for custom hardware manufacturing and helps minimize material waste. Considering these environmental aspects helps ensure that TrashDash not only improves convenience for users but also aligns with broader goals of sustainability and responsible use of resources.
Yilu’s Status Report for 3/7
This week we completed the design presentation and finalized the design report for the project. I contributed to several sections of the report, including the abstract, introduction, motor system implementation, project management, ethical issues, and related work. Writing these sections involved organizing our project goals, explaining the technical design of the motor platform, and documenting how the team plans to manage development and address potential ethical considerations.
In addition, I began writing a preliminary motor control driver for the motor platform so that testing can start immediately once the chassis arrives. Preparing the driver in advance should make it easier to bring up the motors and begin hardware testing.
One concern at the moment is the arrival time of the motor platform. Although it has already been ordered, I have not yet received a notification from the ECE receiving desk confirming that the items have arrived. Once the motor platform is delivered, I plan to proceed with hardware setup and begin testing the motor control system.