Our biggest risk at this point is whether our software end will be able to mesh well with our hardware design. We have spent a significant portion of our past few weeks focusing on the hardware aspects that we weren’t able to expand thoroughly enough on the software portion of our project, a point our professor kindly pointed out to us. Currently, our software lead is focusing on expanding on the software mapping that was done in the design presentation but left out in the paper so that we have a clearer idea. There has also been more brainstorming and ideas presented during our meeting so that we have a much more clear/solid plan for how to tackle the wireless connection between the app and the hardware/device by using WiFi + MQTT. We will continue to communicate after hardware is completed with inner-communications and try to start early (so a bit before the interim demo, we should be trying to connect our separate but working systems together so we can deal with bugs earlier than later).
No huge changes were made, except for the hardware end- instead of piling all the signals control to one microcontroller, some signals will be handled wirelessly from the other microcontroller by adding on the initial packet that originally only contained the counter/servo information. This would make it easier to debug if we divide between the two so that we won’t be creating an overly complex hardware design system on just one microcontroller. No costs will be incurred due to this change, though.
No changes have occurred to the overall schedule, except we will individually will be working on getting done with a prototype of our respective areas by the end of the week so we can start debugging or helping others who are more behind.