Category: Team Status Reports

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.