Progress Log Week 2/3
- Sep 10, 2025
- 3 min read
Updated: Sep 17, 2025
Dates: 08/27/25 - 09/09/25
During this portion of the semester, the team and Dr. Ejaz skipped a week, and therefore I am culminating two weeks of work into a single larger blog post.
Last week, I had the following content prepared:
An issue I have been having with the prototype is the stability of connections and other hardware architecture. I attempted at first to minimize the amount of "permanent" connections were being formed, namely by avoiding soldering as much as possible. To increase the stability of the prototype, I decided to change that. To the left is an image of a wire soldered directly to VBUS and GND of the Raspberry Pi Pico 2 (note that the GND wire was incorrectly soldered to 3V3 instead of GND, this was later fixed).
This includes more than just the Pico, the stranded wire connections for each of the IR sensors were also incredibly unstable when just using F-M Dupont wires, so those also had regular pin wires soldered onto each connection. The updated result of the prototype after Week 3 can be found below. Note there is a single Sensor connected directly to the Pico ADC0, with a motor connected directly to GPIO14 and both to a common VBUS and GND.
There were two issues at the end of this week. First, data intake was incredible unstable. The sensors are rated for between 100cm and 550cm, so anything within that minimum 100cm range causes irregular spikes in the ADC value. Also, This specific Raspberry Pi Pico 2 actually ended up fried, as spikes from the sensor voltage within that minimum range occasionally sent more than 3.3V to the ADC.
For the next week there would be 3 issues/deliverables:
Find a way to smooth out the data coming in from the IR sensors, to better interpret real world data.
Find some method of limiting the amount of voltage the IR sensors can possibly send to the ADC to ensure protection of the board.
Connect a total of three sensor/motor connections to test navigating with 3 axes of proximity detection.
First, the data smoothing. This, to an extent, can be done in the software, but I want to save the brunt of the heavy and robust programming for production, while ensuring "feature creep" does not invade the prototype and a working system can be demonstrated. So, I opted for a form of hardware-based data smoothing. This allows for the prototype scope to be managed, while developing a system that can and will still be used during production.
According to its datasheet, the sensor should output a max of around 2.5V at 100cm, but spikes for out of bounds measurements could peak below the minimum, and above the maximum described. A simple voltage divider with a 10kΩ (top) and 20kΩ (ground) resistor per sensor should ensure this safe operating voltage limit. This mostly solves issue/deliverable 2. There was still a decent amount of variability and "bounce" to the voltage readings, and it turns out that this was likely due to the vibration motors drawing a surge of current that can introduce noise to the main supply rail. So, I added a 0.1µF decoupling capacitor across each motor, mostly solving issue/deliverable 2. Also pictured to the right is an HW-131 (black and yellow module on the far right of the breadboard) which will allow for uploading of any code to the pico, and taking the prototype on the move. This will help in solving issue/deliverable 3, performing the demo.
I also soldered a set of pin headers to the pico 2, to even further increase the stability of the prototype.
Pictured below is the final working prototype for the NAVI. it implements all of the above solutions to allow the team to perform a demo, validating environmental navigation that relies on haptic feedback.
Before showcasing the demo, first a validation of the functioning technology being sent via USB through Thonny:
And finally, I performed a demo of the prototype in my home for functional purposes. The team can record a more "presentable" demo of the prototype for the end of semester presentation if desired.
Demo 1:
Demo 2:
Comments