Category: Team 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 most significant risk that could jeopardize the success of the project is the reliability and quality/durability of the pogo pins. We discovered that some of the individual pegs of the male pogo pins become permanently partially depressed (i.e. the spring mechanism degrades and doesn’t push the pogo pin up to full height) perhaps during soldering. This results in a bad connection between the grid and the block no matter how hard we try to align the 2 pogo pins, thereby prohibiting us from playing the game at all since we absolutely need the pogo pins to get that wired connection for our UART communication. To manage this risk, we have a few extra male pogo pins on standby (pre-wired) in case something goes wrong or one of the grid pogo pins degrades. However, we have found that pushing the male pogo pins up from the grid more and pushing the block’s female pogo pin out more can help attain a good enough connection for these defective pins, so our contingency plan if we cannot replace a pogo pin is to rework the grid/block construction slightly to allow these pogo pins to stick out a bit more. For now, it seems like the connections are working pretty well and are relatively stable after we swapped out the bad pogo pins.

 

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?

• Yes, we had to supplement the Merriam-Webster hint retrieval with generated output from Google’s Gemini LLM since Merriam-Webster failed to retrieve definitions for a small percentage of the words in the dataset. This was necessary because there were some games wherein more than 1 word had no hints retrieved at all, which is extremely detrimental to our primary use case of making the game a better experience for novices/ELLs who rely on the hints to gain more background knowledge about specific English words. The cost of this change was in terms of latency. Using Gemini boosted our hint retrieval rate to 100%, and the LLM hints were generally more readable/distinct than the Merriam-Webster ones (i.e. improved quality). However, it is about 15x slower compared to Merriam-Webster. To mitigate this latency cost, we only retrieve hints from Gemini when no definitions or context are fetched from Merriam-Webster. Later on, we decided to pre-generate all the Gemini hints and store them in a local database, so that during program execution we could just read this database instead of making an API call. We then experimented with extending this technique to the whole NYT dataset, pre-generating Gemini hints for all words and storing them in a giant JSON file that we can just read from during program execution. This makes the hint retrieval O(1) and has the added benefit of readability from the LLM output.
• We decided to add sound effects and colors to the web app to draw the user’s attention to it during the answer-checking stage. This was necessary because during user testing, some users would be too focused on the physical blocks during answer checking and wouldn’t look at the screen to see if they were correct, incorrect, or one away. The cost of this change was not much in terms of latency; we just had to write more code.
• We decided to add a “loading” page for the answer checking stage since the latency from button push to transitioning to the appropriate result screen was a bit long, so the user couldn’t tell if their button push was actually registered or not and would sometimes press the button again, resulting in a erroneous double submission. The cost of this change was not much in terms of latency; we just had to write more code.
• We enhanced the “missing block” feature to display on the web app the specific positions of the blocks that are missing or have a bad connection, so that the user can manually fix these before resubmission. This was necessary because the alignment of the pogo pins between the block and grid was quite difficult for users to get on the first try since we had not implemented magnets on the blocks/grid, so if they were misaligned we would have to look ourselves on the backend to see the indices of the bad blocks. The reason we did not implement magnets is because each grid and each block’s pogo pins are slightly different in terms of positioning, so we were having a difficult time coming up with a way to get the magnet placement to be interchangeable between all the blocks and grid positions. The cost of this feature was having to rework the code a bit to relay this information, and in terms of latency we had to query all the blocks in the grid/row before returning to the web app instead of just stopping at the first failure, so the latency was slightly increased. To mitigate this, we decreased the delay from 0.5 to around 0.1-0.3 seconds for the UART querying, which made our UART communications much faster. 
• We want to have our row LCDs be able to “scroll” so in case a category name is too long to fit on the whole row LCD, it doesn’t get cut off and the user can still see it. This is needed since the row LCD is the only way the user can see the category name if they guessed correctly.
• We added a “super hints” feature to help users who were really stuck, even with the provided hints. This super hints feature gives 1 word in each category. We thought this would be necessary to help make Connexus a less frustrating experience for players compared to the original game. 
• We added an “easy mode” feature that is only 8 words and 2 categories. This mode is useful to novice players since it is much easier to win the game this way, and helps the user to get in the right mindset that is needed for the normal game without all the frustration and difficulty of the full 16 word mode.

Provide an updated schedule if changes have occurred.

• All the changes except have been implemented, tested, debugged, and integrated into our product. Thus, the updated schedule just includes us working on potential aesthetic enhancements like 3D printed frames for the block LCDs, a custom housing for our speaker, and neopixels for the blocks.

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

