Closed djdekker closed 8 years ago
Well, I tried PicoChess latest dev with Rodent II latest dev and I can confirm this. However, it used to work in the past. :cry: I haven't tried lately this combination as I was playing Rodent with Pychess @pychess and here Rodent II is working like a charm. I'll take a look at this issue. But it will take a few days as I'm travelling and my DGT board is so unwilling to travel.
Cheers
I have no suitable hardware for PicoChess, so I must ask for help: please determine the last version of Rodent that can work with it.
PicoChess also runs without expensive DGT hardware! :smiley:
pi@raspberrypi:/opt/picochess $ sudo python3 ./picochess.py -c -e /usr/bin/rodentII
If you run PicoChess like this in console mode, with Rodent II selected as its engine, you will see in the log file that PicoChess never receives the best move, although it is clearly receiving the PV and score. Just enter a2a4
as the first move and enter go
to start the search. There's no answer coming from the engine.
Something similar is happening with the K2 engine by @serg-meus.
However, trying exactly the same procedure with, for example, Stockfish or Gull is successful: replace /usr/bin/rodentII
with /opt/picochess/engines/armv7l/a-stockf
and it works fine.
The problem is that Rodent is not answering an 'isready' command during search. It answers 'isready' with 'readyok' while not searching (08:16:26.767), but it ignores 'isready' when searching has started (08:16:26.783).
UCI specifications state that engines should also answer 'isready' with 'readyok' when search has already started.
2016-07-19 08:16:26.767 DEBUG uci - send_line: <PopenProcess at 0x74e6e650 (pid=14585)> << isready 2016-07-19 08:16:26.767 DEBUG uci - on_line_received: <PopenProcess at 0x74e6e650 (pid=14585)> >> readyok 2016-07-19 08:16:26.768 DEBUG dgtserial - write_board_command: DGT clock [ser]: locked 2016-07-19 08:16:26.769 DEBUG dgtlib - wait: clock is locked => waiting 2016-07-19 08:16:26.773 DEBUG dgtdisplay - run: received message from msg_queue: MSG_SEARCH_STARTED 2016-07-19 08:16:26.775 DEBUG uci - send_line: <PopenProcess at 0x74e6e650 (pid=14585)> << go wtime 60400 btime 64000 winc 1000 binc 1000 searchmoves c8h3 d5d4 f6e4 c8g4 f6g4 a7a5 b7b5 c7c5 e7e5 c8f5 g6g5 f6h5 a7a6 b8a6 c7c6 b7b6 c8e6 e7e6 b8c6 d8d6 h7h5 f8h6 h7h6 c8d7 e8d7 f6d7 b8d7 d8d7 f8g7 h8g8 f6g8 2016-07-19 08:16:26.783 DEBUG uci - send_line: <PopenProcess at 0x74e6e650 (pid=14585)> << isready 2016-07-19 08:16:26.783 DEBUG uci - on_line_received: <PopenProcess at 0x74e6e650 (pid=14585)> >> info depth 1 time 0 nodes 0 nps 0
Please check whether the last fix solves the issue. If so, I will release new Rodent i about 2-3 weeks.
regards,
Pawel Koziol
2016-07-19 8:21 GMT+02:00 DJ Dekker notifications@github.com:
The problem is that Rodent is not answering an 'isready' command during search. It answers 'isready' with 'readyok' while not searching (08:16:26.767), but it ignores 'isready' when searching has started (08:16:26.783).
UCI specifications state that engines should also answer 'isready' with 'readyok' when search has already started.
2016-07-19 08:16:26.767 DEBUG uci - send_line: << isready 2016-07-19 08:16:26.767 DEBUG uci - on_line_received: >> readyok 2016-07-19 08:16:26.768 DEBUG dgtserial - write_board_command: DGT clock
2016-07-19 08:16:26.769 DEBUG dgtlib - wait: clock is locked => waiting 2016-07-19 08:16:26.773 DEBUG dgtdisplay - run: received message from msg_queue: MSG_SEARCH_STARTED 2016-07-19 08:16:26.775 DEBUG uci - send_line: << go wtime 60400 btime 64000 winc 1000 binc 1000 searchmoves c8h3 d5d4 f6e4 c8g4 f6g4 a7a5 b7b5 c7c5 e7e5 c8f5 g6g5 f6h5 a7a6 b8a6 c7c6 b7b6 c8e6 e7e6 b8c6 d8d6 h7h5 f8h6 h7h6 c8d7 e8d7 f6d7 b8d7 d8d7 f8g7 h8g8 f6g8 2016-07-19 08:16:26.783 DEBUG uci - send_line: << isready 2016-07-19 08:16:26.783 DEBUG uci - on_line_received: >> info depth 1 time 0 nodes 0 nps 0
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/nescitus/Rodent_II/issues/33#issuecomment-233542443, or mute the thread https://github.com/notifications/unsubscribe-auth/ABEHaNYXK6ATCuXRGHiJsvg5ADfVsVLIks5qXGzugaJpZM4I-2qD .
Thanks Pawel. I just built Rodent II 0.9.51 and am still seeing an 'isready' without 'readyok'... :( So the issues is not solved yet.
It's in the log below at 2016-08-02 13:57:11.859.
2016-08-02 13:57:11.825 DEBUG uci - send_line: <PopenProcess at 0x6cdf0150 (pid=746)> << position startpos moves e2e4 e7e5 a2a4 2016-08-02 13:57:11.828 DEBUG dgtiface - process_message: handle DgtApi: DGT_CLOCK_STOP 2016-08-02 13:57:11.829 DEBUG uci - send_line: <PopenProcess at 0x6cdf0150 (pid=746)> << isready 2016-08-02 13:57:11.830 DEBUG dgtserial - write_board_command: put DGT board [DgtClk.DGT_CMD_CLOCK_SETNRUN], length: 12 2016-08-02 13:57:11.831 DEBUG uci - on_line_received: <PopenProcess at 0x6cdf0150 (pid=746)> >> readyok 2016-08-02 13:57:11.839 DEBUG dgtdisplay - run: received message from msg_queue: MSG_SEARCH_STARTED 2016-08-02 13:57:11.846 DEBUG uci - send_line: <PopenProcess at 0x6cdf0150 (pid=746)> << go wtime 298700 btime 300000 searchmoves f8a3 f8b4 d8h4 a7a5 b7b5 c7c5 f8c5 d7d5 f7f5 g7g5 d8g5 a7a6 h7h5 c7c6 b8a6 b7b6 g8f6 g7g6 g8h6 b8c6 f8d6 d7d6 d8f6 e8e7 g8e7 f7f6 h7h6 d8e7 f8e7 2016-08-02 13:57:11.847 DEBUG dgtserial - write_board_command: DGT clock [ser]: locked 2016-08-02 13:57:11.861 DEBUG dgtlib - wait: clock is locked => waiting 2016-08-02 13:57:11.859 DEBUG uci - send_line: <PopenProcess at 0x6cdf0150 (pid=746)> << isready 2016-08-02 13:57:11.860 DEBUG uci - on_line_received: <PopenProcess at 0x6cdf0150 (pid=746)> >> info depth 1 time 0 nodes 0 nps 0 2016-08-02 13:57:11.874 DEBUG uci - on_line_received: <PopenProcess at 0x6cdf0150 (pid=746)> >> info depth 1 time 1 nodes 4 nps 4000 score cp 30 pv d7d5 e4d5 d8d5 2016-08-02 13:57:11.847 DEBUG dgtdisplay - process_message: Search started 2016-08-02 13:57:11.877 DEBUG dgtdisplay - run: received message from msg_queue: MSG_USER_MOVE 2016-08-02 13:57:11.884 DEBUG picochess - main: received event from evt_queue: EVT_NEW_SCORE 2016-08-02 13:57:11.897 DEBUG dgtdisplay - run: received message from msg_queue: MSG_NEW_SCORE 2016-08-02 13:57:11.900 DEBUG uci - on_line_received: <PopenProcess at 0x6cdf0150 (pid=746)> >> info depth 2 time 2 nodes 32 nps 16000
in that event can You perform a binary search to determine which commit stopped responding to isready?
regards,
Pawel Koziol
2016-08-02 16:05 GMT+02:00 DJ Dekker notifications@github.com:
Thanks Pawel. I just built Rodent II 0.9.51 and am still seeing an 'isready' without 'readyok'... :( So the issues is not solved yet.
It's in the log below at 2016-08-02 13:57:11.859.
2016-08-02 13:57:11.825 DEBUG uci - send_line: << position startpos moves e2e4 e7e5 a2a4 2016-08-02 13:57:11.828 DEBUG dgtiface - process_message: handle DgtApi: DGT_CLOCK_STOP 2016-08-02 13:57:11.829 DEBUG uci - send_line: << isready 2016-08-02 13:57:11.830 DEBUG dgtserial - write_board_command: put DGT board [DgtClk.DGT_CMD_CLOCK_SETNRUN], length: 12 2016-08-02 13:57:11.831 DEBUG uci - on_line_received: >> readyok 2016-08-02 13:57:11.839 DEBUG dgtdisplay - run: received message from msg_queue: MSG_SEARCH_STARTED 2016-08-02 13:57:11.846 DEBUG uci - send_line: << go wtime 298700 btime 300000 searchmoves f8a3 f8b4 d8h4 a7a5 b7b5 c7c5 f8c5 d7d5 f7f5 g7g5 d8g5 a7a6 h7h5 c7c6 b8a6 b7b6 g8f6 g7g6 g8h6 b8c6 f8d6 d7d6 d8f6 e8e7 g8e7 f7f6 h7h6 d8e7 f8e7 2016-08-02 13:57:11.847 DEBUG dgtserial - write_board_command: DGT clock
2016-08-02 13:57:11.861 DEBUG dgtlib - wait: clock is locked => waiting _2016-08-02 13:57:11.859 DEBUG uci - sendline: << isready 2016-08-02 13:57:11.860 DEBUG uci - on_line_received: >> info depth 1 time 0 nodes 0 nps 0 2016-08-02 13:57:11.874 DEBUG uci - on_line_received: >> info depth 1 time 1 nodes 4 nps 4000 score cp 30 pv d7d5 e4d5 d8d5 2016-08-02 13:57:11.847 DEBUG dgtdisplay - process_message: Search started 2016-08-02 13:57:11.877 DEBUG dgtdisplay - run: received message from msg_queue: MSG_USER_MOVE 2016-08-02 13:57:11.884 DEBUG picochess - main: received event from evt_queue: EVT_NEW_SCORE 2016-08-02 13:57:11.897 DEBUG dgtdisplay - run: received message from msg_queue: MSG_NEW_SCORE 2016-08-02 13:57:11.900 DEBUG uci - on_line_received: >> info depth 2 time 2 nodes 32 nps 16000
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/nescitus/Rodent_II/issues/33#issuecomment-236914665, or mute the thread https://github.com/notifications/unsubscribe-auth/ABEHaLJcXemacB8iEFS1TxD450GlbTFBks5qb060gaJpZM4I-2qD .
Hi Pawel,
This is not needed anymore. :smile: Niklas has updated the python-chess libraries just an hour ago. Python-chess is no longer sending 'isready' after 'go', so Rodent II isn't stalling with PicoChess anymore! :thumbsup:
Greetings, DJ
Hi Pawel,
I'm using Rodent II with PicoChess using the python-chess library by niklasf. I compiled the Rodent II binary (version 0.9.44) on Raspberry Pi 3 with -march=armv6.
Now the following problem occurs while playing with PicoChess against Rodent II. When the engine leaves the opening book, it becomes unresponsive. The same happened with a couple of other engines like Cinnamon (which has been fixed now), Floyd (fixed in version 0.8.1 with a temporary fix) and K2 (not fixed yet).
The cause of the problem may be related to the way engines handle an 'isready' command during search. According to the UCI standard, an engine should answer 'isready' with 'readyok' without stopping its search. As niklasf explained in the case of Floyd, the python-chess library actually sends 'isready' commands early in the search process. He also provided a fix for the Cinnamon engine.
Could this behaviour of python-chess be a problem for the Rodent II engine, too?
DJ