Carnegie Mellon ECE Capstone, Spring 2019: Mark McKinzie, Chris Reed and Eric Sun
Last week I worked with Chris and Mark to build the dealer component. I also started building various parts of the web frontend, and the socket server that will send game updates to the players and audience.
I believe I’m still on track for my tasks. Next week I will continue work on the communication layer between the play areas and the central computer, as well as the motor driver.
This week, Mark and I focused a lot on getting the card shuffler and dealer set up. Now that the final components were printed, we had to work and file down a couple sections that did not work as planned to make more room for our motors to fit in and our cards to go through. We have been setting up and running test circuits with our motors to test the cards shuffling and dealing. We have successfully dealt a card out of our holder with our wheel, but need to work on the positioning of the actual card deck so that the wheel has good access to the deck. We have also successfully gotten the cards to be spit out of the shuffler when we use the motor, but we are ordering one with more torque so it doesn’t get stuck from the weight of the cards on top of it.
Our schedule hasn’t changed much. Mark and I will continue to improve our prototype card dealer and shuffler to have it ready for our demo this Wednesday. Once this is completed, we will start to clean up the wiring and set up of our player area and make an enclosure to more neatly contain it.
This week I made some minor fixes to the chips and chip contacts, adding extra copper tape to the center contact to bring it level with the outer ring contact so the stacked chips will register the correct resistance value.
The bulk of my work was spent on assembling the shuffler and dealer module. We printed the last of the parts and have begun to test the optimal setup for the motors in the shuffler trays and the dealer tray. We needed to file away some of the plastic on the shuffler trays to allow cards to more easily slide into the dealer tray.
Currently the shuffler works with a quarter deck in each tray, so it needs to be run twice for each round, however we purchased high torque motors which will increase the stack of cards up to a half deck on each shuffler tray. The dealer can pull cards from the bottom of a full deck easily, we simply need to optimize the angle which allows a single card to be dealt, rather than for the whole deck to slip out at once.
This week we will finalize the shuffler and dealer construction and begin constructing the play area which will hold the chip contacts, RFID readers, and E-ink displays. Once the demo is over, we will start work on the final presentation.
There have been no design changes and schedule changes this week. Our biggest risk is still the shuffler and dealer, as the chip totaling and card reading subsystems have been completed. However since all parts of the structure have been printed and the motor drivers function we are confident that this risk has been minimized.
For this week’s demo we will show our functioning chip totaling, card detection, and the shuffling and dealing, as well as an audience display.
This week I worked on fabricating more poker chips using the copper tape rather than aluminum foil. When stacked the chips add up to their parallel resistance value accurately, which allows accurate monetary value totaling. In addition I worked with Chris on testing the dealing and shuffling capabilities of the DC and servo motors. The dealer works very well, but some adjustment is necessary for the shuffler because of the low torque of the high speed motors. Possible improvements could be adjusting the angle of the shuffler trays, widening the card gap which prevents the motor from throwing cards outside of the dealer tray, or adding another motor to help start the card movement.
This coming week I will fabricate contacts for the chips which will allow their resistance to be communicated to the central computer and embedded devices. I will also work on putting together the shuffler and dealer and making any design tweaks that are necessary.
This past week I focused on 3D printing the rest of our components we needed for our shuffler/dealer mechanism. I now have the two shuffling trays, one player tray, the dealer tray and cylinder. Attached below is a picture.
This week I need to work with Mark on attaching all of our motors to our shuffler and dealer and putting it all together into one unit. Once we have it all set up, Eric can use his driver code he will write so we can test the shuffling and dealing of cards all put together.
Last week I did some light research and work to prepare to write the motor driver, but other than that was unproductive.
I believe I’m still on track for my tasks. Next week I will work on the communication layer between the play areas and the central computer, as well as the motor driver.
No changes were made to the design this week. No changes to the schedule have occured. As we’ve discussed in past team status reports we believe the shuffler/dealer is still the riskiest part of the project, but nothing has changed to make us think we need to starting working more seriously on contingency plans.
As Chris and Mark get farther along on printing the parts for the shuffler/dealer and setting up the servo motors, we feel more and more confident that it will be completed on time and within spec.
Last week I finished the chip detection driver, and worked on a rough prototype of the e-ink display driver. With the display driver I ran into some difficulty because there are very subtle differences between the models that are not made explicit in the documentation. It was a process of trial and error to get the screen to work, but once it began working it was an easier process to get the rest of the driver figured out.
I ended up using a second library to make generating images for the screen easier. The way an image is sent to the device is as a big two dimensional array of binary values, because each pixel the screen can either be on or off. However to generate text and graphics by hand would be a pain and require a large amount of boilerplate code. Instead I use a two step process. The first step is generating the image using PIL (Python Image Library). It creates a “canvas” that can then be drawn on. It has resources for drawing text, images, shapes, and more. Then the second step is to take that canvas and render it to black and white, and output an array like the one required by the screen. That data is then written to the screen’s memory.
Finally, I wrote some simple code to glue everything together for the demo. It was a simple loop that checks for new cards, checks for new chips, then updates the screen with the results if any are new. While this isn’t the exact approach that will be used for the final game coordinator running in the play area, I hope to be able to reuse a lot of the code.
I believe I’m still on track for my tasks. Next week I will work on finalizing the game coordinator in the play area and building a simple server to test with on the central computer.
This week I fabricated poker chips for each dollar value: $5, $10, $15 using copper tape rather than aluminum foil as a conductive medium. This method of construction was much simpler and much easier as the copper tape adheres to the poker chips and the leads of the resistors, minimizing the need for excessive solder to hold the resistor in place. In addition the dealer tray which will rotate was fabricated in the Makerspace using a 3D printer and holds a full deck and is slick enough that dealing one card at a time from the bottom of the deck is a simple and fast process.
The next step is to test stacks of the copper taped chips and see if the dollar values remain accurate. For the shuffler and dealer we need to print the shuffler trays and then begin assembling the motor and gear system inside the 3D printed system. The schedule is still on track to be completed on time.