Posted on

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? 

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

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.
No schedule changes. 

 

Posted on

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

 

Posted on

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.

Posted on

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.
Posted on

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.

Posted on

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.

Posted on

Fei’s Status Report for Mar 29

I worked on creating the CAD file using onshape and the physical build of the vending machine. We successfully built the vending machine by laser cutting the wood board and creating the first prototype of our final product. Additionally, I enhanced the playability of the challenge mode by introducing velocity changes to the bird after some time has passed. I am currently on schedule with the project plan. For next week, besides the interim demo, I plan to work on our website deployment and focus on debugging to ensure it matches our MVP. And if possible, continue refining the vending machine prototype by adding some decorative elements.

Posted on

Fei’s Status Report for Mar 22

This week, I completed the code for our challenge mode, including bird movement, gravity, generating the pipes and gaps, collision detection, and score tracking. I also ensured that everything worked smoothly when uploading to the rpi without displaying errors. In addition, I spent time refining the mechanics to make the gameplay feel smooth and responsive. After meeting with the TA to test play the game, I received helpful feedback on how to better engage users and made several adjustments, such as improving font readability and refining various UI elements. I am currently on schedule with the project plan. In the next week, I plan to physically build the vending machine by laser cutting the wood board and creating the first prototype of our final product before Wednesday. If time allows, I will also begin working on our website deployment.

Posted on

Min Ji’s Status Report for March 22

This week, I mostly continued working from where I left last week.

3/17:

  • Improved candy dispensing screen flow on the touchscreen interface
  • Added functionality for the “go back” button in all screens
  • Adjusted the overall UI/UX to closely match the provided Figma design specifications.
  • Work time: approximately 2.5 hrs

3/20:

  • Troubleshoot audio narration problems
    • Note: due to unresolved technical issues, I temporarily disabled audio narration to ensure reliable touchscreen testing. I am planning to add that back once I figure out the issue. I am assuming it’s because I did not connect the touchscreen HDMI with the Rpi micro HDMI. I now have the cable, so I will try testing that out next week.
  • Work time: approximately 6.5 hrs

3/21:

  • Purchased wood boards from Techspark with Vicky and discussed initial designs for the physical construction of our trivia kiosk.
  • Had a meeting with David and received valuable advice about environment variables and setting permissions correctly for kiosk mode.
  • Work time: approximately 2 hrs

My progress for this week is mostly on schedule. While encountering audio narration issues set back my initial timeline slightly, I managed to remain productive by pivoting my focus toward essential touchscreen UI/UX tasks without the audio narration function and physical design preparations. To prevent future delays, I ordered the HDMI converter promptly, and next week’s tests should resolve the audio issue, allowing me to get back on track.

For the upcoming week (3/23–3/29), I plan to achieve the following:

  • Conduct thorough testing using the newly received micro HDMI-HDMI cable to resolve and verify audio narration functionality on our touchscreen interface.
  • Start on the physical building of the machine, now that each component of the vending machine has reached a decent level for the demo.
  • Write the initial code for the Rpi to send a 4-digit signal upon candy selection(we have four candy selection slots), enabling communication between software and physical components so that Vicky can continue from there for candy dispensing.
  • Deploy our project website, enabling integration into kiosk mode for better UI/UX design.

I have an exam on Wednesday, so I will be working mostly after the exam this upcoming week, but I will make sure that I achieve my plans.

Posted on

Team Status Report for March 22

 

  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)
    => As our project moves forward, here are some possible risks:

    1. The challenge mode game on touch screen is experiencing some latency in the touch response. This does not affect the gameplay significantly but improving the response time will make it more user friendly and help players gain points more easily. This will be done by modifying the current program.
    2. We have decided to use ¼ inch thick MDF board to build the machine body and ⅛ inch thick board for the inside compartments. The advantage of using thicker walls is the interconnection between perpendicular sides will be fixed together more securely as a bigger touching cross sectional area has higher friction. The disadvantage is this will make the final product slightly heavier. This is a light trade-off.
    3. For the refill of items, our current solution is to fix the servo motors to the spirals (in which the items are filled), and fix the arduino board at the bottom of the machine. With a long connection line made secure, the user can take out the spirals like a tray and refill there.
    4. Our current planned view of the gameplay was done by implementing kiosk mode on the rpi system. This seems to be difficult during system development when we need to access code files when running the web page. We plan to switch to chrome browser kiosk only so it’s both easier to exit kiosk mode and make other rpi file edits.

  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)
    => Yes, a change was made to the existing design plan. We initially planned to use wood purchased from Amazon to build the vending machine and use wood glue and nails to hold the structure . However, after the ethics lecture and the discussion around E5, we found their method was more stable. Thus, we decided to purchase the wood directly from TechSpark which fits our needs better with its larger dimension.This change does incur additional costs, as the Amazon purchase had already been made. However, these costs are justified by the reduced risk of structural failure which minimizes the chance of rework. Moving forward, we will pay more attention to make sure the construction method is a good choice early on to avoid last-minute adjustments and additional expenses.

  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)

=> This week, our group successfully purchased wood from Techspark to construct our trivia kiosk and discussed detailed plans for assembly. Min Ji improved the touchscreen UI/UX, aligning it closely with our Figma design, and temporarily disabled audio narration for reliable testing. Vicky completed Arduino code tests for candy dispensing functionality, confirming the reliability of our motorized dispensing mechanism. Fei resolved some minor bugs within the challenge mode gameplay, ensuring smoother user interaction and reliability for the upcoming demonstration.

For the upcoming week(3/23-3/29),  we will prioritize the following tasks, with smaller numbers indicating higher priority:

  1. Physical Assembly of Kiosk Structure(All)
    Vicky will create laser-cut CAD files based on our recent design discussion and will assemble the machine. The aim is to finish assembly ideally before Wednesday. Min Ji and Fei will focus on helping assemble the structure by Wednesday(3/26).
  2. Motor and Dispensing Hardware Integration.
    Vicky will create spiral helixes using wires and attach them securely to the motors. Long wires will initially be used to allow easy refilling of candy.
  3. Integration of Raspberry Pi & Arduino (Min Ji + Vicky)
    Min Ji will test and finalize the Rpi functionality to send a 4-digit GPIO signal upon candy selection, confirming that signals are reliably received. Vicky will then adapt the existing Arduino dispensing code to trigger the candy motors based on Raspberry Pi signals.
  4. Kiosk Mode and Audio Narration Testing (Min Ji + Vicky)
    Min Ji will use the micro HDMI-HDMI converter to resolve the audio narration issue and thoroughly test kiosk mode interactions. Vicky and Min Ji will collaborate to confirm environment settings and permissions are optimized for the kiosk deployment.
  5. Website Deployment (Optional, Lower Priority)
    We will maintain our current UI as is for the interim demo, but we plan to deploy our existing website for testing the kiosk mode if sufficient time remains. This task is a lower priority, considering our current UI is functional and presentable for the demo.

Notes:

  • Tasks 1 and 2 are critical and must be finished early in the week (by Wednesday 3/26) to allow ample time for debugging and refinement in the latter half of the week.
  • Integration tasks(Task 3) and focusing on debugging any bugs seen in the gameplay follow immediately afterward. Our main goal for the interim demo is to have a clearly working gameplay.
  • Kiosk mode(Task 4) and website deployment(Task 5) are also critical but slightly lower priority than full assembly and hardware integration, so we scheduled it to be after initial assembly completion.