Team Status Report 3/29

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.

 

Andrew’s Status Report 3/29

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.

 

Martin’s Status Report 3/29

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.

Justin’s Status Report 3/29

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.

Team Status Report 3/22

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.

Martin’s Status Report 3/22

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.

 

Justin’s Status Report 3/22

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
  • 1 hour participating in 3D Printing Dispenser Body
  • 7+ hours of game state management
  • 1+ hours on starting on user interface

Key Accomplishments

  1. Completed 3D-print request to CMU techspark. The dispenser body is taking a little longer than expected to get printed. Relatively small pieces like cylinders and gears are printed.
  2.  Completed structuring the Poker game management. Haven’t made much progress with  user interface.

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

  1. Finishing implementing I/O inputs and game state management.
  2. Start testing on dispenser body.

Andrew’s Status Report 3/22

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.

 

Team Status Report 3/15

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

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. 

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

None

  • Provide an updated schedule if changes have occurred.

Slightly behind in combining parts to the machine body. It must be done by next week.

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

DXF file ready to be cut in techspark fablab.