Posted on

Week 2 Status Report- Mark McKinzie

Individual Status Update

This week my primary goal was to fabricate an initial prototype for the embedded resistor poker chip and to design a CAD model of the shuffler and dealer prototype. Since the poker chips we ordered did not arrive this week I was unable to fabricate this prototype.

Due to this delay I focused more on the CAD model and selecting mechanical and electrical components which will be used to drive the automated shuffler and dealer. There are RC wheel 360 degree servo motors which come with attached wheels with rubber tread, which will provide a simple dealing mechanism, dealing from the bottom of the deck of cards. to shuffle the cards, high speed DC motors will be used to drive two sets of gears, one to grab one card at a time and push it towards the shuffling area, and the other to push the cards together in the shuffling area. I observed this gear design in existing shufflers which will provide better interleaving results than a system with only one pair of gears. The shuffler model is displayed later in the post, and Chris has the dealer model in his post.

The motor driver used to drive all of these motors will be the L293D, which can drive two DC motors each and one servo motor each, so we need three, one for dealer rotation, one for card dealing, and one for the two high speed DC shuffling motors. I will work with Eric to ensure he is able to write software for these motors which will integrate with the rest of the game environment

I am on schedule for the playing area and the shuffler/dealer. However to catch up on the poker chips I will fabricate and test the initial prototype so I can move onto finalizing the design in a couple of weeks.

Next week I intend to CAD a model of the full playing area, as we will know the physical design for all components in the playing area. I also will fabricate the poker chip prototype for the $5 chip and test this prototype. If that goes smoothly I will fabricate the $50 and $10 chips.

 

Posted on

Week 2 Status Report – Team

At this point we do not feel that or risks have changed significantly. We’ve all made progress in our respective areas, and we still believe we’re on track to finish with some slack. The details for the shuffler and dealer are being worked out, and as we make more progress in that area it should become clear whether or not it will become a roadblock. If it does our contingency plans remain the same.

There were no big changes made to the existing design of the system this week. We all worked more on a final (for now) design for the design review, but this was largely detail work and did not involve any large scale changes.

Going in to next week, our schedule remains the same.

Posted on

Week 2 Status Report – Eric

Work Update

This week my primary goal was to create an overarching design for the software, encompassing both the embedded platform, as well as the central computer. Last week I selected hardware components and began finding software libraries. The work this week built off of that, isolating the software we will need to write from scratch and forming a cohesive architecture.

Last week I found an e-ink screen that was controllable using SPI. I also selected a python library for SPI that I felt would provide a good base for our code. Going forward we will need to write a driver for the screen that is built on top of the SPI library. I spent some time last week going over the docs for both the library and the screen, and preparing to write the driver next week once all of our hardware arrives.

The process for the RFID reader/writer was almost identical to that for the e-ink screen. Again, we will need to write a custom driver on top of the SPI library I found last week.

For resistance measurement, we will need to write a driver on top of a different library—one designed for I2C communication instead of SPI. That shouldn’t be significantly more difficult.

On top of the different sensor drivers there will be a game coordinator layer. On the embedded device this will get the current game state from the central computer, and use the sensor data to update the screen. It will also be responsible for deciding which pieces of data to communicate back to the central computer.

Finally, on top of the game coordinator will be communication layer, built on top of gRPC. This will be a thin abstraction layer so that if we have to make communication changes (e.g. moving to a wired network or USB) we can make them to an isolated part of the system.

For the central computer, there will also be a game coordinator. It will be driven by a state machine representing the game, and take input from each of the player areas. It will send current game information to the player areas, as well as the web server described below. It will also drive the shuffler/dealer.

The audience and player views provided by the central computer will be web-based. There will be a web server (likely Flask) that pulls data from the game coordinator, and serves two different web pages with real-time data.

One thing I have not yet planned is the shuffler/dealer driver. I need to work more with Mark to establish the electrical design of the shuffler/dealer before I can figure out the software.

Please note that the finalized diagram will be presented as part of our design review this coming week.

Schedule Update

Progress is on schedule. As noted during the weekly meeting I swapped this past week with this coming week to accommodate the delivery schedule of our components. Next week I will writing the sensor drivers for the sensors that we currently have.

Posted on

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

Posted on

Week 1 Status Report – Eric

Component Selection

One thing our team as a whole focused on this week was choosing the correct components for our project. I personally worked on the embedded platform, as well as the specific sensor components for both RFID reading/writing and resistance measurement.

