Author: chunglee

Risks

The most significant risks to the project are if the code to read data from the sensors isn’t completed on time or if the sensors aren’t able to correctly determine whether the pieces are on the board. These components are critical to the project, because it would be bad if the game isn’t able to correctly detect where the pieces are.

To manage this risk, we have been working quickly to test individual components. We just confirmed that the hall effect sensor can work with the pi, so we will start to add additional sensors with a multiplexer to prove that the system can correctly read inputs sequentially from multiple sensors. We are looking at alternative options just in case certain components don’t work or function differently than hoped, but the general idea is to work quickly so that we have enough time to address issues should they come up.

Changes to System

None

Changes to Schedule

None

Personal Progress

We were finally able to get the hall effect sensor connected to the raspberry pi. There were a few hiccups on my end with getting the pi set up and the necessary modules downloaded, but we we were able to get it done. The pi can successfully read inputs from one sensor. The next steps will be to add more sensors, connect them to a multiplexer, and read from them sequentially. Ultimately, the pi will have to read from an array of sensors that represent the individual pieces of the board. I hope to have the code for reading the array of sensors done by the end of the week.

I tried to get the pi to run headless without a monitor or keyboard so that I could work on the project anywhere, but I ran into issues with configuring the pi and had to table this until a later point. I have access to monitors and keyboards in the ECE labs as well as at home, so this should be fine.

Schedule

We are slightly behind schedule because there were a couple hiccups with setting up the pi, but it is good that we were finally able to get that done. As long as I stay on track and complete the code for reading multiple sensors soon, I think we should be good to stay on schedule.

Deliverable.

I hope to have the code for reading from the array of sensors done by the end of next week.

Personal Progress

The design review report took a lot of time. I realized that this was really the first time that I had to fill out extensive design documentation like this. There were segments in which I realized that I was repeating myself or not really answering the question to the level of depth required, so I had to revise the sections that I wrote sometimes, or Austin and David helped me. Writing the report definitely made me think more about the details of our project and how everything would come together, so it was a helpful process.

We realized that we hadn’t ordered an SD card for our project so I ordered one to my home and it should arrive soon. Once I install the OS, I plan to set up Ethernet communication with the pi for ssh, make sure that python runs smoothly, and start looking at code for reading inputs from the sensors. I hope to have all this done before the end of spring break.

Schedule

After I set up the pi during spring break, I hope to start looking at code to read inputs from the sensors. Once this works, I’ll start looking at controlling the muxes with the pi. The plan is to switch between reading from two sensors by the end of the week that we get back from spring break.

Deliverable.

By the end of spring break, I hope to have the pi set up for all the things that we need in the future like python, ssh, ethernet, etc.

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.

 

Personal Progress

My focus this week has been identify the appropriate gui for our smart chess board. I narrowed down the requirements for the gui by creating a very simple sequence for the workflow:

1. Player picks up piece, triggers sensor
2. Sensor data goes to ADC
3. ADC data is processed by pi, sent to gui
4. gui receives position, sends UCI (Universal Chess Interface) string to stockfish chess engine.
5. stockfish processes the potential moves, sends data to led lights
6. lights light up, indicating possible next moves/suggested next moves

Therefore, we need a customizable gui that’s capable of interpreting sensor data as a position, and generating the appropriate uci string to send to the stockfish engine.

I feel that it took a lot of time to reach this point because there is a lot of complexity behind chess engines and gui’s that I was not familiar with. I wasn’t sure what the underlying protocols were between the gui and the ai/chess engine. This critical link will allow us to translate movement on the board to a format that the chess engine will understand, so I felt that it was important to get this correct.

I’ve looked at several different chess gui’s, but I have yet to identify one that will support uci and allow us to use different inputs, since we are not using a keyboard but we are moving pieces on a physical chess board. There will be a learning curve, but the goal is to have a solid candidate and a backup by the end of next week.

Schedule

I’m a little behind schedule, because I hoped to have the gui selected by this week. However, I’m starting to realize that the requirements for the gui are more complex than I previously expected, so it’s taking more time than I hoped. We have built in a buffer into our plan, and I have a good idea of what I’m looking for, so I hope that I will have this part of the project done soon.

Deliverable

I hope to have a gui selected by next week, along with an appropriate back up if the gui turns out not to meet our requirements.