Weekly Status Reports

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 only significant risk that would jeopardize the success of the project is the connection of the 2nd set of blocks that we created. It seems to intermittently work where sometimes it is really smooth and doesn’t cause problems and at other times it is very difficult for one of the blocks to get an ACK. The plan for mitigation is to do continuous testing and try to isolate the problem first. The hypothesis currently is that it is due to the leveling of the female pogo pins that are on the grid and that once the grid is built, we will have a more stable and flat connection between the block and grid which will help with uploading the words. Another mitigation is to modify our algorithm slightly by potentially bypassing the block that appears to be having a problem and maintain a list of those blocks. It will continue uploading the rest of the blocks and will re-try the blocks that weren’t able to receive the word. If it still fails to do so, we may need user help with resetting the block by displaying on the webapp to tell the user to check the connection of a certain block position on the grid to reposition the block or simply turn it off/on. The other plan is to exponentially increase the delay for an ACK on several subsequent re-tries. This would be the worst case scenario if we are not able to fix the problem.

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.
The changes made to the existing design of the system is the need for a 3D printed part to hold the pogo pin on the grid. We wanted to ensure a very stable connection and for a flush look which is why we wanted to make a holder for the pogo pins. At techspark, the 3D printers are $0.48 per gram and each holder is 1 gram. So $0.48 x 16 = $7.68 which I will round to $8 in case I have to do 1 trial print.

This is also the place to put some photos of your progress or to brag about a component you got working
Since the last update, we were able to get all 16 blocks fabricated to completion which meant laser cutting the blocks, soldering the adapter and batteries, cutting out holes in the battery holder for the charging cable, and we decided on using hot glue to secure down the components in replace of tape which was a bit flimsy. Also we accidentally ordered a surface mount pogo pins instead of the through holes and so there was additional soldering where a total of 6 header pins were added to the surface mounts to provide stability and an electrical connection to jumpers. We had to do this for a set of 8 blocks. We also worked on creating another testbed for the 16 blocks as a proof of concept before we build a grid that is for 16 blocks instead of 8. We noticed that there was a lot of wiring on some mini-breadboards that we had and we felt that it felt bulky and decided to create a perf board to minimize the circuitry instead. As it was kind of late in the semester ordering a PCB may not come in time so perfboard was the best option, we may end up being able to move everything to a PCB towards the end if there is enough time. Also corresponding modifications were made to support all 16 blocks as well as a 1 word away feature on the webapp. Also, the grid CAD was created to plan the cutting of the wood that we purchased, with 16 blocks working we were finally able to create a grid to size and also worked on a 3D printed part pogo pin holder to ensure that everything fits. In addition we tested E2E with the 16 blocks and did some preliminary testing by changing the delay to receive an ACK which allowed us to reduce our total uploading latency from 22 seconds to only 3.2 seconds.
Link to Photos

Additional: Comprehensive update on what tests you have run or are planning to run. In particular how will you analyze anticipated measured results to verify your contribution to the project meets the engineering design requirements or the use case requirements?
Next week is reserved for testing and so we worked on creating a testing plan. So far we have been playing around with the delay values for the uploading_words algorithm and we were able to reduce our upload time. The verification tests that we plan on performing next week is game logic accuracy, weight and size of all 16 blocks, battery life – endurance trials, UART send and receive latency, hint retrieval latency and ability to retrieve all the hints through the Merriam Webster API. For the game logic accuracy, we will take 10 known puzzles and ensure that each will have a 100% correct answer checking when a submission takes place. We will measure and weigh all 16 blocks with a caliber and scale to ensure that it meets the requirement of <4”x4”x4” and <400g. For battery life, there will be 5 endurance trails with the block displays turned on to ensure that the average battery life can last at least 15 minutes for game play. We have currently been simultaneously testing this while we test our actual implementation of our code and the blocks last very long with like a week of gameplay each session being anywhere between 2 – 4 hours. For the UART tests, we will have 10 known words sent and read from each of the picos and ensure that the pico receives and displays the correct word as well as have the upload latency be <400 ms. The last test is for the virtual companion by loading 20 puzzles and looking at the hint retrieval latency as well as accuracy of Merriam Webster API to have that word in the API. We want a 95% retrieval of hints and an average of 3.2 seconds per puzzle. As far as validation testing, we have been performing these such as playing several games subsequently and trying different edge cases to ensure that those are handled properly.
Link to plan

There are a few other tests that we have to look at tradeoffs such as with accuracy and speed as well as a comparison of 8 and 16 blocks. For uploading words we will be varying the delay and recording the latency as a result of that delay value. We will also play around with UART baud rate as well to look at the latency.
We also worked on creating a survey (google form) for user studies so that we have it set up for next week and we can just test with people. We will be recruiting 10 novice NYT Connections players and 10 ESLs to play the game and provide their feed back through the google form. We will have them play a NYT Connections puzzle first through the original mode (online) and then we will have them play Connexus and gather their input / feedback. We would ideally like to see that Connexus outscores NYT Connections by 1 point in each of the main categories that we have: ease of Use, game completion rate, level of enjoyment, and frustration toward game.

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 physical hardware design. The pogo pin connections are sometimes not well aligned because the pogo pins are not level with the grid/block. This is temporarily mitigated by placing cardboard support on the grid beside the pogo pin to provide more support for a block to be placed. A more definite mitigation strategy will be to build a proper grid using wood which we are in the process of doing. The wooden grid structure will hold the pogo pins in place and we have purchased magnets as well to align the blocks to the grid when they are being placed.
• Another risk that could jeopardize the success of the project is the circuitry design. The batteries on the block sometimes turn off after repeated use (more than 1 game) but the DMM detects it to still be 9V. We suspect there might be some inaccuraries in how the battery voltage is being shown and the actual functioning of the battery. This only happens when the battery is running low. To mitigate this, we plan to charge all the batteries to their full capacity before any extended testing instead of relying on the indicator to tell us how much power the battery has left.

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.

• For the grid, we decided to use plywood since it is more sturdy and can better withstand the repeated placement of blocks onto it and the submission button being pressed. We decided to purchase small magnets to be placed on the grid and the blocks for additional alignment as the magnets on the pogo pins might not be strong enough. This was a small amount of cost and did not make a big difference to the budget.

This is also the place to put some photos of your progress or to brag about a component you got working

• This week we reached out MVP! Here are some photos and videos showing the game flow.
• We did a lot of testing and debugging this week to make sure the integration between the webapp and the embedded controller was robust.
• We found out that the pogo pins were sometimes unreliable (as mentioned before) which is due to the levelling issue.
• We also found an edge case where the webapp would crash when the there is a word in the puzzle that is not present in the dictionary. Hence, we added an error checking process.
• We also found that the communication between the Pico and the embedded controller was not very stable against error handling so we added some code for more robust text parsing and error handling. 
• We also managed to get all the LCDs on the block to change color when a correct submission is being made.
• We also debug the button bouncing issue so the number of mistakes the webapp records is accurate now.

• 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
  • Click here for photos and videos
  • 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.