Winboard Forum

I am on a college project of making a chess playing Robot. Most of the Hardware and controlling parts are done. I now just need to do the Chess software parts. For this I have been searching for quite a time now and I got winboard. I am doing most of my programming in matlab. I now need some way to communicate with external programs such as winboard itself. I want it to go like this
1. I command to start a new game (white/black)
2. I send it the move made by user
3. It should send me back the best move.

I don't want to (actually I also don't know how) directly communicate with chess engine because that involves doing a alot of work on my part , such as, setting the options, difficulty, checking if moves are valid, opening books etc etc which I don't even know. I would like to set these options from external program. In short, I just want the normal winboard program but just with 2 enhancements
1. Accept the user-move from matlab through simple interface
2. Return back the computer move to matlab again through simple interface.

Can some one point me to what I should be doing?

It seems to me that the best solution would be to make your robot driver mimic an engine. I don't know Matlab, but if the program to control the robot you have written in it takes its commands through typing to the standard input (like typing 'e2e4' or 'usermove e2e4' to make the robot perform the move), it could be used as a WinBoard engine with only little modification. You would just have to make it such that it reacts to the 'new' command by setting up the board in the initial position. I suppose your robot has sensors of some sort (perhaps a camera) that allow it to detect the moves of its opponent, and if you detect such a move, the Matlab program should simply print it on the standard output as 'move e7e5'.

Letting the driver communicate that way on its standard input and output would allow you to run it as a WinBoard engine under any GUI that supports WinBoard protocol. In the case of WinBoard you could even make use of some undocumented features to let the robot have control over the GUI for setting up positions. (I.e. allow the user to set up a position on the board, let the robot recognize it, and send it to WinBoard to display it on the board there as well.)

