Fei’s Status Report for Apr 26

This week, I focused primarily on finishing up the MVP requirements for the Flappy Bird gameplay and helping a bit with motor control integration. While the basic game flow is now functional, I also started exploring post-MVP features like adding sound effects and moving gaps after hitting a score threshold. I am slightly behind schedule, as I was hoping to finish everything this week, but with other coursework wrapping up, I should be able to catch up soon. Looking ahead to next week, I plan to continue developing the post-MVP features, work on the final poster, and support the team with demo preparation and final polishing to ensure everything is ready for our final presentation.

Min Ji’s Status Report for April 26

This week I worked on:

  1. Finalizing final presentation slides and presented in front of the class.
  2. Assembly work on a machine with Vicky:
    • Recoil the 4 slots to right gap and length + test 20+ times
    • Glue motors back on to lower position than before
    • Reconnect wire connections
    • Glue backpanel with the side panels
    • Laser cut 8 coil holder walls
    • Laser cut plexiglass
    • Stick on LED strip
  3. Finished 1st draft and 2nd draft of final poster.
  4. Prepared for shooting final video, filmed the intro.

10 point candy motor

20 point candy motor

30 point candy motor

40 point candy motor

My progress is on schedule. I still need to finish debugging the QR-code before the final demo.

In the upcoming week, I plan to finish the poster, final video, and get ready for the final demo.

Team Status Report for April 26

  1. 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? (by Vicky)
    Our project is at the final stage of integration. Currently the box is fully assembled (all panels glued except for the front panel for emergency debugging/refill) and the standard mode game logic and dispense is fully tested. The post-mvp features (shopping mechanism at candy selection, QR code) are still being added. The most significant risk now is that our code base does not have the updated challenge mode logic:
    a. Each correct answer is now worth 10 points while it should be worth 15.
    b. The questions in challenge mode now are not being pulled from the database but instead using same questions for each round.
    c. When bird hit the ground the error message is  ‘incorrect answer’ instead of ‘hit ground!’.
    d. The score does not start from zero in an entire new round. (Started after a dispense round).
    A teammate has been working on these features, if our code base is not updated in time, our contigency plan is that Vicky and Min Ji will write the code to fix these issues.
  2.  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? (by Fei)                                                                      We made some modification on the height of the candy slot back panel. It didn’t take us much time to reprint it, as we had learned how to use the more advanced laser cutter in TechSpark. However, the change wasn’t particularly helpful, as we later learned from our ME friend that the coil needs to touch the ground to better support the weight of the candy. Our original plan was to use a taller panel to place the motor higher, but because of this requirement, the idea didn’t work out well.
  3. Provide an updated schedule if changes have occurred. This is also the place to put some photos of your progress or to brag about a component you got working. (by Min Ji)

No big schedule changes. Will plan to finish the following:

  • final poster
  • final video
  • prep for the final demo

10 point candy motor

20 point candy motor

30 point candy motor

40 point candy motor

  1. 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.
    – Design changes: we purchased a different coil (for 25 dollars ouch) that is harder and stiffer which should work in our favor, but the coil is ready-made and the size does not match the box’s internal dimensions. We then seeked help making some mechanical analysis and lowered the position of the coils so that the weight of the items are sitting on the shelf panels not the coils. This fixed the coils being bent out of shape during rotation and make the dispense smoother and more sustainable.
    – Overall system test: made 3 dispense test (full dispense from full to empty) on all 4 candy slots to make sure every motor and coil are working properly.
    – Tested the synchronization of audio and sound effects. works great, no overlapping/discontinue issue.

Fei’s Status Report for Apr 19

This week, I focused primarily on debugging and integration for our project, as well as the final presentation ppt. While the challenge mode are now can either start a new round or transition to the candy selection page, I encountered an issue on my end where the game is currently not running as expected. I’ve been investigating the root cause and testing different parts of the code to isolate the problem. I am slightly behind the schedule due to this setback.  Looking ahead to next week, I plan to resolve the current runtime issue, complete the full integration of the gameplay flow, and support the team with final testing and polishing to ensure the system functions reliably in preparation for our final demonstration.

Team Status Report for April 19

1. 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?  (by Vicky)

  • Sound effect and audio: we were having some conflicts before on getting the sound and audio to work together with the rpi download, Vicky fixed that by adding back the narrate and sound endpoint api-server.cjs. 
  • Rpi download: Min Ji added an customization question category and fixed the google cloud drive csv management and the rpi local download. Now the player can upload personal questions and directly check if they are included. 
  • Dispense program: Added back i2c communication code in the new api-server.cjs file, similar code as before in server.js only updated the host address. Arduino and motor wire connections are the same as before. 
  • Paint: We tried to enhance the look of the machine box by spray painting the MDF boards. The spray paint was hard to work with but we did multiple layers to achieve an even finish. 
  •  Board reprint: We laser cut new boards for the front, left and back panel for a clean edge that will hold on more tightly for the finger joints.

    2. 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? (by Fei)

