Personal Progress
I spent a lot of time working on our design review and talking over some major design choices for our project. After meeting with Professor Mai, we were thinking about creating a hardware accelerator for stockfish. We determined that this would be too much for the time that we have. After that, we carefully looked through all the things we had to and shuffled around the responsibilities. The reason why Professor Mai thought that we should pursue a hardware accelerator is because he wanted more complexity and he thought David should have a bigger chunk of the project. I was struggling a lot with understanding the requirements for the GUI and selecting a suitable starting point, so I decided to turn over that portion of the project to David. I decided to take on David’s original part of the project, which was reading data from the sensors through an ADC, and converting them into a format that the GUI can recognize. I’m also taking charge of the networking portion of the project, which will allow us to eventually connect two physical boards to simulate playing remotely with a friend. This will consists of two pi’s connected via ethernet and running a master-slave model. David came up with the idea of a master slave model, and it means that one master pi owns the game state and logic, while the other slave pi simply feeds inputs into the master pi. I definitely think that these parts of the project better fit my strength and interest in embedded systems so I look forward to it.
I was also responsible for giving the presentation this week. That was a good experience and I hope to incorporate the feedback into future presentations I give. An important point from the questions was that UCI, the communication protocol that we are using to communicate with our chess engine stockfish, doesn’t require different strength magnets because it only takes in positions and assumes that the user started the board in the correct configuration. This is a point that we’ll have to discuss as a team. If we keep the different strength magnets, this will increase the complexity of my code as I will have to keep track of the different strengths. I’m hoping that we can stick to one magnet, so that we can put more effort into the gui and the networking portion, which I think will be more interesting.
Schedule
We’re a little behind schedule because of all the changes that we made during the design review. I hope to have a simple test for the sensor done before we go off to spring break, so that I can start writing the software for the entire sensor array when we get back.
Deliverable
I hope to have an update on the simple sensor test before we head off for spring break.