Team AC: Smart Chess board

Austin Milford-Rosales

Week 4

This week, I ended up spending a decent amount of time finishing work on the design review document.  However, my primary goal was to test the functionality of the sensors and to try and develop the circuit for an individual square.  The datasheet had two separate suggested designs that either involved a single capacitor or two capacitors and a resistor. I started off with the simpler one since if it works, then I won’t have to do as much soldering for the two boards.  Since Chris is still working with the ADC, I used an arduino uno with analog pins to read output from the sensor, and went with the more basic circuit initially. It was able to output clear values to the serial monitor, distinguished between polarities as advertised, and when I placed a magnet in an adjacent spot (like where an adjacent square would be), the serial output indicated an output from the sensor around an order of magnitude less than when the magnet was directly above the sensor.  It was ranging on a scale from around 100 to 500, and the sensor is supposed to output between 0 and 2 volts. As a result, although I now know the relative differences between various levels of output from the sensor based on different magnet placements, I still do not know the total voltage outputs based on magnet placements, and will try and have that determined by next week. I am very glad that the magnet does seem to work well, I was very concerned last week that I had made a critical mistake.

Over the course of the next two weeks, I am hoping to get more work done on designing the chained sensors so that I we can test multiple sensors with the ADC.  Initially, that will just involve a few sensors on a breadboard, but hopefully I can design a more expansive test to go through before it comes time to actually solder the pieces together.  I also need to spend some time with the ADC datasheet and the mux datasheets to make sure that I know the appropriate voltage levels they can take in, since I don’t want to blow out any components.  I am roughly half a week behind right now, and hope to catch up over the next week or so. I have the basic circuit working, but until Chris and I get the ADC and the pi working together, I am uncertain how much more of what I can do with the Arduino will translate to the final project with the pi.

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.

 

One of our top risks right now is the functionality of the hall effect sensors.  They arrived this week and Austin will be running tests with them tomorrow.  He discovered that he may have made a miscalculation in regards to the magnet strengths, so there is a slightly higher risk going into the testing that we might have to redo the squares.  He went back and did some more calculations to determine the next best magnets to get if the ones we got don’t seem to work.  In addition, we have begun to explore the possibility of keeping track of pieces in the software, based on the assumption that the users set up the board correctly at the beginning of each game.  Because this would greatly affect the complexity of the project, we are currently considering it as a viable back-up if the sensors struggle to differentiate between the different pieces, and will have a further update on this next week.

Currently the FPGA work is on the backburner. David will focus most of his attention towards getting the basic board up and running asap. The stockfish integration is still being hashed out, so depending on these next couple of weeks, we’ll have a better idea if its a feasible goal. The evaluate function of stockfish is the most computationally expensive in terms of CPU time, so that would be the first place to start accelerating stockfish specifically. This is a place that other accelerator’s have neglected, so it would be a relatively novel implementation.

Since we ended up reversing much of the changes we discussed last week, we are back to looking towards a very similar schedule to what we originally discussed, and are planning on sticking to the schedule that is on our presentation.

I put FPGA acceleration on the backburner for now. I’m hoping to use my time doing my research with Professor Lucia as a way to get some early experience using the fpga board I currently have in possession. Currently, my time is mostly concerned with how exactly we lean on stockfishes functions. Using dead reckoning with the magnet’s is the simplest (and therefore probably correct) idea. But then the magnet circuit becomes a somewhat glorified RFID system.  My oversight of the stockfish integration with the multiple magnet levels concern’s me to be honest. I feel like my novelty seeking behavior caused me to ignore parts of our project. I’ll need to put in more time thinking about our design.

Schedule

We’re on schedule. My task list is probably a little conservative and needs to have dependencies with the sensor input. In the meantime I have a good understanding of Stockfish’s high-level architecture, so I should be able to knock out a significant amount of tasks and help my team mates.

Deliverable

I want a full end-to-end test running on the pi by the end of the week, hopefully incorporating some jury rigged sensors.

Status Report

Austin Milford-Rosales

 

