Google Slides:
https://docs.google.com/presentation/d/1pewOBJGKAw8ZmDTP7iZefQU61l65CuS7oN7bHG4oyPU/edit#slide=id.g3466c71b45b_0_6
or
PDF: Demo Slides
Carnegie Mellon ECE Capstone, Spring 2025 – Andrew Kim, Justin Kim, Martin Lee
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:
Key Accomplishments
Next Week’s Deliverables
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.
This week, I had to make a major revision on my codebase, since in the previous implementation, I completely forgot that we had to deploy the model to read in data in real-time and rather had the model read in images for data. This meant that I had to change the model to extract features and read data in real-time video processing instead of on static image data.
I’m a week behind in terms of what I had to achieve– I had to deploy the model on raspberry pi. However, the issue stems from delivery issues, so this was quite inevitable. As such, to mitigate this, I will have to devote some good amount of time once we get the SD card and make 2 weeks amount of effort.
Now, the model is designed to work on real-time streamed video. However, since we haven’t been able to gather training data for the cards, I was not able to test the model. The next step I’m thinking is maybe I could train and evaluate the model on dummy data so that we can see if the basic object detection is working. Subsequently, once I’m able to gather the training data, my plan is to train and evaluate the model to detect and classify the cards that can be deployed in the dealer system.
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:
Key Accomplishments
The project is getting a little behind of the original plan: 3D printing is taking more time than expected, and Implementing the game state management and user interface is also taking more time, but it is not a huge concern, given that our original schedule had a massive slack time. In addition, I can put more time next week to finish everything before the presentation week.
Next Week’s Deliverables
This week, I cut out the main machine body of ACE, made of mdf. After consulting with a person working in Techspark, I realized that the thickness of does not need to be overly thick. So, I decided to use a 3mm mdf, which significantly reduced the overall weight of the machine. So, I think we can continue using the motor shield we have for now.
I have confirmed that the machine does spin properly, within the latency bound we have set as the design requirement. Right now, I have temporarily put the pieces together in tape, but they will soon be glued together. Once the dispenser gets printed, we can try placing it on the designated space and see if everything works out.
Roughly on schedule, with some parts ahead and some parts behind. It was unexpected that our order for the SD card got canceled.
No special risk at this moment. However, since our project requires a combination of many components. All parts must be prepared on time to have enough slack time.
None
Slightly behind in combining parts to the machine body. It must be done by next week.
DXF file ready to be cut in techspark fablab.