Category: Team Status Reports

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.

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.

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)
   a. A narration stuck issue when running standard mode game on web, the issue is only present on the rpi touchscreen and not on local server run so it is tricky to debug. One way to manage this is to build a test program with an audio output and see what is wrong with the speech module on web run.
   b. For the physical build, the MDF board available for purchase has a smaller size than we need, so we need to find a way to securely connect the boards together into a bigger panel that supports the board’s weight. We plan to use either glue or metal connectors for the flat connections and furniture connector for corner connections.
   c. The integration of challenge mode and standard mode, as currently the standard mode is being run on web and challenge mode is written in python. We plan to convert the python code and integrate both games in web-run format.
   d. For the webpage to accept user question-answer upload and rpi local download, we need to integrate a cloud database and add a ‘synchronize’ control on the game interface, working with cloud databases is new and might take some time to build this part of our system.
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)
   In the implementation of the game, we switched from Pygame to Loveable AI. This change was recommended because Pygame’s complexity exceeded the requirements of our game. The transition simplifies development while preserving functionality. However, it introduced new challenges, such as display errors on our touchscreen. These costs will be mitigated by priority in debugging the display error for next week.
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)
   There are no big changes in the schedule. We need to order more MDF boards and a plastic sheet to be ready to build the machine. Our group is planning to have the games work by 3/21 and the physical building to be done by 3/25.

Video link: Touchscreen & Web Testing for 3/15/25

Attached above are the video of testing the web and the touchscreen using the rpi and a screenshot of the challenge mode code.

Part A: … with consideration of global factors(written by Vicky).

As an entertainment physical portable game, our product provides accessibility for individuals with disabilities, offers text-to-speech for visually impaired users and alternative input methods for those with limited mobility, further ensures a globally conscious design. Moreover, since internet access and digital infrastructure vary widely across regions, our system is designed to function offline or with minimal connectivity, making it viable in areas with limited technological resources.

Part B: … with consideration of cultural factors(written by Min Ji).

To make sure that our trivia vending machine is sensitive to culture and engages a diverse audience, we need to carefully consider the content of trivia as well as the experience of the users. One useful way to prevent inadvertent bias or exclusion is to review and edit trivia questions to ensure they are accurate and appropriate for many different cultural groups. From a design perspective, we must provide accessibility through high-contrast screens for better readability and maybe have multiple languages for individuals who are not English speakers. To make sure the UI/UX is as intuitive as possible, we can test it with people from diverse backgrounds and adjust the design as necessary based on their feedback.

Part C: … with consideration of environmental factors(written by Min Ji).

In terms of environmental considerations, we can also be sustainable in the choices for both material consumption and energy use. Our choice of using an MDF(Medium Density Fiberboard) and transparent plastic for the outer candy casing can reduce waste as compared to non-reusable materials. We can save power waste by ensuring that unwanted parts enter standby mode when unused. Using low-power microcontrollers and LED displays can reduce wasteful energy consumption. With these design choices, we can ensure that our trivia vending machine is not only environmentally friendly but also energy efficient.

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)
   Some risks so far are the physical build of the machine and how the assembly will securely come together. Another risk is we are unsure how long it will take for the final integration, as of now, Vicky is working on the Arduino control for dispensing and building the standard mode game code without styled ux graphics, and the website interface; Min Ji is working on the speech audio generation, graphics for standard mode and the website interface; and Fei is working on the touch game. Our plan is to allocate one week before the interim demo to straighten out the mismatches during integration
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 Vicky)
   Due to consideration on making an intuitive design and more portable physical product, we eliminated the horizontal/vertical fetching tray inside the machine, thus getting rid of the aluminum bars, stepper motors, and attachment wood hardware, making the product much lighter. We also eliminated the physical buttons and the LCD screen in exchange for using a bigger touchscreen of size 10 inch. The change in screen incurred some order delay and shifted around our task order slightly.
   
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 is the updated Gantt Chart. No big changes but added minor tasks that have to be done by 3/14 and 3/21.
   For progress: The updated code for audio narration is in our git repo. Attached is a sample recording of our SweeTrivia audio narration.
   

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)
   So far one risk is how the unknown touch screen lag time will affect the player question-answering experience in the challenge mode, we plan to mitigate that by using one button for the user tap signal in the flappy bird logic if the touch lag time is too long. Another challenge is the integration of the project, for example so far our work division on the standard mode and challenge mode is separate. We also need to integrate the arduino motor driver side of the system with the rpi game side of the system.  So we need to allocate additional time (1 week minimum before the set MVP date) after each mode is finished. We also faced the question of players being confused with how to navigate the interface and how to reset, so we need to have graphics on the screen display to show optional new player instructions.
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)
   After receiving feedback from the design review presentation, we made some changes to our microcontroller choice and refined aspects of our design. It was apparent that our design was confusing for the audience. We decided to change the microcontroller because the previous option was not powerful enough for our design. Within our budget, the new selection is a better fit. This switch might delay some timelines until the new microcontroller arrives, but we’ve adjusted our plans to minimize the impact.
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)
   There haven’t been any big changes in our schedule so far. Instead, the following are the upcoming plans until the end of spring break week(~3/9):