Yes, a change was made to the visual design of the system—specifically, the appearance of the letters on the front panel was modified to better align with the desired squid game theme aesthetic. This change doesn’t introduces any additional costs and the team are all very satisfied with the current style.

3. Provide an updated schedule if changes have occurred. This is also the place to put some photos of your progress or to brag about a component you got working. (by Min Ji)
No schedule changes. 

 

Min Ji’s Status Report for April 19

This week, I focused on repainting the left, top, and front panels as well as the letters. After painting them, I assembled all structural components, including the inner panels. The coils are not here yet, so I wasn’t able to glue them, but other than the coils, the box assembly is done.
For the software tasks, I successfully deployed the website to production at www.sweetrivia.me. The Rpi question download bug was fixed(had an incorrect Google Drive ID), and the QR code functionality on the website to link to the upload interface was attempted. I also completed preparations for the final presentation slides.

I am on track overall. The major deliverables, including the structural assembly, paintwork, website deployment, and challenge mode integration, have been completed as planned. The only issue still being resolved is the QR-code-triggered cloud download functionality on the RPi. I am planning to continue debugging into next week to ensure a seamless sync between the frontend and backend.

For the upcoming week, I plan to

  • Finalize the QR-code-based cloud download pipeline, ensuring that the RPi correctly pulls and processes the selected CSV from Google Drive
  • Prepare and present our final presentation
  • Polish UI/UX elements

 

Fei’s Status Report for Apr 12

This week, I worked on both the software and hardware aspects of our project. On the hardware side, although the structure is functional, the inner divider panel needed to be reprinted, as the original top panel was unstable and couldn’t close properly. I redesigned and reprinted the panel to resolve that issue. On the software side, I enhanced the challenge mode gameplay by introducing velocity changes to the bird after a certain amount of time to make it more engaging. I also completed several updates, including increasing the vertical gap between barriers, enlarging the score and lives-left displays, and updating the background to a new pink theme. In addition, I tried to implement the correct screen flow so that after each round, players are taken to a continue/exit screen—selecting “continue” starts another round with the score persisting, while “exit” leads to the candy selection page, which then returns to the home screen. I am currently on schedule with our project plan. For next week, I plan to focus on integrating the software with the vending machine hardware and collaborate with the team to add decorative elements to the vending machine.

Min Ji’s Status Report for April 12

This week, I focused on three major subsystems: Raspberry Pi audio narration, synchronization between the website and Raspberry Pi, and user interface finalization for both Challenge and Standard Modes. Each component has been implemented and tested.

  • Raspberry Pi Audio Narration: I made an attempt on implementing the speech functionality using pyttx3 on the Raspberry Pi after confirming that previous options such as espeak-ng and Google Cloud TTS were not viable. The audio narration still had some issue and Vicky took over.
  • Website-to-Raspberry Pi Synchronization: I took over from Vicky and worked on the website-related tasks. I developed a complete data pipeline that allows the Raspberry Pi to download new CSV files from Google Drive, parse the contents, and append only new questions to the local questions_and_choices.json database. This process avoids duplication by checking previously synced filenames. I also categorized questions upon import and ensured filtering logic, particularly for the new “Customization” category, was respected during gameplay.
  • Standard Mode Customization Integration: I created a new “Customization” category and implemented the filtering logic so that only relevant questions appear when this category is selected. I also built a new page to handle this mode in the same structure as the existing standard gameplay. I confirmed that questions in this category render correctly and are narrated on the Raspberry Pi.
  • Challenge Mode UX Improvements: I finalized the post-game flow by adding a screen prompting users to either exit or continue. If “continue” is selected, the previous score is preserved and the game resumes; if “exit” is selected, the user is redirected to the candy selection screen. I also added logic to automatically return to the home screen if the score reaches zero. It works the same as the standard mode.
  • Hardware – Aesthetic Polishing: I painted the outer wooden structure of the vending machine to give it a clean and arcade-like appearance for the demo and final presentation.

 

I am currently on schedule with my contributions and slightly ahead in some areas. There are no outstanding tasks from this week, and no additional catch-up work is needed at this time.

 

In the upcoming week, I plan to do the following:

  • implement the logic for generating a QR code that links to the website and allows users to download question sets and assist with deploying the website to support this functionality
  • begin preparing our final presentation slides and submit them for review and feedback by Tuesday and Wednesday.

Min Ji’s Status Report for March 29

