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.

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.

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.