Final report

https://drive.google.com/file/d/1yCA6a16mlX-ebjrBeiEj9fVXN8R3rkUr/view?usp=sharing

Team Status Report 04/27/24

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 risks are related to connections (solders breaking, sensors disconnecting). We are reinforcing our connections and using JHT connectors instead of soldering the sensors directly to a protoboard.

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?

No

 

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.

Capacitance test – We learned that the capacitance between different liquids didn’t change much, so we needed to use different metrics for classification.

Unit tests for temperature, tds, turbidity, and color sensors with different liquids. We found good variability between color, tds, and turbidity in our target liquids. We also found that the temperature sensor is consistent with what we expected.

Integration tests for the sensors once the system had been assembled – we tested the sensors in the bottle, and found the results from the unit tests remain.

Level testing for the ultrasonic testing – we tested that the level indicated by the ultrasonic sensor is consistent with the expected value. We also found that this could be used as a metric for bottle stability, and decided to use this instead of FSR’s. This allowed us to simplify our system and decrease energy expenditure.

Static code analysis for the Arduino code and JS code. Issues found (such as unreachable code and uninitialized values) were either mitigated or found to be false positives.

Connection test – we tested the connection between the app and the bottle, and found it to be stable.

Alan’s Status Report for 04/27/24

What did you personally accomplish this week on the project? Give files or photos that demonstrate your progress. Prove to the reader that you put sufficient effort into the project over the course of the week (12+ hours).

This week, I worked on our final bottle assembly. We have a new board, which should be more stable and less vulnerable to solders breaking, since it uses JHT connectors. I crimped connectors, tested sensor connections, and debugged solder and connection issues. I also worked on our final bottle, sealing sensors in place,  moving the display and adding a new switch (for the battery circuit) to the taller bottom compartment.

Is your progress on schedule or behind?

On schedule

What deliverables do you hope to complete in the next week?

Next week, I’ll finish the battery circuit and clean up any final issues with the bottle, to make sure we’re ready for a successful demo.

Team status report for 04/20/2024

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?

We had a few issues with fabrication, wires breaking, sensors disconnecting, and fitting the assembly in the bottom compartment. We resoldered our assembly, with a much more reinforced structure, and are printing a slightly taller bottom compartment.

 

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?

We moved away from a pressure plate and to an FSM based on the ultrasonic sensor to measure bottle stability. This will simplify the system, reduce weight, and slightly decrease power expenditure.

Updated schedule:

Alan’s status report for 04/20/24

What did you personally accomplish this week on the project? Give files or photos that demonstrate your progress. Prove to the reader that you put sufficient effort into the project over the course of the week (12+ hours).

This week I worked with Erin to resolder our assembly and produce the bottle we will use in the final demo. I also got the display working, and it shows liquid level, temperature, and classification. I then wrote and FSM to detect when the bottle is stable based on the stability of the ultrasonic sensor’s reading, eliminating the need for a pressure plate. Finally, I designed the integration tests we are performing to validate our final product

Is your progress on schedule or behind?

On schedule

What deliverables do you hope to complete in the next week?

Next week, I’ll continue testing the final bottle,  will add more liquid samples, and the capability for user-added liquids.

 

As you’ve designed, implemented and debugged your project, what new tools or new knowledge did you find it necessary to learn to be able to accomplish these tasks? What learning strategies did you use to acquire this new knowledge?

I’ve learned a lot about different sensors used to test and identify liquids, their principles of operation, and their libraries. I mostly learned this by googling, reading reviews, forums, and wikis. I also learned about bluetooth low energy, again, mostly by googling, reading forums and tutorials. Finally, I learned some things about hardware, fabrication, and durability, mostly by talking to classmates and trial and error as we build our product.

Team status report for 04/06/24

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?

Right now, we are concerned with finding a food-safe, effective sealant. We are exploring a few different options. The first one has already arrived, and we will begin testing shortly. We are also working on detecting uprightness with an FSR, and are exploring different alternatives for this (more than one FSR, a larger FSR, different stands to hold the FSR in the final bottle).

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?

Our exploration into sealants and FSR options does have a cost, but we have room in the budget for them.

Another big change is that we decided to 3D-print our bottle (out of food-safe acrylic), so we have purchased filament for it, but, again, there is room in the budget for it.

Now that you have some portions of your project built, and entering into the verification and validation phase of your project, provide a comprehensive update on what tests you have run or are planning to run. In particular, how will you analyze the anticipated measured results to verify your contribution to the project meets the engineering design requirements or the use case requirements?

We will measure the sensors (temperature, turbidity, tds) against the ground truth (from reference tables and/or pre-existing sensors we know to be correct), to make sure they are within an acceptable margin of error in the final assembly.

We will use fuzzers and static analysis tools to detect issues in the code and correct them (both for the microcontroller code and the app code)

We will stress-test the bottle for leakage by leaving liquid in it for an extended period of time, and moving it at intervals (the acceptable threshold is no leakage).

We will test the battery life by keeping the bottle on for extended periods of time, and simulating drinking from it at intervals (we expect to reach the battery life outlined in our requirements, of at least 2 days).