• Please see our photos and videos here.

List all unit tests and overall system test carried out for experimentation of the system. List any findings and design changes made from your analysis of test results and other data obtained from the experimentation.

• Hint retrieval quality test
  • Findings:
    • Merriam-Webster does not retrieve any definitions/contexts for a word 1.57% of the time
    • There are 5.37% of games w/ >1 missing word (“bad” game)
  • Design Changes:
    • Supplement hint retrieval with LLM API calls
    • Supplementing w/ Gemini, we are able to retrieve hints 100% of the time
• Hint retrieval latency test
  • Findings:
    • Merriam-Webster has a latency of 0.11s per word
    • Gemini Flash 2.0 has a latency of 1.5s per word
    • [Merriam-Webster] Average “good” game latency = 1.81 sec
    • [Merriam-Webster + Gemini] Average “bad” game latency = 4.28 sec
    • Average game latency = (1-(33/614))*1.81+(33/614)*4.28 = 1.94 sec
    • We will meet our 3.2 sec latency requirement ~95% of the time
  • Design Changes:
    • We pre-generate all the Gemini hints and store them in our own local database so that we don’t have to make API calls live when the program is running, we can just fetch the hint from our dataset.
• Game logic accuracy test
  • Findings: Answer checking logic was 100% accurate
• User testing
  • Findings:
    • More often than not, some blocks would be disconnected or misaligned, resulting in missing ACKs during UART communication. The user would not be able to see which blocks were being problematic.
    • Users wouldn’t realize the web app is showing the result of their submission and would miss it.
    • The puzzle was sometimes too hard even with hints.
  • Design Changes:
    • Displaying the positions of the missing blocks on the web app.
    • Colors and sounds during answer checking.
    • “Super hints” for each puzzle which gives 1 word in each category.
• Battery Life of Blocks
  • Findings: Each battery lasts around 6 hours of continuous use
• Weight and Size of Blocks
  • Findings:
    • Each block weighs around 181g and is 3.3” x 3.3” x 3.3”
• UART Tradeoffs during upload_words
  • Delay (latency) vs Accuracy
    • Findings: Ideal combination was at 0.2s for total upload latency of 3.2s but 100% accuracy
  • Baud Rate vs Accuracy
    • Findings: 
      • Baud rate > 115,200 are able to received within one try (0.2s delay)
      • Baud rate < 115,200 received within 2 tries (0.4s delay)
• UART Send & Receive
  • Findings: 
    • 100% accuracy
    • 200ms latency on average for each word
• Answer Checking E2E
  • Findings:
    • Average incorrect latency: 0.9419006s
    • Average correct latency: 3.0390748
    • Average latency: 1.9904877s
    • Average accuracy: 97.50%
      • Sometimes accidental double submissions or failed transitions that cause inaccuracies.
      • Sometimes the category display on a row LCD failed.
  • Design changes:
    • Added a “get status” function to every web app page that involves gameplay so that we are guaranteed to transition to win/lose if game end conditions are satisfied no matter what state.
• Word Upload
  • Findings
    • Average latency: 3.231673384s
    • Average accuracy: 97.50%
  • Design changes:
    • Added the position reporting of the missing block to the frontend.

 

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?

Pogo pin defects

• Some of the male pogo pins have slight manufacturing defects of or from soldering wires to the back of it. Some of the pins on the pogo pins are uneven and different height, hence even if the block is level with the grid, the pogo pins will not be well connected between the female pogo pins (on the block) and the male pogo pins (on the grid). This could be the reason why some of the blocks did not ACK back to the RPi during transmission of commands.
• In terms of contingency plan, we have resoldered and swapped out the ones that are uneven on the grid with working ones. We also made sure to test every block with every position on the grid to make sure all possible combinations are working for pogo pins connections.

Sturdiness of the grid

• The grid broke along the joints between two pieces during our testing process. We plan to reinforce it with wood glue again and potentially glue another piece of wood at the connection point between the two pieces of wood to ensure that the connection is secure.
• Circuitry was also a possible point of failure. Since we have to use jumper wires to connect the LCD, buttons and male pogo pins to the RPi, the connectivity might not be the best and we encountered instances of the wires coming loose from the connection, causing malfunctioning hardware components. We have decided to solder the connection between two wires and tape them with electrical tape to reinforce it.

 

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 height of the grid was adjusted and there is more space for the Rpi and circuitry now. This is because the circuitry turned out to be more wire heavy than expected which doesn’t fit entirely under the lid of the grid. This is more of an aesthetic change so no major schedule changes is expected. We still plan to collect all the user testing data this week and have the lid ready by the final demo.

