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.
