Posted on

Claire’s Status Report for 2/21

This week I started to implement the LED system code to index into the different placements on the board. I had used my previously existing code that was meant for our previous idea of using an Arduino so plan to to transfer my existing logic to the Raspberry Pi 4 that we ordered. Right now, I am able to light up a given number of LEDs at a given position at a given color. In the end product, I will have to translate the computer vision’s FEN string into these 3 parameters. We also finished our Design Presentation, which also let us finish planning for the small details of our project like how the different subsystem will communicate with each other.

My progress is on schedule. This next week, I hope to complete coding and testing the starting and ending sequence. These are the small light up “shows” at the beginning of the game to show the player the different zones like the river and also the end to show which side of the board won. I also hope to get started on the logic to figure out which LED’s should light up which color based on how optimal the move is or not.

Posted on

Charlie’s Status Report for 2/21

This week, I have completed our Design Presentation and begun to incorporate feedback into our system architecture. On the implementation front, I have completed the rule validation layer and full game state tracking, including turn management and legal move constraints. I have also started working on the move generation system, organizing it in a way that allows it to cleanly interface with the existing validation system and future search algorithms.

Concurrently, I have begun working on unit tests to ensure correctness and started to benchmark the current engine performance. I started working on the user interface for the chessboard to enable visualization and interaction with the engine. Because of the extra time needed for proper testing and integration, I am currently a little behind schedule.

Posted on

Yoyo’s Status Report for 2/21

This week on the physical chess pieces and board, I laser cut a few chess pieces out using frosted acrylic, and the top piece of the board using plywood. This is sufficient for initial testing of cv, the remaining pieces of the board can be cut out anytime after we have finalized all the physical electrical components and know the exact volume we need to hold all the parts. Also since we might need to change the design of the chess pieces later to increase board state detection accuracy, I didn’t cut out the full set of pieces, just 4 for each player for cv testing.  The parts are not with me but I’ll update images once I get a chance.

I also worked on the cv part, wrote more code for it, and will began testing next week. I am a little behind schedule on this part, as we changed our design a little last week and just got to manufacture the pieces, but I will catch up next week on this mainly.

I will also need to design the holder for the phone camera to be fixed above the board next week.

Posted on

Team Status Report for 2/21

The most significant risks that could jeopardize the success of the project is the board state detection accuracy, which hasn’t change since last week. We are aiming for above 95% accuracy but that is 1 wrong move in 20 total moves and each game is around 40-60, which we believe is a non negligible amount of misreads that could potentially affect the game. We hope to obviously beat this 95% accuracy and we will come up with a robust testing metric to see when it is specifically failing, if it does at all, like not being able to read specific pieces or in specific conditions. As we get to cut out the physical board and pieces, we will be working on solving this problem and increasing the accuracy.

We do not have any changes to the existing design requirements and have no updates to the schedule.

 

For individual status reports, see:

https://course.ece.cmu.edu/~ece500/projects/s26-teamd3/2026/02/21/yoyos-status-report-for-2-21/

https://course.ece.cmu.edu/~ece500/projects/s26-teamd3/2026/02/21/charlies-weekly-report-for-2-21/

https://course.ece.cmu.edu/~ece500/projects/s26-teamd3/2026/02/21/claires-status-report-for-2-21/

Posted on

Team Status Report for 2/14

A was written by Yoyo, B was written by Charlie and C was written by Claire Lee.

A: As of safety perspective, our hardware designs minimizes physical risks by enclosing all electronics inside the board,  so user interaction with the electronic components are limited. Users will only be interacting with their phone and the acrylic chess pieces. As of welfare aspect, our product will provide guidance and feedback to beginners who are frustrated when learning Chinese chess. Users will understand and learn from their mistakes, which will support positive cognitive development and give them motivation and confidence to keep learning.

B. Our project relates to social factors by supporting cultural preservation. Xiangqi is deeply embedded in Chinese and East Asian communities and serves not only as a competitive game but also as a social and cultural practice that connects generations. By building a guided engine that explains moves and strategies rather than simply optimizing for winning, the project supports knowledge transfer across cultural and age groups, making the game more accessible to beginners and diaspora communities who may not have access to in-person mentors. From a broader social perspective, the system also addresses educational equity and access.

We changed the material and design for our chess pieces this week, from 3D printing to laser cutting frosted acrylic.  It will make LEDs under the pieces easier to see by user. It will be easier for rapid prototyping because it takes less time to make new pieces. We haven’t printed anything out yet so making this change won’t cost anything more.

C: Our system aims to be relatively affordable since it is a learning tool for households or children at schools. The goal would be to distribute it as a fully assembled consumer product to classrooms or houses. We are on track to making the production cost feasible for our audience since our project doesn’t require too much hardware. We need the LEDs, a Raspberry Pi 4, power source, camera, and laser-cut board. If our project were to be produced at scale, these components are relatively inexpensive and the most costly piece may be the wiring of the LEDs since that could potentially be a bit complicated. We were able to cut costs and use inexpensive materials because our project doesn’t require any sophisticated data like a very high frame rate from the camera. We also believe our product to be able to keep sustainable demand long term since buy a reusable, flexible, portable board is a more personalized experience than hiring a teacher since the player can set the pace of the game and the pace of their learning. Even if the player may not need assistance from the guided part of the product, they can still use the board and piece of play at leisure and if we wanted to launch any updates, we could allow the firmware to be updated over USB so older models can still have the new features.

 

