Sprint 3 was a flurry of getting all our individual components integrated and tested. Here's what we accomplished sub-system wise during this sprint!
In sprint 3, our team mounted the hand sanitizer dispenser, created an electronics cover, and 3D printed a sensor mount. In order to mount the hand sanitizer dispenser, we created two L-brackets that went inside the center hole of our chassis. Then, a tall block of wood was screwed into both of the L-brackets to make the sensor mount very rigid, so it wouldn't need PID control. Then, we screwed mounting holes into the mount and the dispenser and attached the hand sanitizer dispenser with screws. For the electronics cover, we used a large plastic dome lid to protect our electronics from the hand sanitizer. Finally, our IR sensor was 3D printed and then mounted to the top of the hand sanitizer dispenser by creating mounting holes in the dispenser and screwing the sensor mount in.
One of the main problems coming out of this sprint is that our electronics are exposed so if hand sanitizer doesn't make it into the hand of the person this could cause electrical problems. Another problem that occurred was that the hand sanitizer dispenser we bought broke as it would not supply power to the motor anymore. Finally, our tactile switches were hard to trigger throughout this sprint as oftentimes the robot would get stuck when pressed on walls.
The next steps for the mechanical portion were to mount the cover for electronics. Another goal is to find a hand sanitizer dispenser that we could mount or replace the PCB to the one that broke. Finally, we needed to find a way to mount the tactile switches so they can be triggered easily. A good way to do this might be to mount a plate over the tactile switches so whenever the plate was pressed it would trigger the tactile switches.
Implement IR sensor for robot movement stopping functionality, and add more tactile switches (14 in total) with more intentionality on placement around robot’s perimeters towards the front and back such that a switch would be pressed in almost any instance it encounters an obstacle.
Towards the end of this last sprint, when we wanted to test the fully integrated system with the filled sanitizer dispenser that was mounted on the chassis, the sanitizer did not dispense. We probed different areas of the dispenser electronics to see where the issue was occurring - the battery attachment, the hand sensor signal power, and the dispenser motor power. The issue was with the latter. We realized that the motor used to dispense sanitizer from the dispenser was not receiving any power from the PCB it was connected to. It was functional earlier on in the project, so a possibility is that it may have burned out. This led us to purchase a replacement sanitizer dispenser.
In the vein of achieving a fully cable-less robot, we unplugged the Arduino on the robot from the computer after uploading the code. However when we did so, the Arduino did not receive enough power, so we had to provide it with an extra 12V battery pack to power it.
Sanibot, a four wheeled robot, moved forward until an obstruction was detected. The robot detected an obstruction when a tactile switch was pressed.
Once we were able to detect when tactile switches were pressed, we tested our code from sprint 2 to alter the behavior of Sanibot based on the situation it faced.
Our new debouncing technique works as follows. We begin by setting a debounce delay constant, in this case, 50 milliseconds. Then, we check if the tactile switch has been pressed. If the reading of the switch has changed since the last reading, reset the debounce timer (measures the time since the switch change was detected). When the debounce timer exceeds the debounce delay constant, if the reading of the switch has not changed since the timer began, we set the last reading variable to this reading. Otherwise, we assume that the reading was caused due to noise and we ignore it.
The key issue in this sprint (and in sprint 2) was that even though each individual case delivered the commands to the robot as expected when we tested one case at a time, when the tactile switches were pressed, the robot did not detect these presses most of the times and instead changed cases in a cyclic fashion to alter the robot behavior. This was occurring because our code relied on one 100 millisecond delay time frame to detect tactile switch presses. This meant that the switch had to be pressed in the exact same timeframe as the delay was occurring in the loop, otherwise the switch press would not be detected. After consulting the professors and course assistants, we approached the switch press detection using a more robust debouncing technique.
Our original plan was to implement PID control to the software components because given the top-heavy nature of our design and the strength of our wheel motors, we wanted to use the code to make the robot movement smooth and prevent the robot from toppling. However, as we progressed through our sprints, we realized that our mechanical components were sturdy enough to support our design and our current code was able to provide smooth movement of the robot. Thus, we did not need to implement PID control.