Team Status Report 04/27/2024

There are no more major risks as all that is left is to add small changes to the website and internal software system. We did add new batteries just in case during the demo we needed to swap them out for more battery life. The batteries cost about $80 and we had the budget to spare. We shouldn’t incur any more costs. Schedule has not changed.

ADDITIONAL PROMPT:

Starting with the hardware unit testing, we tested out the body rotation and card dispensing first separately. We had the internal gear system as well as the axle ready, with a platform on top. The rest of the system was initially replaced with a comparable amount of weight on top of the platform to check if the stepper motor we chose was able to rotate a system up to 8 pounds. Once this was confirmed, we tested out the card dispenser. This took a lot of iterations to come to the final design. Throughout multiple iterations, the design of the slit that lets the card out has changed in shape as well as size that minimizes cards being stuck as well as 2 cards being dispensed at the same time. Toward the end of testing, we changed it so that the front of the dispenser is separable, making it easy to iterate multiple times. One major change was also changing the material around the rollers from o-rings to rubber bands. Rubber bands have a lot larger surface area touching the cards so they grab the cards more easily. On top of these, while we were able to get a good card dispensing accuracy, we noticed it might be better to add an IR sensor to detect whether a card is dispensed or not automatically. Adding self correction with the IR sensor basically made the failure rate very low.

We worked on some integration while unit testing the separate hardware as well. We connected the UNO and RPI using serial and made sure we could send a command from the RPI to the UNO and move the motors for rotation and dispensing, and everything worked out pretty well.

On the software side, we didn’t really have a lot of unit tests. Our testing methodology mainly worked around logging events in the system and then analyzing the logs when things went wrong. When moving to the asynchronous execution model, there were alot of bugs surrounding synchronization and deadlocking. We had to be very precise to avoid recreating the issue of blocking on io in the main thread. For our design requirements, we measured latency using the log files to find the time deltas between initiating and completing actions such as website updates and classification. Logging truly was a very versatile and useful tool for us as it allowed us to introspect how all of the asynchronous events were interacting with each other.

 

For the image classification portion of the project, we mainly operated on the accuracy results from our test and validation datasets. One key design change was to artificially generate new images (by rotating, scaling, changing saturation) AFTER splitting up the dataset. Otherwise, the images would be too similar across the datasets, and there would be very little difference between testing and training datasets. We also found that fine-tuning ResNet-18 worked significantly better than designing our own architecture.

Leave a Reply

Your email address will not be published. Required fields are marked *