My primary goal at the front end of this week was to finish the hardware sections of the slides and effectively communicate that knowledge to Chris (our presenter) to make sure that the presentation came out well.  After starting work on them last Saturday, I continued on Sunday, making the block diagram in powerpoint (since my hand drawings are pretty bad and revising slides to communicate our goals more effectively.

In addition, we spent a fair amount of time working on finishing the definition of our project.  The previous week, Professor Mai had suggested adding in some FPGA acceleration of portions of a chess AI.  We held a prolonged team meeting sunday before we did our final edit run of the slides to determine the feasibility of that addition, and ended up deciding against implementing any FPGA component in the project.

After our presentations, I began doing some work on the design document, and reviewing some of my previous calculations.  Our first parts arrived, and I have laid out the kinds of tests I want to conduct with the hall effect sensors and began gathering materials (acrylic and wood of various thicknesses) to use when testing the parts.  In addition, I found a physics major friend of mine before the parts had arrived and went over my calculations with him, and I found a slight error. Although the magnets we purchased will work, they will only be able to create fields within half of the range that the sensors can detect.  If the sensors are not very precise, then this will cause additional problems, and we will have to order another round of magnets to test before getting all the pieces. I hope to have that determined by Sunday evening.

In addition, after our presentation, another member of the class approached us and mentioned he’d worked on a similar project for another class, and that he only detected the presence of pieces, but not which kinds of pieces were on which squares.  He then had the users affirm that the starting game state was accurate, and kept track of all piece placements in software. We are currently debating whether or not to switch to this approach in our group, and although it would make things much easier, I am a bit concerned it would decrease the complexity of the project a bit too much.  My ability to get the magnet sensors working appropriately over the next week will definitely play a role in our whether or not we switch our approach to this aspect of the project.

Here are our design review presentation slides.

Design Review Presentation

My primary goal this week was to figure out what I need to build one magnet detection square.  In order to accomplish this, I first had to revisit physics 2 to relearn how magnetic fields work and are measured.  After doing this, I took into consideration the magnitude of fields that our hall effect sensors will be able to detect, and came up with what seemed like a reasonable board thickness (since our sensors will be under the board, and the pieces will be above the board).  These numbers were a range of -45 to 45 mT and a thickness of 1/8 inches. With these in hand, I settled on a set of N42 magnets with a disc diameter of 1 inch and a thickness of 1/16 inches. Their measured surface field was 819 Gauss, and one Tesla is equivalent to 10,000 Gauss.  As distance r increases, magnetic field decreases with respect to 1/r. Since the surface field is assuming a point in the center of the magnet, the surface field is at a distance of 1/32 inches, and our board will be 4 times as thick, so it will be ¼ the strength on the other side.  As a result, this magnet should be detectable at 20 mT by the detector if it is flush against the board. I plan on using thin spacers to elevate magnets higher to change the field for different pieces. I placed an order for the appropriate magnets and sensors, and hope to settle on a spacing system next week and also determine any changes that must be made based on differences between my readings/calculations and how the sensors and magnets actually end up working.

In addition to this, I started my basic circuit design.  I have already designed a testing circuit I can use with my arduino, since the actual raspberry pi and ADC will be arriving later than the sensor and magnets.  Conveniently, the input voltage can range pretty significantly, so for testing purposes a single sensor can be powered straight from the arduino. I also spent time researching analog multiplexers to use for each row.  Our plan is to have an 8-input ADC that receives input from 8 8-to-1 muxes, which will receive input from the 8 squares on each row. I found one that looks like it should suit our purposes. The CD74HC4051-EP is an 8-to-1 digitally controlled analog multiplexer, so it will be easy to send lines from one pin on the raspberry pi to all the multiplexers and then sweep the 8 inputs to the ADC.  I am behind right now, but am bottlenecked by not having parts to run tests with yet. I hope to drop a lot of hours into testing after the presentations next week to try and catch myself back up in time to have a form of functioning square before leaving 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.

 

I started looking into the FPGA acceleration of our chosen chess engine. Chess Programming is a fascinating problem that’s attracted some of the greatest minds in Computer Science, like Ken Thompson. www.chessprogramming.org is the authoritative source of chess programming info. Pretty much all the knowledge I need is held within the pages and third-party links on this wiki.

The problem boils down to a complex search of either all interesting possible moves, or all possible moves period. Back when computation power was limited, heuristics were used to limit the search space of possible chess moves. With the power of Moore’s law, the prominent strategy returned to a brute force search of the “best” move one can make.

I’m planning on using some advanced RTL libraries found in RocketCore for our accelerator. My current game plan is to use unmodified stockfish running on a Raspberri Pi on our first board, with our second board running on an FPGA of some sort. I’m highly skeptical that our FPGA accelerated stockfish will outperform the Raspberri Pi’s 4*A53 Arm Cores @ 1.4 GHZ. But I would be escatic if I can beat it on a clock for clock basis.

First step will be to get Stockfish running on a RocketCore. I’ll need to port Stockfish to RISC-V (which I’m hoping will start as a simple cross-compile). It would be prudent to tune the RISC-V port a bit before I dive into the hardware acceleration. I think the move generation logic is the most ripe candidate for acceleration, while the alpha-beta pruning/search is best left for our softcore.

This is a relatively late addition to our project, so an exact time table isn’t applicable yet. I’ll count this as behind schedule because we’re already pretty deep into the semester and I’m just now starting this. I’ll probably invest some of my spring break working on this project, as it’s directly relevant to what I want to do in my career.

I would to get Stockfish up and running on my ArtyA7-100t FPGA this week. The existing FPGA shell’s and SDK from SiFive should give me a good starting point.

Team Update

The most significant risk at the moment is that I’ll be unable to figure out how the implement the move generation circuit. The literature is all there for me to sift through. This represent’s most of the complexity of the project, so I’ll be doing my best to guide and leverage my other teammates when needed.

We added an FPGA acceleration aspect to our system to make it worthy of an 18500 project. Chess Machine’s aren’t new, so this represents a doable extension to the smart chessboard.

We also need to sit down and redo our schedule now that I have a much more significant burden of the project to investigate. Hopefully we can come up with a revised Gantt chart sometime this week.