Posted on

Andrew’s Status Report 2/15

This week, I focused on figuring out how exactly we would implement the machine. I discussed a lot with the team to make a final decision on how we would deal with the input. The rest of the machine stayed about the same as how it was in the proposal. However, the input has changed a lot more ‘realistic’ after taking in feedbacks from our instructor and TA.

The general idea was that using a button takes away a lot of the fun that players feel when playing poker. For example, the act of throwing cards when folding and pushing chips when betting. So, we decided that we would need to use both motion detection and weight sensors to allow the user experience to be as real as possible. It would definitely be a burden on our workload, but we thought it would be manageable as long as the dispenser does not give us a headache.

That is why I searched a lot to see what would be the best motor to use for the purpose of our project and how it should be integrated. Because I have never used a dc motor before (unlike servos, which I am used to), it took me a while to decide which motor would be sufficient. Not too weak, but not unnecessarily strong. Having an unnecessarily strong motor would be a huge down factor for power consumption and weight, so we took some time to decide.

Now, we have all the components ordered, and will be ready to start building.

Since motor control will mostly be PWM, I skimmed through past projects I did that involved PWM and l reviewed the relevant lecture slides (from embedded systems).

Because I haven’t actually coded yet, I can say that I am slightly behind schedule, but I am confident it wouldn’t be too much of a problem, as getting the motors to run is not too difficult (at least, based on past experience).

We recently got our hand in an Arduino, so I hope to start coding in there and connect it to the motors to get it running. Then hopefully, we will get the dispenser case printed and attach the motors.

Posted on

Team Status Report 2/8

At this point, we think our ambition has pushed us to have diverse features, each being quite challenging. Even though we got rid of many components after receiving feedback from the initial meeting, since we strived for seamless integration and smooth gameplay, we ended up including new components, such as player motion detection and resistive sensor. As the complexity was added, we’re trying to split work as efficiently as possible and also start early. In case we’re short of resources(time), we have a set of features that we’re thinking of that are the minimum requirements of our project. As such, if we end up having short of time, we will dispose of those ideas and reinforce our already-implemented features.

We opened the possibility of using a screen as output for communicating with the players. We thought that it may be easier to implement than an audio output. We also narrowed down to work with 4 players at maximum (not 8), which avoid us from struggling with blind spot for using a display as our communication. 

Based on the feedback we received during the presentation, we thought that pressing buttons for check/raise/fold could be tiresome to the players. We’ve come closer to the idea of attaching an additional camera to the machine for detecting raise/fold and putting resistive sensors for detecting checks (double tapping). 

No change in schedule yet. Everything is on track.

Posted on

Andrew’s Status Report 2/8

This week was mostly finalizing the design and preparing for the actual building and coding. I worked on taking in feedbacks from Proposal and deciding on the final design. Then I searched for appropriate parts to use for the design. Then I realized that there was an inventory that we can use to borrow parts. So I checked the list and found that there existed lots of Raspberry Pis that we could use. Unfortunately, there wasn’t an Arduino.

Our goal this week was to purchase parts and do some research, so I can we are on track. Next week, I need to start coding the motor control logic for our dispenser.

Posted on

Martin’s Status Report for 2/8

Personally for me, after I received some feedback on the proposal presentation, I shared my thoughts with the team and we managed to have some constructive discussion. 

  1. Need to have Arduino in addition to Raspberry Pi?

A: Utilizing arduino along with raspberry pi will further empower Raspberry Pi by sharing workload and reducing the bottleneck.

  1. 99% accuracy card detection is not enough

A: We definitely agreed upon this and we also thought it wouldn’t be too hard to make the accuracy 100%, as there are only 52 cards for the model to learn, which wouldn’t be too complex.

  1. Using resistive sensor for player input (player move)?

A: We reached the conclusion to ultimately conform to this suggestion and embrace a resistive sensor for the “check” move. Furthermore, for other moves, we slightly changed our approach and are trying to attach a camera on the dealer system which could track the player’s motion and identify if it’s a “all-in”, “raise”, or “fold”

Created & Prepared for the proposal presentation!

Our team and my own progress is on schedule, where we discussed and finalized the parts to buy and submit purchase orders.

By next week, my goal is to start learning how to make object detection model to be functional on a raspberry pi by referring to online tutorials.