3/14 + 3/22 Zehong Lin progress report for week of spring break and week after spring break
After consulting one of my MechE friend, we finalized on the idea of mounting a circular wooden platform over the Roomba. We arrived at this design because the top surface of the original Roomba is not smooth and it is hard to attach anything onto it. The wooden platform will be mounted on using 70mm threaded standoffs and serve as a platform for all other electronic components: the raspberry Pi 3, the range sensor, and the load sensor. Having the wooden platform also makes it easier to attach the basket. Over the spring break before campus closed down, I went to work on some physical portions of our project mentioned above:
- Using band saw at TechSpark wood shop, I cut a 10 inch radius circular wooden disk out of 1/2′ plywood.
- I 3D printed 70mm threaded standoffs and their corresponding screws
- Realized the printed screws do not fit into the threaded standoffs. So in the interest of time, instead of reprinting, I scavenged 12mm M2.5 screws from TechSpark.
- Drilled holes on the top cover of Roomba and attached the standoffs.
- Realized TechSpark does not have longer M2.5 screw and 12mm is too short for the 1/2′ disc. So I Planned on using holesaw to thin the area above mounting holes by about 50%. I did not get to this part because of the virus outbreak.
- Also found a micro-SD card at home for the raspberry Pi.
After the virus outbreak, our team came together to discuss how we can re-scope out project. After re-scoping, I am in charge of experimenting with 2 different algorithms for path planning: 1) an item-to-item approach that uses A* to find the shortest path between each item on the list; and 2) a dynamic programming approach that treats the path planning as solving a Traveling Salesman Problem. I first did research on what is a reasonable run time upper limit for the path planning algorithm before it starts to negatively impact the user experience. I then started thinking about what data structure to use to represent the map so that both algorithms can use the same map representation. This is important because re-planning is where there is a tighter requirement on run time. If the algorithm had to be switched during re-planning, we do not want to have to reconstruct the store map, which can take a long time. Ideally in the real world, store map should only need to be constructed once.