Category: Kevin’s Status Reports

For this week’s progress, I continued with developing the board-state software. I mainly worked on representing the physical chessboard as a digital 8×8 state and I also worked on developing the logic behind comparing a previous board state with an updated state. Since the camera is currently available, I have been working with simulated board inputs to test the board-state tracking logic and made sure the software can correctly identify piece movement. I also made some progress organizing the software so that the board-state tracking can connect directly with the camera/OpenCV pipeline and python-chess move-validation system.

As of now, I feel like the project is currently on schedule with the software development side. Right now, board state tracking is most likely the most important task to complete. The main risk that has come up is just not having the hardware at the moment so I am not able to test using real images. While I used simulated boards, it could turn into a potential problem if the simulated board and images do not work the same.

For next week, I want to plan on integrating the board-state tracker with python-chess so that detected board changes can be translated into chess moves and then we can check for move legality. I will also continue using simulated move sequences to test normal moves and invalid board changes. If the camera is available, I can begin connecting the software framework to the actual camera capture and calibration pipeline.

For this week, I continued focusing on preparing the software side of the project for digital board-state tracking and the chess logic since we have not yet gotten a camera for our setup. Since I couldn’t work on the camera capture and calibration pipeline, I researched how the computer vision output will eventually feed into the digital chessboard representation, move validation, and move logging. One key component to this was looking into the python library, python-chess, which would serve as the foundation for legal moves, updating board after valid move, and generating a PGN move history.

I also began to look into how the flow of moves should be represented internally, which includes the starting square, ending square, move number, and timestamp, so that the move detection and logging can be handled more consistently later on. I did some basic research on how to have the software components run on the NVIDIA Jetson Orin Nano and how the modules should be separated so that the board state logic can potentially be tested before the vision hardware integration.

As of now, my progress has been slightly shifted since we don’t have the camera for the configuration quite yet, but I am using that time to work more on the software components. Next week, I plan to continue developing the digital board-state representation and begin testing move detection and validation using either manually generated or simulated board states. This will help me to check move validation thru the library python-chess. Another thing that I hope to accomplish is an initial move logging structure so that valid moves can be stored in sequence.

Prototyping of board-state tracking + move logging:

This week I was focused on setting up the software environment side of the project. I started looking into the initial development environment and repo structure that we will use for the computer vision, board state tracking, and game logic components. I started some initial research into reviewing how the camera pipeline will interface with OpenCV and how we can calibrate the camera to identify the game state of the board. I specifically looked into mapping the captured image to the physical 8 x 8 chessboard. In addition, I started to look at how the computer vision output can eventually be converted into a digital board state and used alongside the ArCU marker detection and chess-rule logic. For next week, I will try to implement and test the camera capture and board calibration next week before moving into ArUco marker and piece detection.