Weekly Status Reports

During this week, I used time on:

• 6 hours of presentation slides + preparation
• 3 hours of presentation + peer review
• 8+ hours on revising + improving the Dispenser Body with Solidworks
• 2+ hours on integrating building circuits for Tap detection (FSR) and Weight Sensor.
• 2+ hours on writing game state management and connecting arduino and raspberry pi (software).

Key Accomplishments

1. Dispenser is almost there to work without any error
2. Circuits for the FSR and Weight sensor are built and ready to be fully integrated.
3. The final presentation is done.

   Next Week’s Deliverables

1. Integrate/test all parts (finish up Game state management)
2. Make Poster/Video/Report/Demo work.

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

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.

 

I spent the whole week with the team trying to get the dispenser to work. The problem was that we needed the distance between the rubber-covered cylinders and the card to be very precise. Too close, the motor got stuck and did not spin. Too far, and the card did not get dispensed (or took too long to get dispensed, as the cylinder only touched the card occasionally).

After rebuilding the dispenser with wood and trying out different things with the motor and the cylinders, we decided to simply remove one of the cylinders and print a new dispenser with new cylinder that can be directly attached to the gear. This way, we could minimize the possible sources of errors.

And today, we were finally able to get the dispenser to dispense cards quite reliably. It still failed sometimes (which we suspect happens because the cylinder is not a perfect cylinder), but we found that we could simply retry dispensing, and it worked.

Now we can finally move onto trying the full game play with the implemented game state manager. Before that, we will need to connect all the inputs and outputs between the programs in RPI and Arduino, but that will not take too long, as we already tested linking the two through USB port and sending/receiving serial data.

This week, I mostly worked together with my teammates on fixing the dispenser. We identified various hurdles compromising our overall progress towards integrating the whole system. On my end, I was able to complete training the model, making it achieve an average of 95% confidence on all the cards. This was very consistent and I was confident that the card detection part of the system is production ready. However, as the dispenser wasn’t functioning well, we went through various fixes that essentially created some gaps between the previous card detection model training environment. While the dispenser is still not perfect, we’re planning to move on to integrating all the components.

Next week, I will have to see if the old model performs well on the new dispenser environment. If it fails to do so, I will have to train the model again by collecting new data on the new environment.

Worked on making the dispenser work all week. It behaves very unpredictably right now, and that is the biggest problem I am facing. When it works, it dispenses the cards very accurately, but when it does not, it simply does not spit out the card (gets stuck). Tomorrow, I am making a last attempt on stabilizing it, and if does not work, I will just move on to the next part.

No time to take pictures,.

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

Since we spent most time on the dispenser and didn’t have much time to work on the other parts, our only concern is integrating the other parts. Specifically, we still have FSRs for user input and weight sensor for chips yet to be integrated with our system. We’re shifting our focus to these along with training the model with the dispenser finally ready.

The biggest problem really, is that the dispenser is highly unreliable right now. We spent the whole week trying to get it right, but it almost seems like it just is inherently unstable.

• 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 originally planned to use motion detector for detecting user’s “fold” move, but due to the time restriction, we might pivot to simply using FSR to achieve that. However, if time permits, we’re planning to stick to utilizing motion detection.

• Provide an updated schedule if changes have occurred. 

We’re currently following the updated schedule from last week.

 

• This is also the place to put some photos of your progress or to brag about a component you got working.

No pictures.

This week, I was able to finally set up the Raspberry Pi and initialize everything (git cloning, installing necessities). Now I needed to collect data for training the model but due to diverse unforeseen issues on the dispenser, I wasn’t able to start doing that until today (April 19). The dispenser had too many parts that couldn’t ensure certainty in its capability or attributes, together as a whole resulting in a non-functioning dispenser. Most of the uncertainties came along with our unfamiliarity with 3D printing. The dimensions and the quality of the product were mostly all out of our expectations, causing more manual effort to modify them in our initial design, which essentially resulted in delays in our timeline.