• Assemble the rpi screen with the touch screen and buttons and upload the standard mode
• Write the arduino control code(motor + servo + lcd) for the dispense process
• Make sure the AI audio narration works with speaker + rpi
• Implement flappy bird game and upload it onto the rpi to test on touch screen

Part A: … with respect to considerations of public health, safety or welfare. (written by Fei)
Our machine is designed with both physical and psychological well-being in mind. By incorporating an interactive trivia experience, it encourages mental engagement, making it valuable in educational and social settings. Additionally, the voice and button-based interaction enhance accessibility, ensuring individuals with different needs can participate easily.

Safety is a key priority in our design, as vending machines must function reliably without posing risks to users. To ensure stable operation and prevent electrical hazards, our machine is powered by a 12V DC adapter. The structure, made of MDF boards and aluminum tubes, provides durability while keeping the device lightweight and stable.

Part B: … with consideration of social factors. (written by Min Ji)
Our trivia vending machine unites people in that it makes socializing exciting and enjoyable. Whether through teamwork or friendly rivalry, it’s an excellent method of breaking the ice in any environment. Trivia games also tend to make people bond naturally—whether buddies are collaborating to come up with correct answers or even playfully challenging each other. It’s a perfect way for colleagues, family members, or even strangers to bond too. Since the trivia topics can be fully customized through an online platform(website to be built), the game can be appealing to a wide range of interests, cultures, and ages, thus making it inclusive and versatile.

Beyond entertainment, our trivia machine also possesses real educational and team-building value. It can enhance learning as an interactive and engaging experience in schools, reinforcing what has been learned in a fun way. In the workplace, it is a casual team-building activity, so colleagues get to interact and think as a team. During community events or social gatherings, it gives people something to talk about and do, so the atmosphere is more lively and interesting. By combining education, competition, and openness to all, our product makes social interactions richer and more enjoyable.

Part C: … with consideration of economic factors. (written by Vicky)
Our product’s portable dimension and use in entertainment space makes it a fast moving consumer good. If launched to market it can be sold in chain department stores as a party game or a common gift option. The assembly in the production part will require some manual labor. During use of our product, the user needs to have access to network connection in order to log on to the website and enter their customized questions. The user also need to supply their own candy/treat refill for future dispensing.

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)
   One development/change we encountered this week was to adopt the waterfall project management method, implement and update our product versions sequentially, start with a simple crude prototype and add more features gradually. This means for the following 2 weeks we aim to have both the text-based game and touchscreen game working with a simple interface. After that we will then optimize the visual interface and build the website for question customization. We estimate the making a website will take up a bulk of time and decided to implement that after finishing the game part so it does not hold up our progress.

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)
We have finalized more details of the design, ensuring everything aligns with our project goals and requirements. However, no changes have been made to the existing design of the system this week. The entire team is working seamlessly toward delivering the final product.

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)
We modified the current status update of the tasks, and new tasks will be started in the upcoming week. A shared document of the trivia questions(approx. 300 questions in total) was made so that each team member could write questions for the sports, science, and entertainment category respectively.

Link to our Gantt Chart: sweeTrivia Gantt Chart

Link to our trivia questions database: Trivia Questions Database 

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)
   After coming up with some sample questions, it seems that using one LCD screen for full display of the question body, the 4 choices, the time limit at top left corner and current score on the top right corner is not practical. We could resolve this by either using multiple LCD screens for the standard mode, or transfer all text to the touch screen display. The first approach would result in the final product being too heavy or the front panel being too crowded, while the second approach would make the buttons seem out of place and result in a counterintuitive interface. Another risk/challenge is integrating the arduino control side (takes care of power and motor control) with the raspberry pi side (takes care of interface graphics and text, two modes’ game program, speaker control, dispense signal, etc), we need to allocate extra time to merge our parallel work results.
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 was a change to our original plan regarding the timeline for assembling the vending machine. Initially, we planned to assemble the machine first to match the final product, but after discussing with the professor, we decided to postpone this step toward the end of the project timeline to prioritize reaching the MVP as quickly as possible. This adjustment allows us to validate the system’s core functionality before investing time and resources into assembly, which is achievable in a foreseeable amount of time. While this shift introduces the potential risk of a less refined final product, we plan to mitigate this by allocating ample time for assembly and committing to an intensive final push to refine and optimize the system before completion. 
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)
   We modified our tasks’ due date, MVP due date, and tasks that need to be done beyond our MVP date.
   Link to our Gantt Chart: https://docs.google.com/spreadsheets/d/1JmANpvjDwcfwNEb8NOHpPJ_vVw9D5-gHEve7-nGgvLc/edit?gid=0#gid=0