Risks:
One major risk we’ve come across recently is that of a mix-up occurring during the shipping or ordering of items we order from the course staff. This week, instead of receiving the unipolar motor driver that was expected, we got an audio controller PCB from OSHPark. After a few days of inquiries, it was found that the PCB we received was in fact associated with another team’s design, and the course staff decided to re-order the board design. As a contingency for the delay caused by this particular mix-up, it was decided to order a set of darlington transistor arrays from Sparkfun to serve as a potential (if less effective) replacement for the PCB. As a contingency for future mix-ups, we intend to investigate alternatives to required components that can be physically picked up at a store by the team member responsible for assembling our project hardware.
System Updates:
Our previous design made use of an external touch enabled display to provide user interfacing with our raspi. However, in an attempt to reduce project complexity as well as to provide a contingency in the case that the raspi is not powerful enough to both compute image-based compensation on top of a GUI and touch screen feedback we will be altering the design. In our new altered design we will be emplogin a standard user-end notebook as the system for our GUI. This notebook will then communicate with the rpi via usart interfacing (alternatively via ethernet connection) and will provide the raspi with necessary user feedback and vice versa.
The above Gantt chart reflects the decision to move away from the usage of an external display to interface with users. Notably, the task labeled “User Interface Specification” has been struck through, indicating that it is no longer relevant for the project.