This week:

  1. Hardware Fabrication & Setup
    I spent significant time laser cutting and assembling key components of our vending machine. I laser cut structural parts and began researching how to enable kiosk mode on the Raspberry Pi, alongside digging into the persistent issues with text-to-speech narration. The following day, I laser cut the main board for the project and spent the evening at TechSpark, taking advantage of tools and space to focus on precision fabrication. I also laser cut the SweeTrivia letters and front panel, and glued the candy dispensing wire into place on the motor using hot glue to keep things neat and secure.
  2. Audio Output & Narration Integration
    After struggling to resolve the TTS issue using other tools, I successfully connected the Raspberry Pi’s audio output to an external speaker. However, the audio narration works on my local laptop, not in the rpi, so I am planning to move back to espeak-ng from the browser-based web API.  I restored narration using espeak-ng, which offered much more reliable performance. This works on my local, so I will have to test this out on Sunday(3/30) if this works with the rpi as well.
  3. Candy Selection Logic & User Feedback
    I focused on refining the candy selection interface and ensuring it functioned properly with the point system. Previously, the screen displayed incorrect options, especially when the user reached 50 points, and the game automatically ended. I fixed the logic so that no matter how many points the user gets, it shows the exit/continue option only if 10 seconds have passed. Additionally, I implemented a candy dispense eligibility logic so that users are only able to select candies that are priced within the user’s budget. Affordable candies are shown, and added new feedback mechanisms: if the user has zero points, they’re redirected to the home screen once they decide to exit since there is no need for candy dispension, and if they try to purchase something they can’t afford, a warning saying “Not enough points!” appears instead of failing silently. These enhancements improve both usability and gameplay clarity

<Video of standard code gameplay: 3.29 Standard Mode Gameplay>

I think I am on schedule, but I will have to keep testing the audio using the external speakers and changing back to espeak-ng.

In the upcoming week(3/30-4/5), I am planning to continue developing both the functionality and user experience of the vending machine system by accomplishing the following:

  • test the Raspberry Pi audio narration using espeak-ng to ensure consistent and clear voice output across different stages of the game.
  • prepare for our in-class demo by ensuring the core features—including candy selection, narration, and screen transitions—are working smoothly together.

Since narration is a key component of user engagement and accessibility, I want to verify that the system behaves reliably during full gameplay runs, including transitions between questions and responses to user input.

After the demo on April 2nd, I plan to implement a more sophisticated points-based shopping system. Instead of a one-at-a-time candy selection, this upgrade will allow users to select multiple candies as long as their total selections of candies stay within their point budget. This feature will more closely resemble real-world shopping behavior and enhance gameplay flexibility.

Following that, I also intend to finalize the UI/UX elements and refine them based on peer feedback and demo observations. Improvements may include clearer visual cues, responsive buttons, and improved text readability. Additionally, I am also looking into randomizing the trivia questions each time the game is played to improve replayability and make the experience more dynamic for users who return to the machine more than once.

Team Status Report for March 29

  1. 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? (written by Vicky)

=> Our most significant risk this week:

  1. Audio output: Getting the speaker on the rpi touchscreen to play the game’s audio narration. There seems to be an audio signal transmission problem from the rpi to the screen and the built-in speakers are not able to output sound. We managed this risk by using an external bluetooth speaker which worked well and the size of the speaker was suitable to be enclosed in the machine box behind the screen. 
  2. Kiosk display: Initially we configured the rpi to boot up in kiosk mode by making a run_kiosk.sh file and modifying the wayfire.ini inside .config. However this will only work with a deployed website, not with our current React app. We managed this by using command line kiosk mode inside chromium and the view had the same effect. 
  3. Mechanical assembly: We encountered some laser cutting challenges. 
    1. The purchased wood material size is slightly narrower than the initial design. We managed this by modifying the box height (see question 2).  
    2. Attaching the screen to the box: initially we wanted to make one 3D printed slider that covers the entire length of the cut-out screen space on the front panel. This did not work because there is not enough space to tilt the holder and install the screen. We managed this by changing the design to make two screen corner holders with narrow bottom gaps that tightly sit on the front panel. 
    3. Error margins that made the cut result deviate slightly from the design file. This may be caused by: the vibration of the laser cutter working table caused the material to move and the laser trace inaccurately. This was managed by using maximum laser power to minimize the number of total cut rounds. (One round of cut was still unrealistic because of the ¼ inch thickness)

2. 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? (written by Fei)

=>There were a couple of changes made to the existing design, including switching the SweetTrivia letters from etching to 3D, redesigning the shape of the screen holder, and reducing the CAD box height from 11.8 inches to 11 inches. These modifications were necessary to enhance aesthetics and improve functionality. Initially, we designed the screen holder to be the same length as the screen to not only support it but also hide the gap between the screen and the hole cut for it. However, after discussion, we realized that due to the inflexibility of the 3D printing material, fitting the screen might become difficult if the holder was the exact same length. As a result, we prioritized functionality over aesthetics and adjusted the design accordingly. Similarly, the box height was originally set to 11.8 inches to match the dimension of our wood board, but during laser cutting, we found it impossible to achieve that level of precision, so we adjusted it to 11 inches, slightly reducing the height without sacrificing too much space. These changes incurred costs related to design revisions and potential material waste. To mitigate these costs, we carefully reviewed every print file before sending it to the laser cutter and ensured the first prototype worked before printing the remaining parts.

3. Provide an updated schedule if changes have occurred. This is also the place to put some photos of your progress or to brag about a component you got working. (written by Min Ji)

=> no big changes in the schedule. Our group is planning to develop parts beyond our MVP after the demo. Attached are some pictures of the vending machine box.