Well, I am still investigating which chess engine to use and which GUI…any suggestion? I read those chess engine and associated GUI are free but I would like to know where is programming taking place?? (I am not talking about communication about chessboard or arm). What are we really programming here?

With most "engines" they are usually just an interface for other programming languages such as C/C++/VB/Delphi, etc. I would prefer to interface with it in C or C++.... but since you are doing this, find an "engine" that would be able to interface to your own favorite programming language, I still use MS VB6 for a lot of projects.....

 

Yes! The pieces MUST be customized and will be done with existing pieces on the market…but I think will have to choose appropriate ones (you suggested plastic) to work on it easily.
Actually, the ID of each piece is, of course, not for me BUT the mcu in order to inform the PC (chess engine) the location of each piece on the board so it can do its AI and decide on its next move!

…if you want the specific unique # ID assigned to each one, then the uC can "identify" each one as it interacts with it then just remember what location it placed that piece in, so it has a way to board to also verify that there is a piece in that location, then you can place a CDS photocell on each square (light present = no piece, light not present = piece is there, etc.) and use an IC such as the 4051 Analog Demultiplexer IC (for example) to multiplex each grid position to only a few analog channels on the uC. (I am sure there are better demux's out there for the task), or creating an 8x8 matrix with actual switches should not be too complex, but it would be a lot easier than using the CDS photocells, but tactile switches wear out and your pieces would have to weight so much to press the switch, when there is no mechanical parts or contacts to wear out on CDS photcells.....

That’s correct! That is the problem that needs to be solved and post #14 addresses it!

The mcu will have to scan the board (64 locations) and determine whether or not there is a piece on a particular location and if there is one, which one is that? Then records the state of the board and then communicate this information to the PC (Chess engine)!
Apparently the 8x8 matrix is the simpler one according to post #14 and the multiplexing technique will make it possible not to have 64 switches! And I agree that each piece must have a certain weight to close the switch.
I need to read post #14 till I understand how it works. A quick question: How many reed switches are needed then? I think 8 switches but not too sure.

thanks!

 

Well, I am not THAT good when it comes to software programming...I prefer Embedded programming
I have done some C, VB6 and VB.net, C++. So I will implement it in VB.Net I think or C

 