We will test the classifier for accuracy with different samples, as we calibrate the system for them.

Alan’s Status Report for 04/06/24

What did you personally accomplish this week on the project? Give files or photos that demonstrate your progress. Prove to the reader that you put sufficient effort into the project over the course of the week (12+ hours).

This week, I worked on getting the prototype ready for the interim demo. I worked on our backup microcontroller (after we had issues with the Adafruit’s, where they stopped working), re-writing code to be compatible with it. I collaborated with Erin to get the new setup working on the app. I also worked on the new physical prototype (as part of a team effort), and we now have a leak-free, working, classifying bottle! Finally, I calibrated the classifying algorithm for the bottle with nothing in it, water, milk, coffee, and orange juice, and rehearsed for, and delivered my portion of, the team demo.

Is your progress on schedule or behind?

On schedule

What deliverables do you hope to complete in the next week?

Next week, I will work on improving classifier accuracy, with more data points, and in detecting when the bottle is stood up correctly, with FSR’s. I will also begin work on testing, running a fuzzer and a static analysis tool on my arduino code.

 

Now that you have some portions of your project built, and entering into the verification and validation phase of your project, provide a comprehensive update on what tests you have run or are planning to run. In particular, how will you analyze the anticipated measured results to verify your contribution to the project meets the engineering design requirements or the use case requirements?

I will run tests with the sensors in the bottle against the ground truth – the thermometer with a reference one, and TDS and turbidity against reference metrics for our liquids. I will test these against the expected (and acceptable) tolerance of the sensors. For the color sensor, I will test it against different liquids in our final bottle, to make sure the interference of the bottle material is small enough to still give use usable data (as it has been in previous translucent prototypes). This will make sure our final assembly is within our tolerance.

I will also run a fuzzer and a static analysis tool on my microcontroller code, to ensure the code is reliable and secure, and does not have egregious, easily correctable faults in it.

For the classifier, I will test it with different beverages to ensure it can correctly classify them within an allowable tolerance. As I provide more data points and better calibration, I will expect the accuracy to improve.

Alan’s status report for 03/30/24

What did you personally accomplish this week on the project? Give files or photos that demonstrate your progress. Prove to the reader that you put sufficient effort into the project over the course of the week (12+ hours).

This week, I mostly worked on fabricating the bottle for the interim demo. I planned and drilled holes for the sensors, and sealed them in place with our food-safe sealant. It took a few days (the curing time for the sealant is 24 hours) and about three layers, but we now have a leak-free bottle! I also worked with Erin on soldering our circuit so we would no longer need a breadboard (she did most of the soldering; I did some of it, supported her on pieces that took two people, helped with planning for the circuit, modified the code to make connections easire, and tested the sensors once they had been soldered).

Is your progress on schedule or behind?

On schedule.

What deliverables do you hope to complete in the next week?

At the start of next week, I’ll focus on the interim demo – rehearsing my part of the presentation, helping define content, and troubleshoot any issues that come up so we can do to have a successful presentation.

I also plan on working some on connecting the battery, on working with Erin on the app to parse bluetooth data and implement the classifying logic in the app, and on the mechanism for testing whether the bottle is upright. We may need to purchase more pressure pads for this last part. I will also work on waterproofing solutions for the circuits in the bottom compartment (in case the sealant becomes leaky, which should not happen, but we will add a contingency measure to protect our circuit better).

Photo of fabricated bottle, holding water:

Team’s Status Report for 03/30/24

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?

We are working on integration, and the two main issues right now are fitting all the needed components into the bottle’s bottom chamber and detecting density and uprightness. For fitting all components, we are shortening wires as much as possible, and looking into fabricating a larger chamber.

For density and uprightness, we noticed that we couldn’t attach our pressure sensor directly to the bottom of our bottle, since it is slightly indented and the sensors are somewhat fragile when bent. Thus, we plan on fabricating an adapter (as was suggested to us in the weekly meeting) to improve that. We may need more pressure plates to work on this.

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?

We will need to purchase more pressure plates, but that is well within the budget; similarly, we plan on fabricating the adapter for the sensor and a larger bottom compartment, but we have access to printers we can use at no cost.

Here’s the bottle, with mounted sensors, that we assembled this week and will use for our interim demo:

Team Status Report for 03/23/24

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?

Currently, the main risks are physical – we have cadded and will print needed components to assemble our mvp for demonstration. We will need to carefully insulate non-waterproof electronics, make sure all components are securely in place, and sensors are properly secured as to provide reliable readings.

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?

We made several changes over this week. We added turbidity and total dissolved solids sensors, and removed the capacitance sensor, as we found much more significant changes and less overlap in the liquids we want to classify. We also changed the system to use a single Adafruit ItsyBitsy board, rather than two. This is because all sensors we are using can be connected to a single board, and we changed the ultrasound to be attached to the body of the bottle rather than the lid. This will allow us to reduce power consumption, simplify the power supply systems, increase communication reliability (as we only need to communicate with a single board) and simplify communication logic (as we don’t need to synchronize data from two sources).

The cost of the added sensors is well within budget, and the other changes do not incur costs.

Updated schedule: