Posted on

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.

Posted on

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.

Posted on

Week 4 Status Report – Mark McKinzie

Early this week I worked on completing and editing the design review document. In addition I completed my ethics case study assignment.

Due to the setback on the poker chip construction we needed to order new chips and they did not arrive this week so I was unable to complete any work on that aspect of the project.

Chris and I completed the full Solidworks assembly of the shuffler and dealer combined module. The picture of that will appear in his report.

This week was not hugely productive but that owes to the fact that I had a midterm in 18-491 that spent much of my time studying for.

Next week I plan to fabricate 3 poker chips, one for each value: $5, $10, $50. I also plan to flesh out the specifics of which parts of the shuffler will be 3D printed and which will be manually fabricated. If time remains I will build a play area contact for the chips.

Posted on

Week 3 Status Report – Eric

Work Update

Last week I worked on finalizing the architecture of the software. I mentioned in my blog post that the block diagram was not yet done, but would be finished for our design review presentation. It encompasses all of the software and the hardware components that it needs to interact with.

Along similar lines, I also worked to complete the slides, as well as develop my presentation for, the design review. As when I helped craft the proposal presentation, I wanted to create a presentation that told a story. In that case we wanted to have a compelling narrative around bringing professional features to the home game. We wanted to have the same points here, but told through the lens of a development story. The goal was to lay out how we were going to bring the experience to life. I also spent a significant amount of time practicing in advance of actually giving the presentation.

Also this week, I went through the process of setting up one of the Raspberry Pi Zeros. This included work to burn new SD cards with the latest versions of Raspbian, set up SPI and I2C, configure networking, enable persistent access, and more. I then worked with Chris to build out a small circuit to prototype our various sensors.

Once the Raspberry Pi was set up, I began working on drivers for the RFID reader and current shunt. I began by using a high level library to interact with them and verify that they were functioning as expected. I then began to write our custom drivers on top of the libraries I mentioned in a previous blog post. This work will continue into next week.

Schedule Update

Progress is still on schedule. Preparation for the presentation took more time this week than I anticipated, however I still manage to make good progress on the drivers. Next week I will finish them, and being working on the e-ink display drivers.

Posted on

Week 3 Status Report – Mark McKinzie

Mark McKinzie – Team C8

This week I as well as working on the design review document, and giving feedback to Eric on his practice design review presentations, I worked on designing the dealing module of the automated shuffler and dealer. As seen below it is a card tray mounted on a cylinder which will be rotated by the servo motor and wheel on the bottom. In addition I cut out a piece of the cylinder in order to accommodate the servo and wheel which which physically deal the cards. This will fit inside the tray that Chris designed and will have the shuffler from my report last week on top of it.

In addition I worked on fabricating the custom poker chip with embedded resistor. As is displayed below I drilled into the chip 4 times to create a slot for the resistor to fit in. However I hit a roadblock when I discovered the chips we purchased have a metal plane inside the plastic exterior of the chip. When I soldered the resistor into the chip and measured the resistance on either end of a 20k resistor and read 0.2 ohms. The good news is drilling and fabricating this chip did not take me much time, and it will be even easier to drill through a purely plastic chip. The bad news is we must obtain different chips to work with and that will take time.

Progress is on schedule for the shuffler/dealer and next week Chris and I plan to merge the three designed assemblies together and have a final design to present. Progress for the poker chips is behind, but I can catch up next week simply by fabricating many chips, as I know the method of fabrication works, even some of our construction is faulty. I hope to have 1 chip of each value fabricated next week, as well as fabricating one contact for the chips which will rest in the play area.

Posted on

Week 3 Status Report – Team

Team C8

The most significant risk of the project remains the shuffler and dealer. This risk is being managed by modularizing the shuffler and dealer, so that even if the shuffler or dealer does not work, the other aspect will not be affected, but in the successful case in which they both work, they are designed to work together. However if neither work, it is not hugely detrimental to the central poker experience which our project aims to create.

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

Posted on

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.

 

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.