This is my current journey at attaching a chess engine running on a computer to my chess robot. This implementation uses a program called “My Robot Lab” (MRL) written by Grog.
Another page on the topic can be found here: http://letsmakerobots.com/node/26757
I worked with Grog in getting his program to communicate with my robot. I had to explain to him the features I wanted and the protocol that was being used. This is an explanation of what we came up with.
Grog has a video explaining how to work his program here: http://letsmakerobots.com/node/26904 This will help fill in the gaps of my explanation on how to setup what I did below.
First off is how the program needs to be setup:
Once his program is downloaded and installed correctly, setup is pretty simple. The program runs on a net-book (running Windows 7) that is connected to my robot using a FTDI serial cable. I have also ran this program on my Mac using wireless Xbee transceivers to communicate with the robot. Either way it is done, the setup is the same. In the case of this explanation I will be using screen shots from my Mac, but do realize this is the same way it is setup on my net-book.
There are two services that are used for the control of the chess robot. They are the Arduino and ChessGame service. I have selected these and named each of them.
A few things need to be set on the “Arduino” service tab. The box at the tab labeled “read raw” needs to be checked, then select the serial port and serial rate from the drop down menus.
The only thing I change on the Chess Game service tab is the amount of time the chess engine takes to move. I usually choose 5 seconds from the drop down menu, but there are other choices depending on how long you are willing to wait.
The last thing to do is to choose the inputs and outputs of each service. To start with, select the output of the “Arduino” service. The output that needs to be selected is “readSerialMessage -> string”. This gets connected to the input of the
The output of the “Chess Game” service needs to be selected as “makeMove (string)”. This then gets connected to the input of the “Arduino” service as “serialSend (string)”. This is the last step of the setup.
So what that setup just did was allow the chess engine to talk to the Arduino over serial communication. The serial output of the Arduino was connected to the input of the Chess Game. This means what ever move sent over serial from the Arduino will be received by the chess engine. The output of Chess Game was connected to the serial input of the Arduino. This allows the chess engine to tell the Arduino what move it performed so the chess robot can perform that move.
Next is the explanation of the serial protocol that this service is using.
It is pretty simple. When a move is entered on the keypad of the robot by the user it gets sent to the chess engine over serial. This move, for example, looks like “a2a3” or “b5b4”. That is how moves have to be sent in order for the MRL code to properly run it in the Chess Game service.
Once the chess engine figures out its own move, it sends this to the chess robot over serial using a little different protocol. If the chess engine decided its move was e5e4, then the move would be sent to the robot over serial looking like this: “xe5e4nz” . This gives the serial read function on the chess robot a beginning (‘x’) and end (‘z’) character to look for. I will explain the meaning of the “n” shortly.
Now lets say the user performed an illegal move on the chess robot. I will say the illegal move was “c4d7”. This will be sent to the chess engine which will quickly find out that this move is illegal. The chess engine will send back over serial this “xc4d7iz”. This basically echos the move back to the chess robot so that it knows what move to undo. This protocol looks like the one above for a normal move except it has an ‘i’ instead of an ‘n’. The ‘i’ stands for an illegal move and the ‘n’ stands for a normal move that the chess engine came up with. This is how the code on the robot discerns illegal moves from a normal move it needs to perform.
Now there are a few special cases that the chess robot has to look for:
The chess robot has to figure out whether the move it receives from the chess engine is capturing one of the users pieces. The chess robot might receive a move like “xb4b3nz” (b4b3), but one of the white user’s pieces is occupying the square b3 which is the square the chess engine is trying to move to. In order to know if the move is capturing one of white user’s pieces, the code keeps track of where the white pieces are located in an array. Every time the chess robot receives a move from the chess engine it checks to see if the move is capturing a piece by looking in the array at the index the engine is trying to move to. If that square is empty then the robot has to do nothing extra, but if it is occupied then it first has to remove the piece occupying the square before performing the chess engine’s move.
The next special case is castling. The chess engine often castles and there are two different directions it can castle. Castling involves moving both the king and the rook, but this move is sent to the chess robot as a single move. So initially this move received by the chess robot looks like a normal move, but actually two separate moves have to be performed. If the chess engine sends the move “xe8c8nz” (e8c8) or “xe8g8nz” (e8g8) to the robot and this is the first call to e8, then the robot knows that this is a castling move. This is because the king located at e8 is moving two spaces, which is indicative of a castle. This is not true once the king is no longer located on e8 (i.e. the robot has already received a move that started with “e8”).
The chess robot will first move the king and then move the corresponding rook. If the move is e8c8, then the rook has to move like so: a8d8. If the move is e8g8, then the rook has to move like so: h8f8.
Some other, older videos below that help show the progression of updates: