- 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?
Although we stabilized it a lot, the dispenser still behaves unpredictably from time to time, not dispensing the card at all or dispensing it too hard. It happens either when the cylinder that is pushing the card forward is too close to the card or too far. We cannot do much about the problem of it dispensing cards too far. The good news is that it is quite rare.
The problem of cards not being dispensed at all is dealt with by simply retrying to dispense the card.
- 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?
The design of the dispenser changed. Now we do not use gears for the DC motor and instead directly rotate the cylinder with the dc motor. We also removed the top cylinder and instead are rotating the cylinder against a flat surface. This reduces the inconsistencies caused by the difference in thickness of the cylinder on every rotation.
The only cost to this is the additional budget spent on printing more parts. It ended up stabilizing the dispenser a lot, so we think it is worth it.
- Provide an updated schedule if changes have occurred.
Same as last week’s plan.
This Week’s Special:
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.
- Card dispensing
We performed simple success/fail testing on the card dispenser. For seamless gameplay, we wanted to ensure it achives 100% dispensing success rate, but even after several iterations of design/methodological changes to the dispenser, it still fails to achieve 100% success rate. Most of the failures are coming from a combination of variabilities from the printed parts of the dispenser, causing unidentifiable subtle inconsistencies.
- Rotation
We also tested that the machine rotation achieves the angle we configure. This was rather a simple test that made sure the servo was functioning well to rotate the machine and found out it does perform this task well.
- Card detection
We tested that the model detects the card well when situated in the exact production environment (i.e. in the dispenser). We figured that with constant lighting condition and fixed position, the model effectively “memorizes” the cards to classify them successfully. We found out that it achieves near 100% accuracy with an average of 95% accuracy.
- Weight Sensor
With prior knowledge of the coin being 11g, we tested if the weight sensor also shows linear behavior when we increment the number of coins on the sensor. While it followed the linear behavior pretty well, suddenly taking off the coins made the sensor failing to scale back to 0g, causing issues in future iterations.
- Tap Detection
Since there are essentially 2 moves the users will make with taps (double tapping and holding), we tested if the detector segregates these two moves correctly. Also, we identified that there were some false positive rates with both, 19% for double tapping and 3% for holding. As such, a tweak in testing method for fixed condition made reliable testing condition and made the false positive rates to 0.