Introduction

We created a companion system for physical chess boards to help players enjoy their fast paced blitz game with a chess clock, a visual board to keep track of the game, a display for available moves based off of what piece that players want to move, and also a log of past moves made by both players.

Using our PIC32 and TFT screen, we keep track of players moves and display the state of the board on the TFT screen. Not only that, but we include an adjustable timer that each player has to make their moves (For reference, if a player finishes their move, their clock stops and the other player’s starts. If a player’s timer hits 0, he/she loses.).

Using physical buttons on the border of our board, we keep track of which piece the user wishes to move or see the possibilities for that piece, and we display the available moves on our TFT screen on top of the current chess game. Players can easily back out by selecting the same piece or choosing a different piece, and if the player chooses a valid location for that piece (based off of the available moves that our chess board shows on the TFT screen), we update the game and cause the next player’s turn to resume. When a move is made, we display all moves made by both players on a separate monitor in case players wish to review the game and their moves.

We wanted our chess board to include all of these features because we wanted new players to learn what moves a certain piece can make by referencing our TFT screen, but we also wanted to implement the other features (clock, board on TFT screen, move logs, etc.) to make chess more exciting for more seasoned players. Not only that, but we wanted to make our chess platform viable for thousands of chess tournaments around the world; competitors simply have to place their tournament mat and pieces on top of our platform and everything else is handled.

 These extra features will keep normal tournament expectations and automate it for the player, allowing players to enjoy the fast paced blitz chess game while having the tools later to review the game if desired.

High Level Design

We were inspired to do a physical interactive chess board via a youtube video we saw online of a few graduate students at an international university who created an interactive chess board with their own made up rules. We wanted to create our own via the PIC32 and make it exciting by using it to monitor a blitz chess game while also still being educational.

We made our chess platform modular for players who wishes to use their own matt or pieces; simply swap our mat and pieces with your own mat and pieces and you can still use our chess environment.

Our project is split into clear distinct parts; getting the players movement (the physical component of our project) and keeping track of moves, time, available moves, moves made, etc. (the software component of our project).

We realized that a chess board would be tedious and huge physically, and so we wanted to minimize the amount of hardware necessary. We originally thought of creating physical clocks for each player that would be linked to players moves, but we realized that we would already have a lot of hardware to get a player’s moves and pieces that he/she wishes to see.

We decided to keep track of player’s movements and what pieces they want to move via push buttons. The original idea was to use pressure sensors, but that would have driven our budget well over the limit of $100. We decided to use push buttons that would be clicked when a player pushes down on a piece. The piece being pushed on will determine the column that the piece is on while the player will then have to push a button on a row to finalize the coordinates of that piece.

Once the information about the selected piece is determined, our PIC32 then uses our array of the chess board, filled with our data structures of the pieces, to keep track of where the pieces are and what the available moves for the current selected piece is. We display the board and pieces on the TFT screen, and once the piece is selected, we also highlight the available moves on the TFT screen over our board.

If a player selects a move (by placing the piece on the square desired and then also pressing the button of the corresponding row) that is on the list of available moves, then the timer that was counting down the player’s time stops, the board updates with the new move, and the next player’s turn starts (with its clock resuming the countdown). Meanwhile, the move that the player made will then be updated on the other monitor screen to keep track of the game. If the player wishes to select a different piece, all the player has to do is select a different piece.

Our project’s design can be summarized in the following flow chart where the physical board and software board run while the clock is in the background in parallel waiting for inputs from the physical and software board:

Using a hardware based method of displaying the available moves via lights or another method would require an incredible amount of hardware (there are 64 squares, meaning we would need a method to sort through them all and differentiate the lights), making wiring, spacing, and costs a bit too much to manage. Because of the physical limitation given the constraints, we were forced to use software to display available moves.

The current state of board and history of moves are constantly changing and so adaptive and volatile that there would be no hardware that could monitor that, thus limiting our choice to software for controlling those two features of our blitz chess board.

We were fortunate that our board is very local and not interfering with the environment, allowing us to operate normally without worrying about standards. Not only that, but physical interactive electronic chess boards are not that popular, allowing us to not worry about copyrights or trademarks either. We did get our inspiration from an arcade chess game that we found which was like chess except the players could move every 5 seconds and could even move out of turn if the opponent doesn’t make a move quick enough. We included the video below in the references section

Hardware Design

The main function of our hardware was to get player inputs on what locations they wanted for moving pieces. For our baseline design and proof of concept, we chose to use push buttons. We also wanted buttons that would simply tell us which one was pressed and not have a need to continuously be toggled, so we chose momentary push buttons.

Hardware Choices

We chose to use the D6C90 F1 LFS momentary button switch with two sets of pins for connecting to two separate input/output ports. Because there are only free sixteen input/output pins on the PIC32 for our hardware (including the pins taken by the TFT), we decided to use muxes to handle the large number of buttons. The specific muxes we decided to use was the CD4051BCN muxes.

Our initial idea to get the user’s input on location was to have a push button for each of the sixty-four squares on the chessboard. We would have two 8-to-1 muxes where one mux would control the columns and the other mux would control the rows. Since each button had two sets of pins that could feed to two ports, we would feed one port of each button to the row mux and the other port would feed into a column mux. That means that 8 buttons would feed into each input bit of each of the two muxes.

We decided to use pull-down resistors for all of our buttons to have our mux detect 1s when the button is pushed. In order to minimize resistor usage, we would connect a resistor from each input of the mux to GND, and one pin from the button would connect to that pin while the other pin would connect to the 3.3V line.

Both of the two muxes have 3 ABC pins to allow us to control which of the 8 input pins we wish to look at, and since each mux has to go through all sixty-four squares using a for-loop style (one mux stays at pin 1 while the other pin cycles from 1 through 8, then the first mux goes to pin 2, and so on and so forth). We would require 6 separate ABC pins on the PIC32 to control both muxes, and two additional pins for the output lines of the two muxes.

In order to display the past moves, we decided to use the UART serial cable to display the series of moves on a separate monitor. We would therefore need 3 pins on the PIC32 for the UART cable.

Failure 1

When we began to implement the 64 push buttons idea, we ran into issues with spacing and wiring management. Since all sixty-four buttons’ four ports were all being used, that meant we would have to deal with 256 wires feeding into our two muxes. This created huge issues with wire management and portability since we would need a lot of physical addition to the bottom of our board to hide the wires and make sure our chess board is level. As seen in the pictures below, it was almost impossible to use sixty-four buttons given our portability requirement and size constraint (we wanted the muxes to be hidden away underneath the board).

Failure 2

We decided to pursue an alternative idea where we instead have one button for each column, one button for each row, and have the player press a square where some physical mechanism would push on the row and column button to get the location. The idea that came to mind was to have  vertical bars and 8 horizontal bars that would form a waffle-looking physical mechanism. Each intersection would correspond to a square on the chessboard, and when a square is pressed, the vertical bar for that square’s intersection and the horizontal bar for that intersection will only be the ones going down and clicking their respective buttons.

We wanted to use cheap resources found in lab that would be rigid enough to push on buttons at the ends yet flexible enough such that only the bars forming that intersection will be pressed. We decided to build it via strips of cardboard, interleaving to form the waffle-like mechanism. When we tested it, we ran into issues where the cardboard was either too flimsy to not push down its respective buttons, or certain squares were too close to other buttons causing multiple buttons to press, convoluting the row and column button we need for input.

Final Design

The final design we decided to pursue was our previous waffle mechanism, but without the horizontal bars. We would have players push on a piece which would push the vertical bar down to get the column, and the user would then press a row button on the side to finalize the location. This was a slower way of selecting pieces, but it prevented the error of hitting multiple buttons at once, thus giving us a clear input of the user’s desired location. The final designs can be seen in picture X in the results.

In order to minimize wiring and inputs to our mux, we decided to daisy-chain the column buttons at each end to each other. Thanks to the nature of the button layout, the two sets of pins are connected to each other. If we attach another button to a set of pins on the “master” button and attach the other set of pins on the “master” button to the pull down circuit, then when either button is pressed, the mux would detect that input. If the “slave” button is pressed, the circuit for the button on the master-slave would be connected via the closing of the slave button’s circuit..

We would also have the row buttons on the side that users will have to press with their hand after pressing their piece down to get the column. This would prevent any extra buttons from being pressed, but would add on extra steps to select a location.

Software Design

High-level Overview

The software was implemented using protothreads and the libraries given to use by our Professor, Bruce Land. In order to implement the chess board, we had a 8×8 board array of pointers. Each index points to a chess piece that we initialize in a different section of our code. We implemented a piece struct that contains the name of the piece (e.g. pawn, rook, bishop), if it’s a white or black piece, horizontal position, and vertical position. Once we have our initial chess board set up, we then go through our chess control path diagram shown above. We keep track and control which state the program is in using in a simple protothread that checks for certain conditions such as if we have an input and if it is valid or not.

Input Thread

This thread keeps track of the inputs that the PIC32 receives from our 8-to-1 mux. We iterate through all the inputs of the mux and keep track of which input results in a high output. For example, when we receive a column input, the program sets the column_pressed bit to high and records the bits it was sending to the mux when we receive this high input. As a result, we can look at the the truth table found in the data sheet to see which column on our chess board was pressed. Similarly, we can do the same for the row inputs.

In addition to keeping track of the inputs, this thread also makes sure that the input is valid. When both column_pressed and row_pressed bits are high, meaning that they have been selected, we want to make sure that the index of our board array is valid. So for example, if we choose a row and column that doesn’t have a piece or if the piece selected isn’t theirs, then we would want the user to re-choose their inputs as shown in the control path diagram above. Once we make sure that the input is valid, we can then move onto the next state and either display the available moves or move the selected piece depending which state we were in.

