[Oriol Galceran] has constructed an interesting robotic chess player for his end of school project. It’s called the ChessM8, and is an impressive feat considering [Oriol] is only 17! He’s using an Arduino Mega that connects to the host PC via a Python script.
The AI can be any chess engine that uses the Universal Chess Interface protocol, which [Oriol] points out that most of them do. We’ve seen other chess robots here before, along with others that you can play on your wall and uses Nixie Tubes. But [Oriol’s] build is the largest of them all.
He says there’s a network of REED switches under the chess board to detect when a piece is present or not. It would be interesting to know how he dealt with debouncing issues, and if Hall Effect sensors might have been a better choice. Let us know in the comments how you would detect the chess piece.
And be sure to check out the video below to see the chess robot in action.
You deal with debounce by literally just waiting a few milliseconds then reading the signal.
But then you had plenty of time, and made another one. You are left alone once again.
I was expecting the claw to lower down (Z axis) on a string like the claw prize machines in shopping centres.
Reed vs Hall Effect vs VRS: http://www.electronicproducts.com/Sensors_and_Transducers/Sensors_and_Transducers/Reed_vs_Hall_vs_VR.aspx
Thanks for the link, very informative
Congratulations to Mr Galceran. It’s truly beautiful and inspiring. The next step would be to try and increase response time in order to make the robot more motivating to humans. There is also the issue of noise. Hopefully, the motors do not cause annoyance.
In regard to detecting the chess piece:
The robot should, in my view, never need to detect when a piece is present or not. Instead, the Python code can have an 8×8 table in which to store the location of each piece on the board, and then simply send the required set of coordinates to the robot. Of course, the robot would also require instructions for each set of coordinates. The robot can be thought how to respond to these instructions in accordance with a minimal protocol. For example, if a piece is simply being moved to an empty square on the board, the instruction might be coded as ‘0’, and if the move entails a capture, the instruction might be coded as ‘1’. Additional codes can be used to deal with other type of moves such as castling and en passant.
The robot actually does need to detect the presence of pieces if you want the human to physically play the game instead of entering the moves into the computer.
By “robot” I understand the mechanical arm together with the associated moving system. In this context, the robot does not need to detect the presence of pieces. It only follows instructions from the Python code.
What needs to be detected are the coordinates (not pieces) of the human move. This detection is done by the chessboard utilizing sensing devices or by a web cam as explained in comments further below.
Please note that the UCI chess engine only requires coordinates as input.
The machine is a bit slow, but there isn’t really any way to make it faster while keeping the current moving system.
And as you have been told already, the machine does keep the state of the board. The objective of the sensors is to allow the user to play against the machine without having to type one single key.
To detect the coordinates of the human move is usually done economically using small spring loaded switches.
The reed sensors cost me less than 1€ each and were much more simple.
You have obviously done well in your choice of devices.
Hopefully you get a chance to experiment with a web cam, and shift more intelligence from mechanics to Python code.
The good robot has more and more coded intelligence, and needs less and less labour to perform the necessary functions. This ideal should improve the speed and appeal of your robot. Chess players invariably demand quick response and quietude.
I could have made this when I was 17. Probably couldn’t now, because since then I’ve been taught what’s “impossible”.
Why, exactly, would you need to worry about debouncing? A piece gets moved to a square and stays there. It’s not a momentary switching event.
If you read it too early, when it is literally first detected, the signal wobbles considerably and can lead to erroneous detection or multiple detections.
“While the main transition of the pin is from high to low, during the process, there are several spikes which can cause multiple interrupts. There are several ways to remedy this. Often you can fix it with hardware by adding an appropriate RC filter to smooth the transition or you can fix it in software by temporarily ignoring further interrupts for a small time frame after the first interrupt is triggered.”
Here’s an example (using interrupts in this case, but you don’t have to be using them as debounce issues are common to any mechanical inputs) from Sparkfun: https://www.sparkfun.com/tutorials/326
The machine does not read the state of the board immediately after the move. When you’ve done it, you press a button and the original state of the board is compared to the current state of the board. The square that had a 1 and now has a 0 is the origin and the one that had a 0 and now has a 1 is the destination. This is then converted to chess coordinates and then to cartesian coordinates indicating the number of steps each stepper should move.
The ‘reed’ in reed switch is not an acronym, so there’s NO NEED TO SHOUT IT.
I did consider using Hall effect sensors but I quickly realised buying 64 of them wasn’t quite an economical choice
By the way, why is my name in []?
It’s what we do.
Just needs a mannequin in a turban and a French emperor and he’s got his very own mechanical Turk!
I see this failing pretty easily because just picking a random object up with a robot arm is extremely hard to get right. Instead of green felt tips you could use magnets (but you need an algo to move things aside or walk around if horses are used for jumping for instance over the pawns in an opening move) Alternatively take smaller pieces and a larger board allows for this to work without the extra moving around effort by sliding between your pawns… Anyway that’s imho.
https://www.youtube.com/watch?v=dX37LFv8jWY it’s already been done, and i don’t like how it looks. The pieces have to move between each other. I decided to make something that you can play on a bigger scale, like a normal game. Also the claws have a surprisingly low failure ratio. I covered the tips with self-amalgamating tape and that gives it a really good grip.
How about this? http://oi61.tinypic.com/r7ocgj.jpg
A little explanation of above image: A web cam looks at the entire chess board from above. The Cartesian coordinates are mapped out so the computer knows where every piece is. It identifies every piece by pattern recognition of the top of the piece where chess symbol is stamped. It knows where the pieces are by scanning the entire board. When the robot or human moves the piece it re-scans the board again to re-synch all pieces new positions. It can tell the robot arm to extend it’s arm out over the metal topped piece and turns on it’s electromagnetic-coil picker. The piece is attracted upwards, the arm moves to new coordinates, then turns off picker coil, and piece drops into place. All captures are done first and piece is dropped off board, then it moves attacking piece.That way there is no conflict of two pieces on same square. All robot arm noise is abated by wrapping motors in sound proofing foam. Also negative out of phase audio from motors could be sent to speakers almost cancelling the motor noise. Since the picker coil is used the claw never needs to be deployed hence no noise from its motor. Actually a clawless robot arm could be used. Only need azimuth and extend movement.
Using a web cam, even if just to detect the coordinates of the human move, would be the best option because it will eliminate the need for 64 sensing devices currently positioned under the chessboard.
A webcam would have probably been a wiser choice. I don’t know how reliable that would be though, especially with the white pieces on white squares and the black pieces on the black ones.
You would be surprised. The image linked to showcase the idea states there needed to be stamped images on the top of the piece to identify.
That said, the reed switch idea is much less processor intensive and requires less external devices. As far as a potential customer is concerned, I’d rather buy a special board then try to hang a webcam above my chess board.
As far as noise is concerned… ignore trying to play back motor sounds from computer speakers to cancel it out… Best solution is insulation, and perhaps making adjustments on the stepper drivers.
Good job.
I have dabbled with chess computers in the past. The issue with embedding switches (of any type) in the chessboard lies in the amount of wiring that’s involved. You are looking at an 8×8 grid with two 8-wire cables feeding the processor board. The physics can truly be a nightmare. And chances are high that one of the 64 switches is going to play up at some stage, or a connection will go loose somewhere. It’s a long standing problem.
The right approach is to work with generic components that are easily replaceable and are available relatively cheaply over the counter. These components are mainly the chessboard, the chess pieces and the robotic arm. Given that UCI chess engines have now made processor over-loading no longer an issue, the generic components are best assembled (and made to work together) with a little amount of cabling while replacing everything else with code.
In summary, focus more on the concept and less on the mechanics/electrics side of things.
In regard to customers looking for a potential product, it is safe to say that chess players generally like to play chess using their own chessboard and chess pieces. They would not object greatly if they were required to label the pieces. And the use of web cams is now universal. It’s always a matter of how to package and market a product if one wished to pursue that path.
Well using the Cartesian (grid) coordinates system and a square position database in the program, the color of the square would be moot. However, webcams can also detect color. But that’s just more processor overhead. Also color is important not just for the square but also for the piece itself. That could be overcome with a printed code on top of the piece to identify color and piece name or some sort of QR code or something. I’ve seen chess pieces at the store that have a 45 degree up angle label at the base for training purposes.
The webcam never moves (hangs motionless on an inverted L-bracket like a goose-neck desk lamp). The scan process is a built-in function of the computer program. It processes the entire JPEG image for data much the same way OCR programs work. The grid coordinate could also be stamped on the squares too. For human aesthetic reasons all of this wordy stamping of codes on the board and pieces could be done in invisible IR ink. The webcam can have it’s IR filter removed (very easy to do) and bathe the entire board in IR light from a set of IR LED’s around camera ring (very common with surveillance cameras). In that way the human never sees any label stamps only a regular board and pieces. The camera would see much more data.
Speeding up the robot arm process: by using my electromagnet-picker idea would eliminate one time consuming move of opening a closing a claw. By using an actual robot arm like the one I depicted rather than a plotter would also be a bit faster. The chess piece would need a metal iron rod or modified roofing nail inserted through its core. Leave the nail’s flat top alone so magnet has more surface to select.
With those commercially available robot arms that do not use stepper-motors but just old-fashioned PM motors, one could slightly increase motor voltage just a tad. Those motors could probably take more than 6-9 volts and maybe up to 12 volts safely. Just try not to send too many commands to it in a short time period to hold down thermal overload or use a cooling fan.
To cut down noise you could spray the inner motor chamber with insulation foam from Home Depot being careful not to foul the armature. But shredded up newspaper insulation is a great soundproofer too. My negative audio idea was supposed to be an outboard device not computer controlled. It would essentially be a black box project with a electrolet microphone, a PM speaker, a IC op-amp, 9v battery, and some out-phasing device like an audio transformer flipped backwards. Or the out-phasing could be done internally with some sort of 180 degree phase conversion solid-state electronics. Audio xmfrs are way more simple and cheaper (and available at R/S). But that’s just overkill. Some noise is naturally expected. It would seem very weird to see a robot arm moving silently like a ghost was moving it :-)