What are the most significant risks that could jeopardize the success of the project? How are these risks being managed? What contingency plans are ready?
The most significant risk that could jeopardize the success of the project is the reliability of the communication between the RPi Picos and the central RPi. A problem we see right now is that in the uploading words stage when setting up a new game, sometimes a block or multiple blocks does not ACK back to the RPi and instead just echos the word that was sent to it, which prevents us from even playing the game at all since that block(s) is out of commission. We already tested the pogo pin connections to make sure that these are fine, and we also tested each block individually by wiring it directly to the RPi, all of which seemed to work. However, there is a chance that some internal connections inside the blocks have degraded with all our manhandling during testing, so we plan to double check the pogo pin connections and direct wiring tests for the problematic blocks. If the hardware is the issue, we will re-solder the pogo pins directly to the Picos with wires, instead of using female header pins. If the issue is not a hardware issue, then we will examine the code that manages the receiving of ACKs and restructure it to be able to receive messages more reliably.
On the website end, we are facing a problem where SocketIO signals from the backend are not being received properly by the frontend, so we end up with indeterministic behavior where sometimes we automatically transition from the loading page to the gameplay page, but sometimes get stuck on uploading even though everything is ready to begin gameplay. We are currently debugging to see if this is an implementation issue or a CORS issue, but our contingency plan is to implement a button on the frontend that appears once the post request to the backend has returned successfully. That way, the user can transition manually to the next page in the case that the socket signals don’t work out.
Were any changes made to the existing design of the system (requirements, block diagram, system spec, etc)? Why was this change necessary, what costs does the change incur, and how will these costs be mitigated going forward? Provide an updated schedule if changes have occurred.
There were no changes made to the existing design of the system, except that we used a different set of UART0 pins (that work) on the Picos that weren’t working with the initial UART0 pins we chose (perhaps due to bad soldering of the female header pins). This change does not affect communication between the RPi and the Picos though.
Our schedule remains the same. We have completed our MVP (although it’s a little ugly), and now we will move on to testing for reliability in the various subsystems and their interactions.
This is also the place to put some photos of your progress or to brag about a component you got working
We finished prototyping a basic grid and completed all the circuitry for it.
We were able to upload words to all 8 blocks in 1 function call, using our “upload_words” embedded controller function.
We were able to test the button submission on the grid for both rows, and found that it works successfully with the web app. We just have to modify the embedded controller logic a bit to take care of button debouncing, so that the web app doesn’t get triggered multiple times for 1 button press.
We were able to get both row LCDs working on the grid.
