Month: February 2019

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.