Week 5 Status Report – Chris Reed

This week was a particularly busy one for me coming back from Spring Break. I was able to test out our motors that we will be using for the shuffler and dealer, as well as tweak a few final things in our Solidworks model to get the shuffler and dealer encasing ready to 3D print.

Next week, when I have more time to be in the makerspace, I want to 3D print and construct the dealing trays/shuffler top unit so that we will be ready to install the motors and start putting things together. I will also be testing the RFID cards and writing their values now that Eric’s card reading driver is coming along.

The schedule is doing fine, but next week we need to make progress on our dealer prototype so that we have time to make adjustments and calibrate with the deck of cards.

Week 4 Status Report – Chris Reed

Early in the week I worked on our Design Review paper along with my teammates. I also completed my ethics assignment.

I worked on putting together our finalized Solidworks model of the Shuffler/Dealer that Mark and I designed. We are going to go into production of our prototype once break is over, now that we see how our parts all fit together. There is a picture below.

Since we needed to focus on the Design Review and other classes before break began, Eric and I did not get to encoding our cards yet. I did, however, apply all of the RFID stickers to one full deck of cards so that they will be ready to go once we have the code to write on the tags.

I had to modify my schedule a little bit since we could not encode our deck of cards this week. But this does not affect the schedule that much, because once we have the cards encoded that aspect of the project will be completed. Since next week is Spring Break, we built in some slack time into our schedule. Once we get back, we’ll be encoding the deck of cards and testing those, as well as starting to build our shuffler/dealer.

Week 4 Status Report – Team

The most significant risk of the project is still the shuffler and dealer, for the aforementioned reasons. We have a good Solidworks model, but hooking it all up will be challenging. Another risk is trying to hook up all of the components together with our Raspberry Pi. Since our components are not finished yet, we have not been able to write or test the code that runs all of these things yet. We are still on schedule for that though, so we will just have to come to that hurdle when we are scheduled to.

There have been no changes to the design of the project or to the schedule.

Week 3 Status Report – Chris Reed

This week on the project, I worked on incorporating the dealer tray I designed last week into the full shuffling/dealing apparatus, as well as setting up the RFID Reader to test if and how it works.

After some discussion about the dealing apparatus, Mark and I decided it would be easier to have the automatic dealer be the thing that rotates towards each player’s tray to give them a card. Mark will be designing the dealer, while I worked on modifying my dealing tray design to have supports on top where we can place our shuffling device. I designed small pillars and an upper platform where I will be able to position the shuffler on once the final design for the automatic dealer is done and I know where exactly we need to feed the shuffled cards into. I have attached a picture of the Solidworks model for the dealer tray/supports below.

Now that all of our parts were in, Eric and I started to set up the RFID reader/writer with our Raspberry Pi Zero. As Eric installed all the necessary libraries on the Pi, I wired up our RFID reader to the Pi and put one of our extra RFID stickers on a spare playing card I had. After adjusting where the card was and making sure all the wiring were plugged in tightly and correctly, we started detecting the RFID tag through the playing card when it was placed near the reader. I have attached a picture of the initial set up below.

As of right now, since we modified our schedule to not waste time waiting for parts to come in, we are on schedule. Next week, we have a few goals we want to reach before we all leave for spring break so that we can remain on schedule. For the RFID playing cards, I want to be able to work with Eric to write code on the Pi that will allow me to encode the RFID stickers with the encoding scheme I came up with for rank and suit, so that we will have a fully encoded deck of RFID cards to work with. I also want to coordinate with Mark to have a full Solidworks model done of the card shuffler/dealer before break, so that once we get back from break we can get to work on constructing our prototype.

 

Week 2 Status Report – Chris Reed

This week for our project, since we were just starting to get parts in, I decided to focus more on the design aspects of the project. I created the numbering scheme that we will be writing on all of our RFID tags, as well as creating our Solidworks model of the rotating card tray we’ll be dealing into.

I solidified our bit numbering scheme for our RFID tags for each playing card to make it easier to recognize each card’s bit code when we were detecting them. The last 4 bits encode the rank of the card, while the two before that encode the suit. I have attached a picture detailing the exact bit code for each card below. Once our RFID tags come in, I’ll stick them on each card and start working on writing each of their codes.

