Weekly Status Reports

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.

During this week, I focused on three main areas: User Interface and Game State Manager. My time allocation demonstrates a substantial commitment to the project, meeting the expected minimum of 12 hours:

• 4 hours of in-class team collaboration
• 2+ hours on revising + printing  Dispenser Body with Solidworks
• 4+ hours on integrating Dispenser Body into the machine body
• 2+ hours on discussing problems and next week’s plan.

Key Accomplishments

1. Completed final draft for Dispenser + integrated/tested. Final change to the gears must be made for servo part.

Next Week’s Deliverables

1. Implement and test FSR (Force Resistive Sensor) for Tap Detection (check & fold)
2. Implement and test Weight Sensor for coin counting (Raise)
3. Integrate all parts, validation & verification
4. Prepare for Final Presentation

Lots and lots of CADs and laser cutting.

All the small misalignments between parts have been fixed using wooden pieces joined together with joints and hot glue. For example, initially, we decided to stick all parts onto the machine permanently, but we discovered that it would be better to have them be detachable. So, I made a detachable wooden case for each of them to hold them in place. There are more of these very small changes that were mostly done using laser-cut wooden parts.

This is the semi-final machine body we have for now. It is only half-functional, because the cylinder connected to the servo does not move the card far enough, making it impossible for the two cylinders at the exit to grab it firmly and dispense it. We are going to add two gears (1:1.4) to the servo and the cylinder to increase rotation.

We were actually supposed to be done with this part already, so we are behind schedule right now. Hopefully, the gears get printed quickly, because integrating the gears into the machine should not take long.

I did confirm that everything else in the machine works perfectly fine, so once the servo issue gets cleared, it should be ready to be tested and verified.

We have a lot to do by next week. Hopefully, the RPi and Arduino won’t cause any trouble as we connect them.

 

Verification:

I will need to test the dispensing accuracy and machine rotation accuracy along with their latencies. Both tests have been done roughly, but the full quantitative tests still needs to be done. The size of the machine already meets the requirement of 20.3 cm x 20.3 cm.

Those complete the hardware and machine body side of the requirements that we have set.

Google Slides:

https://docs.google.com/presentation/d/1pewOBJGKAw8ZmDTP7iZefQU61l65CuS7oN7bHG4oyPU/edit#slide=id.g3466c71b45b_0_6

or

PDF: Demo Slides

We’re mostly working towards finalizing the sub-components of the machine. We believe that integrating the components could cause various unforeseen challenges that could jeopardize the success of the project.

We assembled the parts in autodesk fusion 360 to get a general sense of how our assembled design will look like in real life. With that, we were actually able to catch a slight flaw in the design and were able to fix it. We can now use this as a guideline when actually assembling the parts.

One potential problem that we may face is that the gears we printed and the motors may not combine very well. The current plan is to simply stick the gears and servo’s plastic parts together with adhesive, but if that does not stick too well, we will need to find another way to make those work together.

 

Our design plan is concrete for now, and we are sticking with what we have. If we encounter unforeseen problems as we actually assemble parts and integrate systems, then we will definitely need to adjust accordingly, but for now, no change.

 

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

 

Worked on finishing up the cad for the components. I finished up the platform for the card shuffler to sit on and exported the dxf file to laser cut. However, techspark was too crowded this Friday, so I am planning on visiting again tomorrow (Sunday) to cut it and assembled them. The positive side about this delay though, was that I was able to discover that the initial design of the platform had the angle too high and was able to fix it. If we went on with that design, it could have resulted in the cards from the shuffler falling out before they could get shuffled.

With that discovery, to make sure that our design looks good, I decided to assemble the parts in fusion 360 to get the full picture. Since I grabbed parts from the autodesk gallery, some parts are not exactly what they are (like the caster wheels, and the shuffler, which I just replaced with a simple box), but they do a good job of showing us the general sense of where we are going. Now with this as the guideline, I will probably have an easier time assembling the parts together.

 

When I assemble the parts tomorrow, if it looks like how it is here, then we are good. If not, then we are behind schedule, so I will need to speed things up.

 

This week, I completed writing the code necessary for data collection related to card images and implemented the training pipeline for our model. My implementation allows the model to classify cards accurately within the controlled environment we have established.

Currently, our progress is largely back on track. We’re almost done with printing out the dispenser, so after this I will be able to use it to make the model ‘memorize’ the cards by training it on the exact same environment as the actual deployment.

For next week, I should be done with validating that the model memorizes well on any trained data. Since the camera module is here, I will also deploy it on raspberry pi.

During this week, I focused on three main areas: User Interface and Game State Manager. My time allocation demonstrates a substantial commitment to the project, meeting the expected minimum of 12 hours:

• 4 hours of in-class team collaboration
• 2 hours on revising + printing  Dispenser Body
• 8+ hours of game state management and Demo Preparation

Key Accomplishments

1. Completed first round of 3D printing. We found out that the dispenser is too tight to fit cylinders and cards in it. Decided to make some changes to it and requested the 2nd draft of dispenser body. The 2nd draft was completed on Saturday and will be picked up before Demo.
2.  Completed + revised game state management. Started to work on receiving inputs from scale and resistive sensors.

Next Week’s Deliverables

1. Finishing implementing I/O inputs and game state management.
2. Demo Week.

We ordered the sd card for the RPI before break, but it got canceled by Amazon, so we reordered it recently. This has significantly delayed everything related to the main system. Right now we are coding it separately, since we already know it will be written in python.

We planned on using a 7mm mdf for the machine body, but it turns out that 3mm provides enough durability. So, we now have a significantly less heavy machine body, which will decrease stress felt by the servo.

Since we’ve been working on the systems that do not require the delayed parts (SD card), there aren’t any changes required for the schedule.

Machine body printed out.