We had already chosen to use a Raspberry Pi Zero for our play areas, and after briefly reviewing the models, I decided that it was worth the extra money to get the newest version with built in wifi. This will allow all the components to communicate wirelessly which will give us a better form factor. It also means we don’t have to worry about using a switch.

I researched e-ink screens and chose one that we could use with the Pi. We needed a screen that was controllable using SPI, and simple enough that I could write a driver for it in a relatively short amount of time. I looked at a number of options that were available in “hat” format, meaning they fit over the Pi, similar to an Arduino shield, but ultimately decided that a naked screen would work best, and allow us to fit it into our play area better. I was able to find one designed to be used with the Pi.

For RFID reading/writing, I looked at projects people had done with a Pi/RFID and noticed that they primarily used a single RFID chip. I researched that chip, found that it would fit our needs, and was able to pick an appropriate module that used that chip. I also assisted Chris with finding cheap RFID stickers that were compatible with the chip (a surprisingly difficult task).

For resistance measurement, our initial idea was to use an RC circuit and measure how long a capacitor with a known capacitance took to charge to a certain level. We could then calculate resistance of that circuit. However after reading more about this method, I had doubts about its accuracy. Instead, I found that there are devices called current shunts that measure current. I was able to find one with an I2C interface that I’ll be able to read using the Pi.

Software Research

Finally, on the software side I began creating a general design, and looking for python libraries to perform the low level tasks required to interface with our sensors and other peripherals.

Once the design is finished (at the beginning of next week) I’ll be able to include a diagram in my status report. Ultimately it will be difficult to evaluate the software libraries until I begin to use them with our hardware, however I chose hardware such that there were multiple library options. Also, in the worst case I can directly write the C to do both SPI and I2C communication.

My progress is on schedule, and I believe our progress as a whole is as well. Finding parts took somewhat longer than we thought but we aren’t off track. We also all have work we can do while we wait for the parts to arrive, which will help to keep us on schedule.

My main deliverable for the next week is a complete diagram of the architecture of the software. It will include the play areas, the central computer, and how they will it be networked together, and it will inform my design for the rest of the project.

As a secondary deliverable, I would like to have written the main game components of the software. This will largely be a state machine for the game and associated code. This was initially planned to be completed during week 3 but in the absence of our parts I will work on it next week.

Posted on

Week 1 Status Report – Mark McKinzie

Mark McKinzie – Team C8

This week I researched which parts we would need for the chip value detection system. This included choosing resistor values corresponding to the chip values which were chosen as follows $50 = 2kOhms $10 = 10kOhms $5 = 20kOhms These high resistance values were chosen in order to reduce the error in calculated chip value. The most necessary part to order was the poker chips themselves, I chose a basic plastic chip, but if necessary we could potentially 3D print custom chips based on the CAD model I created. Though even if we use the premade chips, our resistor embedding will look like the CAD model anyway. In addition we purchased some current sensors which will make chip value reading much easier, with the raspberry pi zeros, only needing to use the voltage into the chips and out of the chips and the current value measured by the sensor to know the total resistance and thus the total chip value.

For the play area we looked into purchasing a mat, but decided not to do that yet, before having all the components which need to be inserted into said play area.

For the shuffler and dealer I looked into examples of automated shufflers and dealers to see which gears and motors would be needed. Since we will probably 3D print or assemble our module out of acrylic, I did not research form factors yet, as that will depend on how the motors, gears, and wiring all fit together. Small high speed motors will initially push the cards together to shuffle them as well as eject cards from the dealing part of the module, whereas a higher torque servo motor will handle the rotation of the module to allow dealing to certain areas. Since only the servo motor requires PWM and the high speed motors are simply run by DC it will run easily from the Raspberry pi. I researched gears for the automated shuffler but could not get any definitive measurements, so this coming week I will order a gear set with many different sizes so I can experiment which of them work best for optimal performance while still keeping the model as small as possible, however I feel I am in a good place knowing what will be driving the module.

I am on progress as I have created a model for the chip and chosen resistance values, so the next step is prototyping, which is what I intend to complete next week. For the play area we are a little behind not having chosen a form factor, but I am confident I can decide that as well as making the CAD model next week. For the shuffler and dealer next week I want to order the gears and motors so the following week Chris and I can begin prototyping.

Posted on

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.

 

Posted on

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.