Available Moves/Move Selected Pieces Thread

One of the more algorithm intensive thread is the available moves thread. This thread calls upon a helper function which takes input values that we received from the input thread. We then take that input and do some arithmetic to calculate the moves the pieces can move and store those values in 8×8 two-dimensional array. We store a value of 1 into the index if it is a valid move and a 0 into the index if it isn’t a valid move. We also needed to take account that a piece cannot move through another piece, unless it’s a knight piece, and special moves such as castling and pawn captures. A few things that we didn’t implement, that we can in the future is the checkmate condition and en passe. To elaborate on the checkmate condition; if black king is in check, black is allowed to move a different piece such as a pawn, which means that the king will still be in check, which is technically illegal in regular chess.

The last main thread we implemented is a move selected pieces thread. This thread just takes the input from the input thread and compares it to the 2-dimensional array of available moves that we calculated earlier. If the index of the available moves is 1, then we would allow the move and we would update pointer from the old position on the 2-dimensional board array to the new position, also updating the horizontal and vertical positions of our piece struct.

Results

For the results, we evaluated the success of our project based on hardware/software criteria:

1. Hardware: do the button presses register correctly and easily?
2. Software:  do the pieces move as intended and accomplishes everything it needs to

For the hardware criteria, our buttons register correctly around 90% of the time. Sources of error includes our design being built with cardboard which isn’t very reliable. As a result, we could’ve used a different material such as aluminum or steel. However, the buttons were very easily pushed. For the software standpoint, everything worked as intended and we thoroughly tested everything that we implemented. There are a couple of things that we did not implement however, such as en passe and checking the conditions for check/checkmate. We hope to implement this in the future

The end result of our project is a very playable chess game that displays available moves when a piece is selected and then moves the piece when a different valid spot is selected. We successfully update the TFT screen and print out the list of moves via UART. Linked below is a video of our project as well as various photos of our design process..

Video of our project

Conclusions

Our chess board was a huge success, especially given our base hardware that we used around the lab to keep budget costs low. We used relatively tall and sensitive buttons to detect piece selections when we could use harder to press with less-travel time buttons to prevent accidental misclicks. Not only that, but we used analog muxes which are much slower at detecting push buttons than a digital mux. Despite all of these more inferior hardware, our project still worked as expected.

In future iterations of the project, we wish to explore pressure sensors for the pieces to detect movement with just a grip of the piece. Users can simply touch a piece to activate piece selection and show available moves, and when the user moves a piece and releases, the pressure sensors could detect that as a movement and update our chess game. We also wish to explore using a touch screen for our board and integrating it with any chess mat that can go on top of it if we wish to not pursue pressure sensors. Of course, we wish to use digital muxes for faster response detection.

An additional idea we wish to implement on a future iteration of our chess platform would be LEDs that could shine through chess mats to show available moves instead of just displaying it on the TFT screen. All of these additional hardware would require careful planning of wire management and space consideration to keep the chess platform compact and user-friendly.

Our current chess board is set for blitz chess, but we wish to expand this to normal chess rules which will take into account future illegal moves that will require more memory and logic. After all of these implementations, we wish to then polish the aesthetics and physical construction to keep it compact and make it tournament-travel friendly, thus potentially marketing it to avid tournament chess players.

Our project utilized a UART interface to display the list of moves a player makes, as a result our design conform to the UART communication standards and followed the same protocol format. We did not reuse code or use code in the public domain. We did, however, use libraries written by our professor Bruce Land and Tahmid  Mahbub which are listed in the appendix.  We did not have to take into account any legal considerations. We did, however, find other electronic chess boards, which is listed in the references below, but they are designed for single player usage and not the tournament or educational purposes that we are targeting with our project. Therefore, we believe that we shouldn’t run into any patent problems if we decide to pursue this project even further. There are patent opportunities for our project if we want to pursue it next semester as an independent project.

The decisions we made and actions we took in this project were consistent with the IEEE Code of Ethics. We recognize the importance of our technologies in affecting the quality of life throughout the world and accept a personal obligation to our profession. We were responsibly in making decisions with safety. For example, we wore safety glasses when necessary and handled box cutters with care.  We are honest and realistic in everything that we stated in this report. We stated the costs of the components that we used at the time of use.  We were not offered and did not take any bribes. We strive to improve the understanding of technology and its potential consequences. We undertook this project knowing that we have the technical competence and that we were qualified to accomplish our goals. We are always open to accept honest criticism for our project and will promptly correct any errors when contact and made our utmost effort to properly cite the contributions of others. As good fellow citizens, we took proactive measures to avoid injuring others, their property, reputation, or employment and will vow to assist colleagues in their professional development and support them in following this code of ethics. Lastly, we treat all persons fairly without any discrimination with regards to race, religion, gender, etc.

Schematics

Source: Interactive Blitz Chess: A Physical Blitz Chess Board Powered with PIC32