This week, I tested the follow-hand navigation logic that I implemented last week in the gesture controller, which uses the OAK-D Pro’s stereo depth to estimate the user’s distance, calibrates across 15 frames with outlier trimming, and drives the robot forward until the target distance is reached. I also built the lateral-shift obstacle avoidance system: when the front ToF sensor detects an obstacle, the robot stops and shifts sideways until the path clears, then continues shifting for a buffer duration to ensure the full chassis width passes the obstacle. A significant portion of my time was spent debugging ToF hardware issues, including Arduino serial port changes between ttyACM0/ttyACM1 on each reboot, EMI-corrupted serial data during motor operation, and intermittent sensor disconnections. I resolved these by adding strict line-level validation in tof_node that only accepts correctly formatted data with all four labeled fields.
For the final presentation, I was responsible for updating the use-case requirements to be more user-focused based on professor feedback, redesigning the architecture block diagram to reflect our as-built system (including the Arduino for ToF and software I2C for the voice module), writing the complete solution and component tradeoff slides, and working with teammates to compile a comprehensive testing plan with 27 tests mapped to our five use-case requirements.
In terms of new knowledge, I strengthened my Python skills through extensive ROS2 development, learning to structure multi-node systems with publishers, subscribers, and state machines, as well as coordinating nodes across separate processes using topic-based communication. I also deepened my understanding of ROS2 Jazzy specifically, including writing launch files, declaring parameters, and debugging inter-node message flow. On the hardware side, I learned I2C protocol debugging using i2cdetect and i2cget to resolve bus conflicts between the voice module and motor controller, which both shared address 0x34, and learned to read firmware source code to identify correct register addresses when the voice module stopped responding after a reflash. For serial communication, I learned that motor EMI can corrupt USB data and that strict validation is more robust than simple parsing. These were all learned through hands-on debugging, reading ROS2 and DepthAI documentation, and examining vendor-provided source code.