Charlie’s Progress Report for 3/14

This week, I finished building the frontend user interface for the chess application and integrated it with the existing backend components. The interface now supports visualization of the board state and user interactions with the system, allowing moves and engine responses to be displayed in real time. In addition, I began working on the LLM agent state management and retrieval-augmented generation pipeline, researching how to structure context and maintain consistent reasoning for move explanations.

My progress this week is generally on schedule. Next week, I plan to conduct user testing to evaluate the usability of the UI and gather feedback on interaction design. I will also continue developing the agent state management and RAG components to improve how the system generates and maintains contextual explanations for gameplay decisions.

Yoyo’s Status Report for 3/14

This week I modified some details of the design for the board, especially the part integrating with the LEDs. The exact measurement of the distance between the individual LEDs weren’t specified, so I had to measure it myself, and with the error in measuring by hand I need to consider tolerance in the design. I decide for the top of the board to have 3 layers, on the very top is plywood layer, which is the actual board with the grid. I am deciding between 1. cutting small circles of frosted acrylic to fill in the holes of the plywood layer to better diffuse light, and 2. simply adding a whole layer of frosted acrylic under the plywood layer to diffuse light, less work more money. And then under that will be a layer to stick our LED strips on, which will be plywood strips, to reduce weight.

And I’m also taking pictures of the chess pieces to work on the cv part. I took some under room light settings, and will need to take more after working with Claire for different colored LEDs and the lamp on the phone mount we’re using.

I’m on schedule and no big design modifications were made that needs schedule changes.

Charlie’s status report for 3/7

This week, I focused on building the frontend user interface using React and integrating it with the backend systems. I implemented core UI components for interacting with the chessboard and began setting up integration tests to verify correct communication between the frontend and backend. These tests help ensure that board state updates, move validation, and engine responses are properly synchronized across the system.

In addition to development work, I conducted further research into implementing retrieval-augmented generation (RAG) and agent state management using LangChain. This exploration focuses on how the system can maintain contextual knowledge and structured reasoning when generating explanations for moves. The goal is to design a pipeline where the engine outputs and relevant game context can be retrieved and incorporated into the LLM’s reasoning process while maintaining consistency with the validated move set.

Yoyo’s Status Report for 3/7

This week with the cut out chess pieces and half of the board I was able to test my cv code. For the phone mount we’ve decided to buy a phone holder with lamp for holding our phone camera over the board.

Currently I cut out the chess board with plywood available in techspark which I think don’t work the best for cv because it reflects light a lot. I will try to find the other kind of plywood that doesn’t have the layer that reflects light so much. With this image you can also see that the frosted acrylic shows the background without direct light on it, which also affects cv accuracy. After I get the phone holder and lamp I will use that lamp to take photos. Since we need to implement yolox model, I will need to take like 100 photos and label them so that will be my goal next week to finishand get some yolox running.

Team’s Status Report for 3/7

Team Status Report for 3/7

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

Part A – Global Factors (Written by Yoyo)

Our product aims to make learning Chinese Chess more accessible to users from different backgrounds and locations. By combining a physical chessboard with a phone-based interface, the system allows players outside of academic environments or those who may not be technologically experienced to interact with the system easily. The phone camera captures the board state while the application provides move suggestions and explanations, allowing players to learn strategies while playing on a physical board. This approach makes the learning process more intuitive and accessible to users worldwide, especially those who prefer physical gameplay over purely digital interfaces.

Part B – Cultural Factors (Written by Claire)

Chinese Chess is a traditional strategy game with deep cultural roots. Our project helps introduce this game to a broader international audience while preserving its cultural elements. The chess pieces include both the original Chinese characters and English translations so that players who are unfamiliar with the language can still understand the game while learning the traditional terminology. By supporting both language systems, the system helps users become familiar with the cultural context of the game while also lowering the barrier to entry for players who may not have prior experience with Chinese Chess.