We also changed from a Flask app to a FastAPI app for the backend of the web app. This is because after constructing the final grid and seeing that there were still alignment issues with the pogo pins that caused issues with communications not being received, we decided we wanted to notify the user of specific problematic grid indices so that they can manually adjust the alignment of specific blocks. In order to expose this info to the user, the backend needs to initiate one-way communication with the frontend, which requires the use of something like web sockets. However, the asynchronous web socket frameworks available to Flask are incompatible with the RPi’s GPIO library due to monkey patching, so we changed the backend app to a FastAPI app instead, which supports python’s native asyncio web socket package through uvicorn, which is compatible RPi.GPIO. The cost of this change was time and effort in terms of code translating/rewriting, but we were able to get it done this week so there is no change in schedule resulting form this design implementation change.

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

• Completed the production of grid and 16 blocks, together with soldered perf boards which have been tested to be working, combined with the new webapp. We also attached the pogo pins onto each 3d printed holder on the grid and glued them on. We also wired the buttons, LCD and pogo pins to the perf board and tested their functionalities individually. We have the ability to play the whole game without issues now! More photos can be found here.
• Webapp has the added 1 away feature which tells users if their guess is one away from the correct guess.
• Completed latency testing and webapp statistical analysis for hint retrieval on the entire dataset.
• In the process of doing user study on ELLs and novice players this weekend.

 

 

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.

• 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 wired connection between the RPi Pico UART (RX and TX) and GND wires to the Pogo pins. A problem that we are facing right now is that steady and sturdy connection that will allow the RPi Picos on each block to communicate with the RPi 5 via the multiplexer that indexes each grid position. Right now we are doing thorough testing on the soldered connections and we’ll also make sure that no picos were damaged from desolder the old male header pins that we had when we were replacing it with the longer female header pins. The contingency plan is to verify all of our hardware as of right now and if that still doesn’t work we will move to directly soldering the wires to the picos instead of having them connected via header pins.
  • On the website end, we set up the Docker container that would ideally allow for the website to run on the RPi without too much set up. The only risk for that the Docker container potentially does not work and the mitigation for that is just to install all the dependencies locally on the RPi 5. Currently we have the local installed dependencies and a working web app running on the RPi 5.
• 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. There isn’t a change to the updated schedule even though we are slightly behind but we are catching up over this weekend and on Monday as well to help stay on track.

• This is also the place to put some photos of your progress or to brag about a component you got working
  • Press here for photos
  • We finished laser cutting all 8 blocks and designed/CAD a 3D component holder to keep help secure the components in place.
  • We set up the circuitry for 1 full row: 4 blocks with corresponding 4 grid slots, button, and row category LCD.
  • Docker container was created which will simplify set up on RPi 5.

 

A was written by Wen Hui, B was written by Alexis and C was written by Nicole.

Part A: … with consideration of global factors. Global factors are world-wide contexts and factors, rather than only local ones. They do not necessarily represent geographic concerns. Global factors do not need to concern every single person in the entire world. Rather, these factors affect people outside of Pittsburgh, or those who are not in an academic environment, or those who are not technologically savvy, etc.

Connexus has a virtual companion that provides hints to the user during gameplay. This simplifies the process of searching through the internet for American culture references and word definitions themselves. It helps to bridge the gap in this digital game of Connections for users who might not be technologically savvy or well versed with the internet enough to search for hints on their own. Our game is built such that the user can just interact with the physical game without having to open their own digital devices at all, making it inclusive to individuals of different technological skill levels. Additionally, Connexus helps to make Connections more accessible to everyone, even for people who might have low attention spans when interacting with digital devices or those who are more tactile learners. Our game makes Connections a game that stimulates the player’s sense of touch instead of just sense of sight, allowing them to be more engaged and focused in the game.

 

Part B: … with consideration of cultural factors. Cultural factors are encompass the set of beliefs, moral values, traditions, language, and laws (or rules of behavior) held in common by a nation, a community, or other defined group of people.