The most significant risks that could jeopardize the success of the project is the board state detection accuracy. We are aiming for above 95% accuracy but that is 1 wrong move in 20 total moves and each game is around 40-60, which we believe is a non negligible amount of misreads that could potentially affect the game. We hope to obviously beat this 95% accuracy and we will come up with a robust testing metric to see when it is specifically failing, if it does at all, like not being able to read specific pieces or in specific conditions. Once we pinpoint the issues, we will come up with a solution on how to manage them like maybe building proper lighting into the board itself.

We changed the existing design of the system to specify that the voice command portion of our project was a stretch goal and not part of the MVP. This change was necessary because we realized it was not crucial to the experience of guided learning and we would have to build a UI anyway so we might as well make it accessible to the user. No cost was incurred because we didn’t buy any parts for this subsystem or spend any time building it since we knew that the majority of our project was through the other subsystems, which is what we were focusing on.

For individual status reports, see:

Yoyo’s Status Report for 2/14

https://course.ece.cmu.edu/~ece500/projects/s26-teamd3/2026/02/15/charlies-weekly-report-for-2-14/

Claire’s Status Report for 2/14

Posted on

Claire’s Status Report for 2/14

What did you personally accomplish this week on the project? Give files or
photos that demonstrate your progress. Prove to the reader that you put sufficient
effort into the project over the course of the week (12+ hours).

This week I ordered the LED strips, Raspberry Pi 4, and power source that I need to build the LED light up system. I also wrote some Arduino code that to index into the LEDs using a pre-existing library for these specific LEDs. I hope to test them next week now that they have been delivered. I also discussed the communication protocol between our different subsystem more meticulously with my team and landed on specific protocols/formats like receiving the state of the board as an FEN string instead of coordinates and having the LED light up system communicate directly with the computer vision instead of the chess engine. We also worked on the Design Presentation Slides and talked more about the details like what the different colors of LEDs mean and other details.

Our progress is on schedule.

Next week I hope to test the LED indexing code and tweak it to correctly work for the 9×10 setup of the board. I also hope to get started on the starting and ending sequence code where at it will highlight the different zones of the board like the river and the opponent’s side and player’s side and also flash the LEDs upon a win.

Posted on

Charlie’s Status Report for 2/14

This week, I focused on preparing the Design Presentation and refining the system’s user interaction model. In addition to slide development and updating system diagrams, I designed and began implementing the user interface for the chessboard, including real-time board state visualization synchronized with the engine. A key design change was shifting from a primarily voice-controlled interaction model to an interface that includes explicit on-screen controls alongside the live camera feed and board state display. This adjustment improves usability, reduces ambiguity in user input, and provides more reliable interaction during testing and demonstrations while still supporting guided feedback from the engine.

Posted on

Yoyo’s Status Report for 2/14

This week on the chess pieces part, we changed our design a little bit after discussing with professor and TA. Instead of 3D printing we will be laser cutting frosted acrylic sheets and glueing pieces together to make sure the LED lights on the board can be seen when pieces are placed on the grid points that are supposed to light up to indicate suggested move. So I made new CAD drawings for the pieces, and will be cutting them out next week. 

I also have the board design. It will be cut out with plywood next week as well. There will be details that might change as I get to designing the holder for phone.

I am working on the computer vision portion as well, and after pieces and board gets cut out next week, I will be able to move on to adjusting and calibration with actual pieces and boards.

I am on schedule with computer vision, and next week I will be manufacturing the chess pieces and boards.

Posted on

Charlie’s Weekly Report for 2/7

This week, I focused on refining the architecture for the engine’s decision-making system by researching search-based algorithms and LLM orchestration. Instead of fully switching to a deep reinforcement learning approach as originally planned, I proposed a more practical and reliable baseline using Negamax search with alpha–beta pruning and fixed depth for efficient and deterministic move generation. I also planned an extension where machine learning is used only for position evaluation and move ordering, trained offline using Xiangqi datasets. This hybrid approach keeps the core engine stable and debuggable while still allowing performance improvements from learned heuristics.

I also looked into LLM-based explanation generation using pruned move sequences from the search as structured context for reasoning about multi-move strategies. Initial testing with vLLM and Gemini showed frequent hallucinations, including incorrect checkmate claims, so I plan to constrain the model to validated candidate moves and add rule-based verification to ensure explanations match the engine’s output. My progress is on schedule, and next week I will begin implementing the Negamax search, integrating it with the current move generator, and prototyping the evaluation interface for future ML integration.

Posted on

Team Status Report for 2/7

The most significant risks that could jeopardize the success of the project is the integration of all of subsystems not working. We are worried about the format of the input and output files of the computer vision, chess engine, and led system all working together and being the same format. We also want to flush out a better idea of how we will send these outputs to each other’s systems. For example, we know that from the chess engine to the LED system, we plan to use HTTP commands but we want a better idea for all the directions of communication. We will manage risk by deciding on a set format and mode of communication before building our subsystems.

We do not have any changes to the existing design requirements and have no updates to the schedule.

For individual status reports, see:

Yoyo’s Status Report for 2/7

Charlie’s Weekly Report for 2/7

Claire’s Status Report for 2/7