As such, I’m only left with one day to really test the model, so I’m planning to max out tomorrow to work on it. Next week, my primary focus will be towards preparing for the demo, which would include fine-tuning the model, finalizing design, and finalizing the integration.

Throughout the project, I was able to learn and reinforce many concepts as I was applying many different knowledge and tools. Specifically, I learned how to write code in Rapsberry Pi. This may sound vague, but it pretty much captures the idea. This includes setting up Pi for coding environment via ssh and making correct configurations. Furthermore, I learned how planning ahead and really working towards that goal is an imperative to any project’s success. While we had many obstacles that caused delays in our project, following along the timeline really helped us with getting on track with our project.

During this week, I used time on:

• 4 hours of in-class team collaboration
• 8+ hours on revising + improving Dispenser Body with Solidworks
• 6+ hours on integrating building circuits for Tap detection (FSR) and Weight Sensor.

Key Accomplishments

1. Dispenser is almost there to work without any error
2. Circuits for FSR and Weight sensor is almost built and ready to work by tomorrow.

Next Week’s Deliverables

1. Integrate/test all parts
2. Make Final presentation using 1
3. Make Final video, Final poster
4. Prepare for Final Demo, Final Report (If have time)

The dispenser is only half-functional right now, due the cylinder not moving the card enough with the provided 180 degrees rotation. It does work fine when we manually turn the cylinder to the exit, so we just need to give the cylinder more rotation. We are either going to be using a 360º servo instead or use down-sized gears.

Since using a 360º servo defeats the purpose of using a servo in the first place (as it is now closer to a dc motor instead of a servo), we are leaning towards using compound gears. We already have the stl file ready, so we just need to send it to the fablab to be printed. While that is going on, we can work on other parts (like integration of other hardware parts and the software).

 

We found out that the shuffler we have does not feed in cards to the dispenser smoothly, so we decided to just remove it from the machine. It can be simply put next to the machine, which will require the users to manually move the shuffled cards to the dispenser, but it will solve many other potential problems, like the center of weight being not uniform.

This gives more space for the dispenser, and most importantly, allows it to be aligned more to the right, as we do not need to care about the shuffler anymore. This will make it easier for the RPI camera module to be connected.

The second change that we are considering is that instead of motion detection to detect fold, we might want to use FSR to detect check and fold by distinguishing between double tap (check) and a longer push (fold).

The machine body is almost fully functional. We just need to make a slight fix to the dispenser, and it will work as we expected.

Validation:

For validation of the ACE machine, we haven’t run any tests specifically for its entirety. 

We will check that player experience in automation feels as seamless as possible. The parts that could be automated should work on their own without the need of human touch.

We will conduct beta tests with a few people to see if they feel like the machine does a good job of replacing human dealers to a reasonable extent.

Last week, in preparation of the demo, I was able to verify that the card detection works on a dummy data. Dummy data here refers to the images of the card captured not in the exact deployment setting. But through this, I was able to verify that the model’s memorization capability is good. While the testing on the dummy data involved some variables, such as different lighting and card position, I’m confident that we will have more certainty and less variability when using the real data. Since the card’s position, camera’s position, and lighting will be fixed, there will be less variability in the training data and let the model effectively overfit on the data and memorize them.

This week, I primarily worked on setting up the raspberry pi. While sshing into pi in my room’s WAN setting worked, I’m still struggling in sshing into pi in the school’s network setting. I tried several different methods in this, but found it difficult to make it work. I was pretty persisted in trying to make it work in a headless setting, but I figured it will be better and definitely more intuitive to have a monitor connected and edit configuration file while on school WAN. As such, I ordered a hdmi to micro-hdmi cable that will help us connect a monitor to raspberry pi.

I’m on track in terms of the CV part of our machine. However, I’m a little bit behind in terms of integrating all parts together.

In this coming week, my goal is to make the model work on the deployment setting, work on motion detection, and connect everything together.

Verification:

I will need to verify that the card detection achieves 99.9% accuracy. This is an imperative for a seamless gameplay. While it roughly achieves good accuracy on the dummy data, I need to ensure it also does on the actual data I will use for the model.