Well, with the "training" like most industrial robots, would be done with a "pendant" or a way to manually control each axis, so for a 5 DOF arm you would need a way to move each segment with switches, and 1 button for telling the controller to "remember" this position, so you would have a switch for up, and down for each axis (or just have 1 set of switches to use on all axis', and just have the uC switch the input to which ever axis you are controlling), the pendant is usually connected to the actual controller for the arm, so when you "move it" you are just telling the uC to move the servo so many steps in either direction, this way the uC knows how many steps to get to where it is at, so you would manually move each axis until the arm is in position over the piece and once it is in place press the "train" button, then uC will store this data in the appropriate array to use later, the array data will also include the grid X,Y coordinates........

This is brilliant!! but definitely be lots of work...but I don't mind it as long as I get to the final output! So far we are discussing high level/ideaa...and from next week I'll start the real work!! I will go deep on it but for now it ok!

Thanks for this!!!

 

Actually, the ID of each piece is, of course, not for me BUT the mcu in order to inform the PC (chess engine) the location of each piece on the board so it can do its AI and decide on its next move

I don't think you need any IDs, because you know the initial positions of each piece, and when anything gets moved you already know what piece it was. You just need the software to keep track of the positions of each piece. Otherwise you would end up scanning the whole board every time the player moves a piece.

 

But isn't there any software out there that can be used to train the robotic arm? whereby you can just enter coordinates and somehow feed those coordinates to the mcu instead of doing it manually????

 

I don't think you need any IDs, because you know the initial positions of each piece, and when anything gets moved you already know what piece it was. You just need the software to keep track of the positions of each piece.

That is brilliant!!

But I think you still need to identify each piece!

Otherwise you would end up scanning the whole board every time the player moves a piece.

the mcu can scan the board several times a second! Anyway I am still thinking about your " You just need the software to keep track of the positions of each piece based on the initial position"

My thread title was correct! "Brilliant ideas..."

Thanks

 

Kubeek! you made me think a lot...

Here's what I came up with:

Initially, the mcu will have an array of 64 locations in data memory with the 32 pieces in their respective positions. And these 32 pieces (locations) will be assigned unique values. A location with zero value simply means that there is no piece in that particular location of the board.

The mcu will then continuously scan the board and when a move has been made the array will be updated. This can be done by an interrupt or routine...the previous state and the current state (latest scan state) can be compared and if any changes -> update list/array...

The mcu will transmit the state of the board at a certain rate which will be greater than the time the full scan takes!!

But there MUST be an ID implemented in each piece otherwise if we do our tracking based on the way each piece move then we ll be implemented some kind of AI into the mcu (that's the engine work)

well, maybe I ll improve this idea...but the bigquestion to me is what to use as an ID for the pieces...

I ll sleep on it...

 

post #14 last comment by thatoneguy seem to have a solution for differentiating each piece but i don't really understand it!

 

I dn't know if someone has already suggested this. I did not see it during my quick sccan of the 28 replies.

Would you be able to simplify your robot arm if you made it so that it always picked up the piece at the same coordinates? Then you could move the chess board in the XY plane to position the piece you wish to move so that it is in the position for the robot arm to pick it up. You would then move the board to the new position where the robot arm would set the piece back down. Of course the piece that would be displaced would have to be cleared first.

hgmjr

 

But there MUST be an ID implemented in each piece otherwise if we do our tracking based on the way each piece move then we ll be implemented some kind of AI into the mcu (that's the engine work)

I don´t understand that.
Lets say you start with the beginning configuration, rows 1,2,7 and 8 are all occupied, rest is free. Now the player takes away a piece, so you notice that position B2 is free. Wonder what piece has moved? And suddenly, B3 is occupied. You got all the info you need to tell which piece moved where, don´t you? You allways know the state of the board, and moving a single piece is allways deterministic as to what and where moved.
Then you simply tell the AI game engine that the move was B2 to B3.

The only problem is promotion, where you would somehow have to tell the computer which piece you want back.
http://en.wikipedia.org/wiki/Chess

 

As for the sensing, magnetic reed switches and a small magnet in the base of each piece seem to me to be the most reliable and least obtrusive sensing method.

 

I don´t understand that.
Lets say you start with the beginning configuration, rows 1,2,7 and 8 are all occupied, rest is free. Now the player takes away a piece, so you notice that position B2 is free. Wonder what piece has moved? And suddenly, B3 is occupied. You got all the info you need to tell which piece moved where, don´t you? You allways know the state of the board, and moving a single piece is allways deterministic as to what and where moved.
Then you simply tell the AI game engine that the move was B2 to B3.

The only problem is promotion, where you would somehow have to tell the computer which piece you want back.
http://en.wikipedia.org/wiki/Chess

Again brilliant!!!

Now I 100% get what you mean...there is no need for a physical ID on the actual piece. each piece ID will be done in memory!!

I have to re-read that link but I had a quick scan on it a few days ago...
so this method will be tracking the location and at the same time identifying which piece is on a particular location!

I would like another opinion on this one!

Thanks!

 

As for the sensing, magnetic reed switches and a small magnet in the base of each piece seem to me to be the most reliable and least obtrusive sensing method.

ok! now what type of 'reed swich' would be most appropriate? and how many are needed? I think multiplexing will be used as suggested by Mrchips on post #14. I suggested 8 but i did not think too much...

How does this reed switch really work anyway? isn't it the weight of the piece on that switch that will close it?

I need to know about the exact component and the number needed so I can already order (of course I ll order more than needed in case I messed up with one).

 

I dn't know if someone has already suggested this. I did not see it during my quick sccan of the 28 replies.

Would you be able to simplify your robot arm if you made it so that it always picked up the piece at the same coordinates. Then you could move the chess board in the XY plane to position the piece you wish to move so that it is in the position for the robot arm to pick it up? You would then move the board to the new position where the robot arm would set the piece back down. Of course the piece that would be displaced would have to be cleared first.

hgmjr

Another brilliant one!!

I agree with you! the arm will be fixed and all it does would be pick it up and dropping it! I seriously consider this method!!

I think I will implement both method and will use the method that works first but I can tell that the implementation of this method will be fast compared to the rm moving in all location!
But th first method is the most attractive but of course complicated!!

thanks!

 

You would have to add in a few rules, for example taking a piece and castling. When taking a piece you would expect the capturing piece, and then the captured piece to be picked up, then the capturing piece put down again. With castling, you need to make sure that both parts of the move work.

 

You would have to add in a few rules, for example taking a piece and castling. When taking a piece you would expect the capturing piece, and then the captured piece to be picked up, then the capturing piece put down again. With castling, you need to make sure that both parts of the move work.

you are correct! But the sad part of it is that I have NEVER played Chess before! I can't play it...a few days ago I downloaded a pdf file + wikipedia to learn a bit about the rules of the Game. but I told myself it is not really important but I will have to know a little like in case you have mentioned!


I think we can figure out a way of solving this issue...

thanks!

 

What would be the best interface between the chessboard (mcu) and the PC?
Best in terms of ease of communication...to transmit the state of the board to the PC? Serial communication, parallel,...?

 

USB (USB to serial TTL) would be a good choice....

 

as for programming arm movements, and such, check out Microsoft's Robotic Studio....