Part C – Environmental Factors (Written by Charlie)

Environmental considerations are relatively limited for this prototype because the system does not require large-scale energy consumption or manufacturing. However, we still considered sustainability in our design choices. The board is constructed using durable materials such as plywood and acrylic so that it can be reused for extended periods rather than discarded after testing. Additionally, the system relies on a smartphone camera rather than requiring specialized imaging hardware, which reduces the need for additional electronic components. These design choices help keep the prototype relatively resource-efficient while minimizing unnecessary environmental impact.

Project Risks and Risk Management

The most significant risk to the success of the project is the integration of the system’s subsystems. The computer vision system must correctly detect the board state before the chess engine and LED guidance system can function properly. Because both the engine and LED guidance depend on the output of the vision system, errors in board detection could affect multiple components of the system.

Additionally, the LED guidance system depends on the chess engine for calculating the opponent’s moves. This creates a chain of dependencies between subsystems, which may make integration more complex than initially estimated.

To manage this risk, the team plans to begin integration earlier than originally scheduled so that potential issues can be identified sooner. If integration requires more time than expected, the team may reduce the scope of testing slightly. For example, instead of testing 100 random board states and 10 full games, we may test 50 board states and 5 full games while still ensuring that the system performs reliably.

Design Changes

At this time, no changes have been made to the existing system design, requirements, or block diagrams. The current system architecture—including the computer vision module, chess engine, LED guidance system, and mobile interface—remains consistent with the original project plan.

However, the team did make a practical adjustment related to hardware setup. Instead of building a custom phone mounting structure, we decided to purchase a phone holder with an integrated lamp. This change simplifies the setup process and improves lighting conditions for the computer vision system, which should improve image quality and detection accuracy.

Because this change replaces a custom-built component with an off-the-shelf solution, it reduces development time and introduces minimal additional cost.

Updated Schedule

The overall project timeline remains largely on schedule. This week focused primarily on development of the frontend interface and early testing of the computer vision system. Over the next week, the team will begin collecting image data to train the YOLOX model and continue developing the integration pipeline between the vision system and the chess engine.

While subsystem integration remains a potential challenge, no schedule changes are required at this time. The team will continue monitoring progress and adjust the schedule if integration takes longer than expected.

Progress and System Development

The team made several important steps toward completing the system this week.

The frontend user interface was developed using React, allowing users to interact with the chessboard and enabling communication between the frontend and backend systems. Integration tests were also started to verify that board state updates, move validation, and engine responses are correctly synchronized between components.

On the hardware side, the team constructed a prototype chessboard using plywood from TechSpark. Initial tests were conducted using cut-out chess pieces and a partial board to evaluate the performance of the computer vision system. These tests helped identify lighting and material issues that affect detection accuracy. For example, the plywood surface reflects light, which may interfere with the vision model.

To improve image quality, the team plans to use a phone holder with an integrated lamp to create more consistent lighting conditions for capturing images. The next step will be collecting approximately 100 labeled images of the board to train the YOLOX detection model.

These developments move the project closer to integrating the computer vision pipeline, chess engine, and LED guidance system.

Claire’s Status Report for 3/7

This week I worked on the starting and ending light up sequences. The starting sequences lights up the river, palace/fortress, home territory, and palace corners in blue at the start of each game as a reminder to the player of the different regions of the board. The ending sequence flashes white on the winner’s side of the board for 10 seconds. To determine which side of the board is the winner’s requires additional work and integration with the computer vision system so right now it the side of the board to flash is just a variable.

My progress is on schedule. This next week, I hope to make the connections between the strips of LEDs more secure by integrating the LED connectors that I ordered before the break. I also hope to start working on the algorithm to light up the potential moves when the player asks how a specific piece can move. My plan at the moment is to store all the ways a piece can move in a dictionary and then map them onto the board checking that they are in bounds. I will also have to switch the color if an opponent’s piece is already on one of the potential moves.