Attached is the poster created by the team for our demo day!
https://docs.google.com/presentation/d/1vygu6m0Y-9RZ-Gl3t9SFnsPY7yQNA1Dq/edit?usp=sharing&ouid=116482161551242473837&rtpof=true&sd=true
Corrado Govea’s Status Report for April 27th
This week’s accomplishments
- Prepared and gave the final presentation on Monday for our project.
- Continued testing and debugging of our system.
- Specifically, found some issues with the pump’s mosfet circuit where the mosfet was getting very hot even with a heatsink, so I redirected a fan that uses power directly from the gantry’s power supply.
- I helped debug the script used to control the heating and dispense, which was giving us some trouble when running everything together.
- Met with the team to discuss next steps and labor division for the remaining tasks (poster, final report).
Next Week’s Deliverables
- Finish fixing the current issues with the pump to make it more reliable — this will require extensive testing, but also lots of debugging to figure out what may be causing it to stop working sometimes.
- I will cover the testing and hardware implementation sections of the poster.
- Make an enclosure for all the electronics to sit in the gantry.
- Haven’t fully decided the labor division for the final report, but will be working on my parts once we meet to determine this.
Status Report: On Schedule
Elijah Knupp’s status report for April 27th
This week’s accomplishments
- Attended mandatory labs
- filled out reports that analyzed the final presentations from other groups
- Gathered data regarding the performance of our subsystems. Specifically:
- mapping the MOSFET gate voltages to the corresponding flow rate
- the performance of our PID loop that controls the heating element
- Once again, this week was filled with troubleshooting. There was a push to integrate everything together, which resulted in many bugs. There was a point in which all subcomponents worked correctly with each other. However, for whatever reason, the pump stopped working with the software script. Many hours were poured into trying to figure exactly why this happened, but no definitive result has been reached. Troubleshooting will continue this week.
Next weeks plan
- Complete the integration of the subsystems.
- This includes troubleshooting the pump bug described above. As mentioned above, we were able to get the pump (and all of the other subsystems) to work together for a full pour-over cycle. This week, we need to isolate this bug and fix it.
- Fine-tune the system. If needed, need to:
- tune the pour-rate of the pump (if flow rates are changed after the pump fix)
- ensure the total amount of water pour is accurate (up to 300mL)
- ensure the nozzle’s movements are completely contained within its expected range (to ensure no splashing/spilling water)
- Make the poster for the project
- Begin writing the final paper
Status Report: On schedule
Rio Pacheco’s status report for April 27th
This week’s accomplishments
- Continued work on Django app(2+hrs)
- https://github.com/Quarks-1/pour-over-and-over
- Convert data feed module to python Threads module
- Further UI improvements
- add Brew steps to brew page
- Add highlighting of current step on brew page
- Add status message for draw down period
- Add fun little coffee bean man to brew page
- Design pour spout holder for 3D printer
- Met in person to work together on project (8hrs)
- Attended mandatory lab (4hrs)
Next weeks plan
- Fine-tuning of full system and all of the writing assignments 🙁
Status Report: On schedule
Team Status Report for April 27th
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 main risk we have right now is our control loop for the pump to stop working. We have been running into a hardware bug that we haven’t been able to figure out where after a certain amount of time of testing the pump, it no longer receives any signals or voltage from its power supply. We imagine this should not be an issue during the final demo due to it only happening after 5+ hours of testing. Unfortunately, we do not have a contingency plan as swapping out a pump is not as simple as it sounds thus we will make sure not to stress it too much before demo day. In the event of total pump failure, we are still able to demonstrate pour patters as well as the entire webapp, we just will not be able to brew coffee.
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.
Flow rate test – Through this we learned that there was a minimum and maximum current that we could send the pump before it didn’t spin at all, thus we had to add a physical flower restrictor to change its flowrate as well
Water heater test – Through this we learned that our initial PID implementation had a small overshoot in terms of the temperature it would achieve. We repeated this test until we were able to refine our PID values to get a temperature +/- 5 degrees of the desired temperature
UI/UX stress test – Through collecting data for UX of our webapp we learned of some pain points for user unfamiliar with pour over coffee. We have since implemented features to help alleviate these, such as active step highlighting, profile sorting, and a friendly little coffee bean guy!
Corrado Govea’s Status Report for April 20th
This week’s accomplishments
- Spent many hours debugging the HV and LV circuits this week with Elijah!
- Assembled, probed, integrated and tested the HV power management PCB to control the heating element, with passing test results.
- Integrated the DC pump with the new power mosfet.
- Identified an issue with the circuit, where we were providing 5V to power the pump, but didn’t realize that there was also a voltage drop across the MOSFET:
- (1ohm) * (2A) = 2V drop across MOSFET.
- Solution: Increased DC supply to be 7V (5V pump + 2V MOSFET)
- (1ohm) * (2A) = 2V drop across MOSFET.
- Identified an issue with the circuit, where we were providing 5V to power the pump, but didn’t realize that there was also a voltage drop across the MOSFET:
- Completed testing for pouring water and for heating water with the team.
- Worked on final presentation.
Next Week’s Deliverables
- Continue integrating all systems and complete remaining testing.
- Ensure stability of new pump circuit, tune circuit by ensuring that gate current limiting resistor and gate discharge resistor values are appropriate through further testing.
- Add safety features to the gantry: cover to protect users from boiling water, securing all LV and power electronics to the gantry.
Status Report: On Schedule
Elijah Knupp’s status report for April 20th
This week’s accomplishments
- Attended mandatory labs
- To account for a drifting issue with the scale, added an automatic taring feature
- Created slides for the final presentation
- specifically, slides that corelated to the tests performed
- Troubleshot the pump circuit for over 12 hours. The issue was with amount of voltage supplied to the circuit. Although this was a simple solution, there were several red herrings that lead to the long troubleshooting process. Ultimately, to solve this issue, we:
- Consulted with 5 different individuals
- Ran a plethora of troubleshooting tests
- Ordered several sets of MOSFETS
- Continually swapped out components
- Tweaked and rebuilt the circuit several times
Next weeks plan
- Perform the necessary tests for the pump and heater
- Integrate all of the components together into one working project.
- Finalize the slides for final presentation
Status Report: On schedule
Team Status Report for April 20th
This week the team continued to work on the full system integration leading up to the internal “MVP”. Currently, the software is finished until we can get the water pump circuit working and integrated with the Arduino. We ran into an issue this week where we noticed that the scale seemed to drift in the weight that it was reading, thus we are looking into this more. Currently, the code does not rely on the scale weight so it shouldn’t impact our ability to reach MVP. We have speculated that this could be due to the Arduino not supplying enough power, but further testing is necessary to see if that is the case.
On the hardware side, the team (finally) got the pump to work with the circuit. The flow rate can be controlled through a PWM signal from the Arduino. The team will be testing the exact flow rates the pump can produce in the near future.
In terms of design requirements, we are currently meeting the following:
- ∓5℉ margin from set temperature of water
- >= 5 preloaded presets in the webapp
- 300ml water tank capacity
The rest of the design requirements are currently untestable until we get the water pump fully integrated, which will be happening sometime this week.
Rio Pacheco’s status report for April 20th
This week’s accomplishments
- Continued work on Django app(5+hrs)
- https://github.com/Quarks-1/pour-over-and-over
- Convert pouring mechanism to python Threads module
- Completely overhauled pour scheduling system to prevent webapp stalling
- Implement 5 default profiles into the setup.py file
- Further fine-tuning PID
- Add pour mechanism thread functions, to be tested this week
- Work on Final presentation (3hrs)
- Attended mandatory lab (4hrs)
Next weeks plan
- Further, fine-tune PID algo to get better temp stability
- Test water pump code with heater/pouring movement code
- Integrate all subsystems together
- Add steps display on brewing page
Status Report: On schedule
New tools/knowledge
- Python threads module
- Previously I had not used the python threads module, however through writing our webapp it was found that it was absolutely necessary. The ability to run functions concurrently as well as schedule them was important as without this feature the webapp would stall if we used while loops in the main thread. Although I had previously used threads in C, threads in python posed their own challenges like function input parameter type, as well as proper scheduling
- Python pyserial library
- Originally we had planned to use octopi for controlling the printer, but it turns out octopi can’t actually read the current position of the printer. We found out that we could just send individual GCode commands over USB using the pyserial library, which allowed us to cut out octopi entirely. I had not previously used pyserial to read data from an arduino either, so learning to do so was a new experience for me
- Django pre-loading data into the db
- Previously I had not made webapps where a setup file was run prior to starting the webapp after downloading the code. I also did not need to repopulate the database, which was something we needed for our webapp as it was a design requirement to have minimum 5 profiles at install. Learning to use the proper functions to repopulate the db was something I learned to do during this project.
- Resources used:
- Online forums such as reddit / StackOverflow / Django and Python documentation
- ChatGPT for writing test code quickly
Team Status Report for April 6th
This week, the team worked on full system integration leading up to our internal “MVP” — that is, all systems work to some extent, but all working together. The Kettle + PID loop and the 3D gantry can be controlled wirelessly, and we got a new pump, characterized it, and verified that it has enough power to prime itself.
At this point, all major systems are in an operating state, so next week we will work on assembling everything together so that we can start tuning the controls — this is important, as factors like height difference between the water reservoir and the nozzle can have an impact on flowrate.
The highest risk at the moment is ensuring that our current design meets the design requirements — for that reason, as we tune, we will start checking off on most of these requirements so that we can identify early if anything needs to be modified.
Extra: note on System Validation
We need to ensure that our product, as defined by our design requirements, meets the use case requirements that we defined early on in the semester. To do this, we plan on creating a simplified survey with a clear, measurable metric for each of our use case requirements, and we will try to collect as much field data as possible to determine if there are any areas that need to be improved from the consumer’s side.