Hi H.G. Muller,
Thanks for your response
Your idea is completely doable. I could easily make the matlab software such that it responds to standard input command such as move e2e4, etc. So, the robot sensors would mimic the engine. But the problem is, we have now made the Human (player) the engine, because the sensors sense the players move. (BTW, the sensors aren't such sophisticated as you might have imagined. Its just an array of buttons, sort of ). Now, after the first move done by the engine ( human in this case), who is going to make the second move? If there is a provision for engine match, then Perhaps, I could use a second genuine engine to do the second move. Is that available?.

Yes, sure, that was the idea. Use WinBoard in 'Two Machines' mode, so that it is playing the 'human engine' against the silicon engine. That should not be a problem. (Well, perhaps it would be after a user sets up a non-standard position. But I am not sure if you want to allow that anyway.)

You could even set WinBoard to 'match mode', so that it will automatically start a new game after the previous one finishes.

I have made a similar pseudo-engine for playing on a Chess server with some non-standard protocol. There were ways to make WinBoard wait starting the clocks before anyone on the server challenged it. (IIRC this was by delaying a 'pong' response to WinBoard's 'ping' command until a challenge came in from the server.) I had to use a trick to control the color as well, as both WinBoard and the server would assign a color independently, so they would not always coincide. When that happened I simply let the pseudo-engine resign the game towards WinBoard, so that WinBoard would automatically and immediately start a new game with reversed (and thus correct) colors, and then play that game. WinBoard does not save games without any moves in the PGN file anyway.

Learning,

Your project sounds like fun. Keep us posted on your progress and results. A lot of readers will be interested.

Ideally, post a link to some photos somewhere, (or video!) so we can see it in action.

Hi H.g.-Muller,
I just Downloaded and installed Win-board V 4.2.7. Yes there is provision for engine match.
I have quickly read through the chess-engine-communication protocol. So, I have seen two likely trouble I may get into
1. What will happen if my Human Engine returns back an illegal move to winboard. After it relays the move to the silicon engine, the engine will issue illegal move warning. Will the warning be relayed back to the human Engine? If that goes like that its fine.
2. As Hg-Muller already pointed out, I don't see any provision where an engine (in this case human engine) can request to set-up positions.

Since, these two problems don't stop me immediately, (I can just ignore them for now; assume human don't make error, and no provision for board setup) I am now going to start writing up program.

Thanks.

@EdCollins I sure will post here about progress I make, with photos and all. And I will be needing some help too! . But, it will take some time before I come-up with something worth showing up.

Indeed, illegal moves would be a problem. WinBoard can be run with or without legality checking; when the latter is on, it would not even send the illegal move of one engine to the other, but it would simply forfeit the engine making the illegal move. With legality checking off, the move would always go to the opponent engine, which presumably would refuse it through an 'Illegal move' reply. (Not all engines check legality of their input moves, btw; I think Pulsar doesn't, for instance.) WinBoard would then take back the move on the display. I am not 100% sure that it would also do this in Two Machines mode, and if in that case undoing the move in the display would also lead to sending an 'undo' command to the engine that originally made the move. Usually this would be pointless, because the engine would likely make that same illegal move again, and you would get into an infinite loop of illegal moves and takebacks.

An alternative is to force the engine to accept any move. There is an option (undocumented, I think) -forceIllegalMoves true|false, which forces engines to accept a move they consider illegal by setting up the position after that move through a setboard command to the engine. I don't think this works in versions older than 4.5.0, though.

I could easily add an option to WinBoard that sends 'undo' to engines that do an illegal move. (Or perhaps it would be better to let the user actually define what should be sent to the engine, e.g. -illegalMoveReply "undo", so that the engine could also implement a command not specified in WB protocol (e.g. "refused") that would make it replace its last move by another one. You could make the robot driver undo the move the human just did, on reception of this command.

I think you will find that WinBoard 4.4.0 (and perhaps even 4.3.15) and later will respond to a 'setboard' command sent by the engine. I am not sure this will keep it in match mode, though.

Hi again friends,

Please Have a look at where I have reached. I will be very-soon connecting to the real robot.
http://www.youtube.com/watch?v=XUP-YYfE2bg


In the mean time I am afraid I need your help. There are few things I would like win-board to do for me
1. Send me undo command if I send Illegal move (previously discussed)
2. And when sending me the other-engine's move, mention whether it is a move to blank position or a capture. This is necessary because if its a capture I need to move away the piece being capture before moving the capturing piece.

It would be a great help if you could modify winboard (perhaps make new version of winboard) to include these features. Perhaps it would be better if you could add an option just for these kind of problem, like engine-Vs-pseudo_engine match. Assume pseudo_engine don't have their own brain, so you should provide it many more information. This pseudo_engine may be say
1. A robot dirver, like my case
2. Another chess gui (may be with awesome 3d graphics) which people are happy to make but can't bother to establish pipes-connections-etc with chess engines.

Also, since the robot takes some time to execute its move, it would be very helpful if we could keep increasing crafty's time (and stopping humans time) until the robot finishes its move.

Hi,
Perhaps I could myself do those works!
Where can I find the source code for the latest version of winboard?
Thanks.

You could start from the sources of the latest stable version from the GNU-savannah website ( http://savannah.gnu.org/projects/xboard/ ). It is a very non-trivial program, though, and even setting yourself up to compile the unmodified version might be a major task. (I use Cygwin + gcc to compile it).

It seems that for the clock problem you need some extension of WinBoard protocol, allowing the (pseudo-)engine to tell the GUI when it finished doing the move. Or we could use dummy 'thinking output' of the pseudo-engine to trigger this. In any case, what is needed is to implement a clock mode in WinBoard where the clock is not automatically switched when the move is made on WinBoard's internal board (i.e. the display), but when the first thinking output of the engine that was just set thinking is received. For true engines this would be almost instantly. Your robot-driver pseudo-engine could be programmed to send a line

0 0 0 0 move done

as soon as the robot has withdrawn its arm then, to trigger the clock switch. It might also be needed to ly against the true engine about the time it has on its clock. Otherwise it might try to use up the time on its clock to the last second, on the move just before the time control, and then be flagged because it cannot physically perform the move in time before its clock runs out. Unfortunately the time it takes to perform the move is really dependent on what the move is, but has to be relayed to the engine before it starts thinking on it. What you would really need is an engine that encorporates the time it takes to perform the moves in its evaluation, under time pressure. (The way humans move the King close to the clock in bullet end-games.)

The undo part should be easy; some SendToProgram call should be added in the routine HandleMachineMove (in backend.c), when it detects reception of an "Illegal move" message.

As to knowing if the target square was empty or not, this seems more a task of the robot. It seems best to keep the robot pseudo-engine as close to a normal Chess engine as possible in behavior, so it would not be too dependent on WinBoard modifications, and could also run under different GUIs. WinBoard protocol has an option to let the GUI send moves in SAN, where the capture would be obvious from the 'x' in the move, but I guess this only would compound the problem, because in SAN the from square is not given. But surely the robot must be able to detect which squares are occupied? (Even if it does not remember it.) How else would it detect the human move?

How does your robot handle e.p. capture or castling, btw? Not to mention promotions...

Hi,
I downloaded, xboard-4.5.2a.tar.gz , extracted the content, moved into winboard directory and opened the winboard.dsw MS VC++ workspace. I then tried compiling the project and was hit with thousands of warnings and these 2 errors.

1>Linking...
1>CVTRES : fatal error CVT1100: duplicate resource. type:MANIFEST, name:1, language:0x0409
1>LINK : fatal error LNK1123: failure during conversion to COFF: file invalid or corrupt
1>Build log was saved at "file://D:\xboard-4.5.2a\xboard-4.5.2a\winboard\Debug\BuildLog.htm"
1>winboard - 2 error(s), 671 warning(s)
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========
And, I am quite positive that there will be lot more errors I will encounter.

Since, as you already told, compiling this isn't an easy job, are there any step-by-step wiki that guides us to compiling our own winboard?

As, a secondary question, my pseudo-engine written as a console program sucks up astonishing 50% CPU of my dual core CPU while it is thinking. Its acceptable for genuine engines. And Indeed fmax also consumes same amount of CPU while thinking. But my-pseudo engine don't have much anything to do. It just needs to periodically Poll a disk-file to check if new move has arrived (from the matlab-robot-interface). Is there some-way to reduce its CPU consumption?

You are right, I should be able to find out if the target square is empty or not, I was just wishing if an easy route was available

As for the time control, I don't need that level of optimized time control. This Robot isn't going to beat grand-masters, but only local-masters. So, only a mere decreasing of the computer time by fixed time (as a reserve for executing move) should work.

Why? castling should be easy. If I get 0-0 I order the robot to first move the king then the rook.(I know where the king and the rook resides ) If I get 0-0-0 I do the same.For capture, I first remove the piece being captured then move my piece. (So, first for everymove, I need to check if its a capture ).
Promotions seems hard. Perhaps I will do that manually.

Perhaps you can have several ordered pieces next to the board that the robot can reach, like the bank in xboard/winboard for bughouse. Or really a couple extra queens, how often do chess engines promote to anything else?

None of the WinBoard developers (i.e. neither Arun, nor I) have MSVC, so it is quite possible that the dsw file is not sufficiently updated. I only know how to compile WinBoard under Cygwin, using the supplied makefile.gcc. But if we can define which extra features are needed, I can put them in for you.

I_am_learning wrote:Is there some-way to reduce its CPU consumption?

Poll less frequently? (E.g. put a sleep(1); in the polling loop.)

Why? castling should be easy. If I get 0-0 I order the robot to first move the king then the rook.(I know where the king and the rook resides ) If I get 0-0-0 I do the same.For capture, I first remove the piece being captured then move my piece. (So, first for everymove, I need to check if its a capture ).
Promotions seems hard. Perhaps I will do that manually.

Beware that WinBoard will not send O-O for castling (unless it is playing Chess960), but e1g1 or e1c1. The pseudo-engine should be smart enough to know that implies a Rook move as well, when it receives it without the King having been moved. For en-passant captures it would also only print, say, e5f6, and the engine should be smart enough to realize that makes a Pawn on f5 disappear.

Thanks H.G. Muller,
Following are the features I require with decreasing priority
1. Keep sending undo command to the illegal moving engine until it sends valid move.
2. Indicate weather the move produces a check / checkmate! (So that I can order the robot to speak appropriate words)
3. Append an e for en-passant if in the move e5f6e to distinguish it from same move that can be made without en-passant (say a bishop move).
and apppend an C for castling such as e1g1c to distinguish it from same move that can be made but not castle such as say a rook move near endgames.
4. Make provision for time correction as we have discussed.
(stop 1st chess engine's time until the second engine gives thinking response. Tracking this delay allows to estimate the amount of time required to execute the move. So, always decrease this amount of time from 1st engines time, as a reserve time for executing move)
5. Append an x for captures, (Although I can do it myself)

No. 3 & 5 only means I need kind of new chess notation.

And, Oh! thanks, Sleep(1) did the trick!

I think that doing 3 and 5 in WinBoard is a bad solution. It is probably easier to solve those problems in the peseudo engine, and would make the latter very non-standard if you change the Chess notation. You cannot avoid some intelligence in the pseudo-engine anyway; even if you know a move is a castling it would have to figure out which Rook to move and where.

All you would have to do in the pseudo-engine is keep a board where you can see which pieces are Kings and which Pawns (e.g. empty=0, pawn=1, piece=2, king=3), and move them around as instructed by WB or the human. Then, if you get e1c1 or e1g1 when a King is on e1, you know it is a castling, and when you get a Pawn move to an empty square on another file you know it was an e.p. capture.

When the game ends WB will send a 'result' command; from that you could deduce who is checkmated.

oh! thanks,
int chess_board[8][8]
empty = 0; pawn =1 etc
will certainly do the trick for me.
I had been thinking, doing anything related to chess in my part would be too difficult, but I now see, its quite easy to do some of the parts.

No. 3 and 5 are off now.
Yes, checkmate can be deduced from result command.
Perhaps I can also calculate if a move produces a check by looking around in the chess_board I maintain.

Then, yes, only 1 and 4 should suffice.
Talking about 4, when playing over the internet, isn't there a need for time correction, just like my case, because there might be delay in sending the moves?

Hi
I hope you are enjoying good health , Sir I am Electrical engineering student and doing same project as yours , "Robotic arm for chess and Chess Brain" , In it for game situation analysing I am using computer vision technology in MATLAB , this part is done . Now i want interface chess engine with MATLAB code ,for this I need your help , i have googled alot about this , please help me or guide me about this , I will be very thankful to you

hi hafizluqman,
I have created an explicit step by step guide for interfacing matlab with chess engine, for you, here
https://sites.google.com/site/therajendraadhikari/publications/chess-playing-robot
Enjoy.

Hi everyone

I am new to this forum

It is good to note that action has been initiated for chess robot and i also viewed the video on the youtube. I must congratulate everyone for their contribution. I am surprised to note that the form has not been continued after that. I am interested to know the developments. please post the developments

Hi All

In continuation to my earlier comment,

I am also put my self in developing a chess playing robot. The following will be my development path

First i plan to develop an application in VB or VB.net to interact with winboard to capture the movements

Is there any way for the winboard to update movements in a textfile and can it possible for the winboard to read another textfile for the opponent movements.

Second by reading the movement i can make my robot to place the target item in the appropriate place.

if any one can clarify my request i would be gladly continue this forum for exchange of ideas.

Vinaiks