Connexus was created to address the frustrations of new and non-native players by offering an interactive, educational, and culturally adaptable gameplay experience that NYT Connections currently is lacking. This game is designed for more inclusivity across cultures by bridging language gaps while still maintaining the challenge and fun of the original game especially for English Language Learners (ELLs). It addresses the need for accessibility and engagement by helping players who would struggle with ambiguities in word meanings due to multiple word definitions, cultural references or elitist knowledge assumptions as the creator of the game mentions. This is accomplished with the virtual companion that will retrieve hints from an API and also it supports customizable puzzles that allows for players to come up with their own puzzles either for educational use or for fun. By allowing for a personal twist, you can create different cultural contexts as well which would make the game more inclusive. Also, Connexus provides physical and movable blocks that would shift from a purely digital interface to a more engaging gameplay that would be beneficial for different learning styles.

 

Part C: … with consideration of environmental factors. Environmental factors are concerned with the environment as it relates to living organisms and natural resources.

Connexus doesn’t have too many significant environmental considerations other than the power consumption and physical materials. Each block has an on-board microcontroller and LCD display that needs to be powered by a battery. In order to reduce the amount of waste that our project generates in the form of dead batteries (which could be harmful to the environment if not disposed of correctly), we opted to use rechargeable batteries with an on/off switch. This way, the same batteries could be used over and over again until they run out of recharge cycles, and energy can be conserved when not in use by switching the batteries off. 

Additionally, the RPi that is hosting the web app will be consuming power as it makes API calls to the dictionary API and coordinates the hardware and software components of our system. These processes consume power, so we want to minimize the communication that the web app has to make with external APIs and the hardware subsystems (i.e. blocks). Writing efficient code based on interrupts and requests as opposed to constantly polling for responses is one way we plan to minimize communication. Furthermore, we “prefetch” all the dictionary API calls/responses at the start of the game and then access these locally in the program, as opposed to making repeated API calls every time a user navigates to a word’s “hint” page, so as to minimize our interaction with the external API. All these measures are in an effort to not waste unnecessary power.

 

Weekly Questions

• 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 primary risk we anticipate would be the multi block integration with the grid. We have only tested our code logic with one block’s circuit since the rest of our components had not yet arrived. If there are issues with using the multiplexer to interface with multiple UART lines, we will have to explore alternatives. The risk can be managed by modifying the program to utilize other communication protocols like I2C instead. If the latency is too high, the complexity of the UART communication algorithm can be simplified.

Another risk is the secure placement of parts within the block. In each block, there will be the Pico, LCD, battery components and pogo pins. It is important to secure the components to maintain the electrical connection. Initially, we soldered wires directly from the pogo pin wires to the LCD breakout board, but the wires would break easily. Our solution was to solder female pins onto the other side of the Pico breakout board to allow us to plug in wires for the pogo pins. We aim to test the completed blocks with this layout to see if the connection remains secure. Otherwise, our mitigation would be to make 3D printed holders for the components within the blocks to hold them in place.

 

• 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?

For the design, we were initially going to use wood to make the grid. However, we looked into procuring wood but realized that it was too expensive for our budget. We decided to switch to using cardboard instead since it was easier to build and cheaper to procure, while still maintaining the rigidity we need for the grid. The cost for our project will be reduced with this change.

 

• Provide an updated schedule if changes have occurred.

For our schedule, we are on track and there has not been major changes. We are not going to build the actual grid yet, but instead focus on prototyping a platform to place the grid pogo pins on for testing. The plan now is to focus on having fully built blocks to test the end to end functionality of multiple blocks with the grid circuit.

 

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

In the past week, we have fully built one block including laser cutting all the cutouts for the pogo pins and charging port, and placing all the soldered components into the block. We have also soldered all the components to prepare them for the remaining blocks, only being left with the laser cutting of the blocks before they can be fully tested.

On the software side, we have fleshed out the design for the Embedded Controller, Game Controller and Web App functions and how they interface with one another. We have also written out all the code functions we need for the RPi and Pico and tested a single Pico with the RPi.

We also have a functioning webapp with Merriam Webster API integration and was able to simulate submission and loading of words from the webapp side. There is also exposed API endpoints for the embedded controller to trigger when the submit button is pressed.

Everything is ready for a primary end-to-end integration and testing next week!