I also created a design and Solidworks model for our dealer base, which we are considering 3D-printing to produce for our project. I first drew up a diagram of the rotating base, including six trays for the cards to be dealt to (four for potential players, one for the community cards and one for the burn cards). I then made a one-sixth model on Solidworks which I then expanded into the full 360 degree part. Once we solidify how we are putting the shuffler together and dealer on top, we can easily attach this bottom part to it. It is designed so that our dealer will only have to deal in one direction, and the appropriate tray will rotate to receive each card in the proper order. I have attached photos of the one-sixth model and complete dealing tray below.

Our project is on schedule. Due to parts coming in this week, I had to move up the design of the dealer to this week, but our schedule is very flexible for what parts get done when as it is comprised of a bunch of individual parts that do not depend on each other.

Next week, since our RFID tags and reader will be in, I will focus on hooking up the RFID reader to the Raspberry Pi Zero with Eric so that we can set up the card detection once we encode each tag with the bit code we want.

 

Design Diagrams Week 2

Week 1 Status Report – Chris Reed

This week for our project, since we had just finished our project presentation, we moved our focus onto getting all our parts for the project. We all worked together to start finding cost-effective options to purchase everything, so we could start testing our devices. I was tasked to find the parts for the RFID card reader and the physical materials we’ll be using to make the playing area itself. After looking up some examples of RFID playing cards and seeing that a pre-made deck would be too expensive for our project, I moved to our second plan of placing RFID stickers on the backs of a regular deck of cards. I coordinated with Eric to make sure that the components we found would be compatible with the Raspberry Pis we wanted to use. After looking through many options on Adafruit, Amazon and other websites, Eric found some RFID stickers on eBay that were a much cheaper option. I found very cheap cards on Amazon, along with a set of poker chips, as well as a mousepad that we wanted to use as the playing mat and install all our components into.

As we were looking for our parts, I took charge in making our bill of materials, so that we could get a head start and help keep track of all the prices and quantities that we needed for everything. I broke it down by requirement, and listed the materials, quantity and cost of everything. As everyone found their parts, they would send it to me for documentation and I was able to calculate our total cost to make sure we were within our budget.

Once we saw that we would be within our budget, I started submitting parts to order to Quinn so we could start putting things together next week. I submitted orders for the Raspberry Pi Zeros, the Current sensors, the E-ink displays, the RFID Tags and reader/writer, the playing cards and poker chips.

I am on schedule with our project. If our parts start to come in next week, we’ll be in a good position to start creating our custom chips, displays and RFID cards and test them. I’ll be creating the numbering scheme for the cards next week once I get the tags and can see what I can store in them. I also want to be able to hook up our RFID reader/writer to the Raspberry Pi with Eric so I can put the tags on our cards and start assigning them their bit values according to their rank and suit. I will also start working a little more in depth with Mark for the design of our shuffler and dealer. I would want to make a CAD model of the whole device so that we can order the motors for it and start prototyping.

 

Week 1 Status Report – Team

The most significant risk that is going to jeopardize our project’s success is attempting to build the card shuffler and dealer. None of the members of our team have extensive experience with electromechanical work, so making sure that we create a good apparatus and hook up all of our motors, gears and wheels to correctly move the cards around may be more difficult than we anticipate. We have been researching other people’s projects online who have tackled these tasks in search of inspiration and guidance on how to go about designing our mechanisms. We will also be taking apart an electric card shuffler that we already own to see its inner workings to help with our design as well. We have a couple of contingency plans in place. If we cannot get either part to work, we could always just purchase an automatic card shuffler and deal manually, but that takes away a big component in our project. If we get our shuffler to work but not our dealer, we can also deal manually. If only our dealer works, we could either shuffle manually or purchase a card shuffler and then place the shuffled deck into the automatic dealer to get the game started.

Instead of using an RC circuit and measuring the discharge time to figure out our resistance for our chip detector, we chose to purchase current sensors we can hook up to the Raspberry Pi because they are much more accurate. We will be shifting the schedule around a little bit due to the parts that will be coming in next week. There is somewhat more work associated with this approach, as the current shunt we have chosen is an I2C device. This means we will need to find an I2C library for python or write the code ourselves in C. There are a number of good I2C libraries available so this shouldn’t be too much of an issue. The current shunt also costs more, but less than $10, and we only need one per play area.

Eric will be writing the game components this coming week as opposed to a week from now because we don’t anticipate getting the parts we’ve ordered this week. This will allow us to stay on schedule and begin writing code for the sensors once we receive them and the Raspberry Pis.