That's why I favoured the jack-plug method.
Perhaps you could represent the chess pieces with different styles of jack plug.
The Rean Jumbo could be a King
The Neutrik Crystal could be the Queen,
The Neutrik NP2X with the top that looks like a mitre could be a Bishop
This cuboid right-angled jack from Cliff could be a Rook
and the cheap plastic covered ones could be pawns.
(Can't find a suitable knight)

 

And every one of the boards 64 squares will need a jack for all of those different plugs. So instead of normal chess pieces these would be required. Not simle

 

And every one of the boards 64 squares will need a jack for all of those different plugs. So instead of normal chess pieces these would be required. Not simle

They are all mono quarter-inch jacks.

 

If you want a non-contact solution, then how about an LC resonant circuit in base of each piece and an RF detector to measure the resonance frequency. This is a bit more complex than a single resistor but it eliminates the contact problem.

If you want to go this route you might as well look at the possibility of an RFID or NFC chip.

 

All this complexity comes from the single arbitrary wish to have the capability of identifying every piece at any time, with random placement, without any input from the player!
Whatever scheme is decided on, there must be some kind of communication between the software and the player to maitain the flow of the game, therefore it would be simple for a player to define a random board.
That single wish has increased the complexity of the requirements by a vast amount. If this was a commercial project I had to quote on, I would state it is not worth the extra time, effort, cost and increased unreliability to include that capability because there is such a simple alternative solution available..
If the TS plans on going ahead with it, I will have very little confidence in his chances of success.

Reference: I was a very successful Project Engineer for HP Test and Measurement for many years.

 

Why not use rare earth magnets in both the board and chess pieces. Then the board squares are made of a PCB, with a central pad ringed by a wide circular trace. The chess pieces have three pads equidistant by a fixed distance from the center equal to the radius of the circular trace on the board . These pads have a solder blob on them. The three pads provide a stable base. The magnets provide consistent contact. A resistance connects the rings to the center of the piece.

One could use s second ring to identify the color, but this really isn’t necessary as software can track the color in addition to the moves.

Mechanically, this solves the concerns of contact reliability and resistance. And it is the least expensive solution.

 

Crazy idea of the day:

Place colored stickers or different color paints on the bottom of the chess pieces - use an RGB LED colorimeters looking up through holes in the board.

 

Ataching a resistor, or even a tiny micro,to each chess piece, in a durable manner, is not trivial. Creating user-proof contacts that will not tend towards making tippy pieces, is not trivial. installing all of those contacts, (2x 64=128) in a reasonable manner is not a trivial undertaking.
It is useful to consider exactly how the process of producing whatever is imagined will actually be done is a part of the design process. And if the project is to be done by one person who lacks an infinite array of resources, it may not work out as well as wished.

Hi,

Magnets help hold the pieces in place and contacts together. Its very common these days. I use that for my phone charging connection.
For the pieces there probably needs to be a physical alignment mechanism.

 

You only have to know which square holds a piece. Moving a piece follows a certain moving pattern which your programs should know and follow. You only have to know the starting positions, and which square/piece moved. You only need to know which square is filled and which is not, ID is unnecessary.

If one piece is taken out from the game, your system will know that when one pieces is lifted and replaced again, so part is removed.

If/when you add a new piece to the game, you need to tell the program which key was it, and then it again starts following a pattern the piece is allowed to be moved.
System can also alarm if a piece was moved in a wrong pattern/way.

Not a fool proof system but fullfill the minimum tasks required.

 

You only have to know which square holds a piece. Moving a piece follows a certain moving pattern which your programs should know and follow. You only have to know the starting positions, and which square/piece moved. You only need to know which square is filled and which is not, ID is unnecessary.

If one piece is taken out from the game, your system will know that when one pieces is lifted and replaced again, so part is removed.

If/when you add a new piece to the game, you need to tell the program which key was it, and then it again starts following a pattern the piece is allowed to be moved.
System can also alarm if a piece was moved in a wrong pattern/way.

Not a fool proof system but fullfill the minimum tasks required.

Needs to be able to cope with the ditherers - unless the touch->move rule is strictly enforced!

 

I have talked to my parents and have gotten them to around $500.
Also to define the moving part, it doesn't have to move the pieces, rather I am thinking of using something to show the point total of each team's pieces. I will be the one doing the coding but with assistance when I don't understand how to do something.

I think by now you understand that what you are proposing is a very complex and lengthy project. I suggest, considering your age and experience level, that you break the project down into stages that will allow you to see some positive results as you go. Otherwise you will just get swamped by all the different subjects you will have to research and all the mechanical effort and programming that you will need to invest your time in, not to mention all the problems you will need to overcome.
If you start by making a very basic game, using a scanning system on the board, and interaction through the computer, you should get some positive results relatively early in the project. That will give you the confidence you will need to continue. Then change the interactive section to a dedicated display and some push-buttons. Then add a mechanical arm. That on its own is going to be no mean task. You will have a working game at the completion of each of those tasks. When you get to that stage, you should be in a good position to start experimenting with some of the piece identification methods that have been suggested here.
If you start to run before you can even crawl, you are bound to fall flat on your face.
I wish you luck and I hope you get a lot of satisfaction from this project.

 

Needs to be able to cope with the ditherers - unless the touch->move rule is strictly enforced!

That's an issue I pointed out very early on -- and was lambasted for.

Even if the touch-move rule is strictly enforced, accidentally touching a piece is not disallowed, and intentionally adjusting a piece is also allowed, so the system has to deal with it. Either of those can likely be dealt with in software, but they will make the code quite a bit more complex. But those can be added as refinements after the basic capabilities are in place.

 

Crazy idea of the day:

Place colored stickers or different color paints on the bottom of the chess pieces - use an RGB LED colorimeters looking up through holes in the board.

I proposed that in post #24 and #26. I am back to thinking it is the best solution after problems with all the other solutions have been pointed out. My proposal uses an RGB LED and two phototransistors.

No one bothered to comment on it, I wonder why?

 

I proposed that in post #24 and #26. I am back to thinking it is the best solution after problems with all the other solutions have been pointed out. My proposal uses an RGB LED and two phototransistors.

No one bothered to comment on it, I wonder why?

Not surprising, with five pages and nearly one hundred posts it's easy to miss what has gone before!

I'm guilty of the same, repeating Ian0's post suggesting jack plug and sockets, which I continue to think is the ideal combination of simplicity and robustness. As he said, you are polling an 8 x 8 matrix and my thought with stereo jacks is that you have three lines. With only 6 different possible pieces times two colours you'd easily be able to distinguish which of 12 pieces with a 10 bit A/D and if that is in any doubt you can have two resistors for each piece with the three lines, or even resistors and diodes would allow tricks to be played with polarity if necessary.

Someone else made the point, what is the object of this project? To develop software to play the game or get bogged down in the minutiae of how to distingush the pieces? A big advantage jack plugs and sockets is also the ability to move the board around without any danger of pieces moving or falling off.

I need to trawl through the posts again, but have we heard back from the thread starter? This problem has created a lot of interest - it seems to have taken on a life of it's own! I actually think I might build a board with pieces using jack plugs and sockets myself.

 

Yes. It would make a great final year capstone project at a college or university.

 

That's an issue I pointed out very early on -- and was lambasted for.

Even if the touch-move rule is strictly enforced, accidentally touching a piece is not disallowed, and intentionally adjusting a piece is also allowed, so the system has to deal with it. Either of those can likely be dealt with in software, but they will make the code quite a bit more complex. But those can be added as refinements after the basic capabilities are in place.

Hi,

Yes, i believe there has to be a way for the human to communicate intentions to the program. We know promotion has to have a mechanism to tell it what the new piece will be, but there is so much more to what may happen during a real game. There are little finesses we haven't even begun to talk about yet.

For a couple examples...
When a player makes a move, it is required that after they make the move with one hand they must press the clock button with the same hand. That makes it a sequence of actions so that they can not use one hand to move and the other hand to hit the clock button, which can be hard to detect if they did it at the same time or after the move. This is important for speed chess which became popular in the late 1980's (but maybe before that too).
Another is that the piece touched is often moved slightly to the right, left, forward, or backward, or slightly along one diagonal. The rule is that the piece touched must be moved and it must be moved in the same direction as it was after it was picked up. If someone is going to be allowed to touch the piece after announcing "j'adoube" or just "I adjust" then there either has to be a camera AND a microphone or another way for the human to notify the computer program that it is doing just that.
The dedicated chess computers of the late 1980's maybe early 1990's did not enforce those rules, in fact they did not even enforce no-takebacks. They did have buttons for promotions though.
They did enforce the 3 fold repetition rule and 50 move rule though.

This makes me believe that some kind of dumbed down version would be required and is actually kind of reasonable.