• 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 communication between the RPi 5, pico, and LCD not working properly. If this communication doesn’t work, then we need to rethink the entire embedded communication portion of the project. To manage this risk, we have tested basic UART communication between the RPi and pico, and SPI communication between the pico and the LCD, and found both to be working separately. We plan to test the full path of communication before moving forward with building more blocks. If we run into issues with our single block prototype, our contingency plan is to swap out elements based on what is not working. We do not expect the RPi5 and pico communication to fail since these are widely-used components that many people have successfully used in other projects . Most likely, if the LCDs are the problem, we will pivot to the familiar RGB backlight I2C LCDs from 18-100.
  • Additionally, there are physical design risks such as the acrylic blocks being too thick for the pogo pins to stick out of (thus preventing a good connection to the grid’s pogo pins), the fact that the USB-C ports on the batteries require us to drill right on the seam of the battery holder in order to make an accessible charging port, and the fact that the LCDs have female header pins for the picos that force us to solder wires onto very small contact points on the LCD manufacturer’s board, which could be less secure and take longer to fabricate. To mitigate these risks, we will fabricate 1 block to see if these physical design specs will work out. Afterwards, we will adjust our components and construction plan accordingly if certain approaches or components do not 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.
  • No changes were made to the existing design of the system since last week, when we fleshed out the details for our design presentation. However, we have updated our schedule to take into account shipping/ordering delays in retrieving our parts. As part of our risk mitigation plan, we are ordering parts in batches to make sure we don’t spend all our budget on parts that won’t work for our project. However, this strategy increases the waiting time between stages of our project as we have to wait for parts to arrive every time we order. This updated schedule can be seen in our Gantt chart.

• This is also the place to put some photos of your progress or to brag about a component you got working
  • We setup, implemented, tested, and verified that UART works between RPi5 and RPi pico using Micropython and pogo pins.
  • We were able to get SPI LCD displays working with the pico.
    •  
  • We finished implementing most of web app frontend + backend (game controller just needs to call backend API functions to control game flow display on web app) — still need to use Merriam-Webster API instead of free Dictionary API.
  • We tested and verified that I2C works between RPi5 and row LCDs.

 

This week we mainly took on creating the Design Review slides. For the Design Review slides, we discussed and created the game flow logic in which we made FSMs and flow diagrams to explain our process in more detail. The more high level flow diagrams were created for the slides and the more detailed ones will be reserved for the Design Review document. We researched many different components and discussed them largely, coming up with the design requirements for Connexus. We also looked into timing and clarified our testing strategy so that we could better measure our success in meeting our requirements.

We ordered our 1st batch of parts and the most significant risk at this point was obtaining parts that would create a functional block as well as meet our dimension and weight requirements. This risk is being managed by ordering our parts in batches and buying enough to build 2 blocks to ensure that all the components that we selected will work well together. We will move fast with initial developments and use the built in slack time if necessary in the event that we need to order different parts. Also, one of the LCDs that we initially put out an order for was on the banned list of vendors and this helped narrow down our options of microcontrollers. The initial order of LCD included an already integrated LCD with ESP32 and at a fairly low cost for the abundant features we could implement like touch screen once we reach MVP. However, due to that ban, we decided to go back to a low-level and just buy components that are readily available to avoid a back and forth on that component we originally wanted. Now we have narrowed the microcontroller to an Rpi Pico which was the one we wanted to do in the proposal so our plans haven’t exactly strayed far. We then found an LCD that perfectly aligns with the Rpi Pico which would reduce wiring and allow for more compact layout when we place it in the cube. This option was also cheaper which allows us more wiggle room with budget when we have completed the MVP and want to move onto having all 16 blocks.

Our schedule has updated as we ordered parts slightly later than we had wanted to and we were also waiting for them. While waiting for parts CAD models can only be made to mock the system, but we felt that the actual building/assembling of the block and grid should wait until all the components are in and we confirm that their sizes are as true as their documentation says. We shifted the focus to flushing out the web app and doing as much as we can there as we wait for parts. The website has most of the pages setup and also functionality for uploading custom words. In addition, we are looking into various Rpi libraries that would help with development. Since we borrowed the Rpi 5, we immediately were able to use it so we just booted the OS and set up a remote virtual machine through Real VNC viewer so that we could all access the Rpi with ease. We soldered jumper cables onto some of our parts to help with prototyping when all the parts we need to make an initial block come in. For next week we will focus on establishing our communication protocol and also test that connect through the pogo pins that we bought. We will also swap out the temporary API calls from the free dictionary API to the Merriam-Webster API once we are able to register our App with them. Also we will build 2 blocks out of cardboard to get the initial dimensions before we decide on ordering acrylic cubes as well as a fake grid slot holder to connect blocks to the main Rpi.

Website Interim Demo

Part A written by Alexis Duong
Connexus is enjoyable instead of being frustrating as many novice players and English Language Learners (ELL) might feel while playing NYT Connections. It not only engages a user’s mind but it offers a physical interaction that would entice the user’s sense of touch and sight that is not offered with Connections. We hope that Connexus can be fun to play with and boost a person’s mood so that they leave the experience more happy and satisfied than when they started. Connexus ensures safety through electrical isolation of our circuitry and the user. The grid will contain some electrical components in a separate layer inside the hollowed out part of the grid so that electrical components are not exposed to the user and are insulated in that manner. The blocks themselves will be easy to hold and the user will only have access to the charging port as well as an on/off switch for the blocks so that they can de-power the system if they sense any hazards. We want the users to feel safe while playing the game and will therefore make sure that all electrical hazards are accounted for so that the user can focus on just having fun. In terms of welfare, Connexus is a game that sparks mental and physical engagement that is educational for the user and it can be a break from staring at a screen all the time as most people tend to do these days. NYT Connections is online and having to stare at blocks on a screen while you are thinking of a solution isn’t particularly the best as this can cause further eye strain for the users. Connexus helps to remind people to take a break from their screens and enjoy playing a game in real-life!

Part B written by Wen Hui Leng
Connexus is based on NYT Connections which is an American English word game. To perform well in the game, players would require an extensive knowledge of vocabulary to understand the double meaning of words and also be familiar with American cultural references to understand the context in which some of the words might be used. Our game, Connexus, targets novice players and English Language Learners. We aim to make the word game more accessible by having a virtual companion that provides hints and assistance to the player in solving the puzzle. These hints are in terms of word definitions and clarifications on American cultural references. Having the virtual companion would allow these players who might initially feel discouraged when playing NYT Connections to have the ability to learn more about the meaning behind the words and solve the puzzle as well. This ultimately makes the word game a lot more inclusive and accessible to players from all backgrounds. Additionally, we also aim to include a custom word upload feature on the virtual companion. If the actual NYT connections are too difficult, ELLs would still be able to utilize our game by uploading their own words. This would allow ELLs to utilize this engaging game to learn new vocabulary in English in a fun and interactive way. Having physical blocks that players can interact with is also more engaging and fun, hence targeting certain users who might have low attention spans or are tactile-based learners. This will allow them to enjoy playing Connections as much as those who play the online version of the game.

Part C written by Nicole Feng
Connexus is marketed towards novice NYT Connections players and English Language Learners (ELL) as a game that is more interactive and less frustrating to play than the current NYT Connections game. Thus, novices and ELLs would be the main audience purchasing or consuming our product. English is the number one language that people learn on DuoLingo, and is taught as a second language in many countries as it is widely considered the current global language. Our product is a tool that makes learning English more fun as it is wrapped up in a physical game that users can play, so we anticipate Connexus being able to satisfy the need for engaging English-learning tools. Additionally, the parts used to make Connexus are common electrical components (LCD displays, batteries, microcontrollers, etc.) and manufacturing materials (acrylic, wood, etc.). Acquiring these parts to manufacture our product shouldn’t really pose a problem since they are widely available and relatively inexpensive, so producing and distributing Connexus would be very doable and would contribute to the economic sectors related to electrical consumer goods.

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 at this point is the communication between the block’s microcontroller (Pico/ESP32) and the central microcontroller (Rpi5). The block should be able to receive the word accurately from the central microcontroller. This risk is managed by implementing and testing the most basic UART communication protocol first before implementing additional features like updating the LCD display when the correct answer is submitted.

 

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?

• During our meeting this week, we discussed our preliminary parts list, mainly focusing on how the components are connected together within the block and the choice of the LCD.
• We found the 9V battery, battery holder and multicolor touchscreen LCD screen with integrated ESP32. We decided to consider the option of the LCD screen with integrated ESP32 to reduce the work required to create a custom PCB since the product already comes with a PCB that connects the LCD to the ESP32. It also opens up opportunities for us to add in extra features like touchscreen capabilities or wifi communication with the central Rpi. However, there might not be an LCD of the appropriate dimensions and it is unclear if there is sufficient documentation to support our integration of the advanced LCD screen. Our alternative is to fall back on our original design of using a Rpi Pico + standard LCD screen + custom PCB.

 

Provide an updated schedule if changes have occurred.

• If we do decide to purchase the integrated LCD with ESP32, we would not have to create a custom PCB, hence eliminating the need for the PCB design, testing and fabrication processes in our schedule.
• Moving forward, we are going to conduct more research on the other LCD options available. We will also be doing a CAD model of all the components and decide on the block dimensions after we have procured the individual components so that we know the exact dimensions and how they would fit.