Posted on

Team’s Status Report for 4/25

Unit Tests:

  • CV Pipeline
    • Tested piece detection on single-piece and multi-piece images
    • Verified correct grid mapping after ArUco-based warping
    • Checked FEN consistency across repeated captures
  • Chess Engine
    • Validated legal move generation across edge cases (check, capture, invalid moves)
    • Verified no illegal moves are returned to downstream modules
  • LED System
    • Tested LED addressing and color mapping correctness
    • Verified correct highlighting for legal moves and best move
  • LLM Pipeline
    • Tested that generated suggestions are always legal (engine-bounded)
    • Verified latency under different prompt lengths

We conducted end-to-end system testing under realistic gameplay scenarios.

We found that LLM latency was quite long which made the overall latency of running the whole pipeline longer than we wanted, therefore we decided to use a token-limited setting and was able to boost the latency.

The most significant risks that could jeopardize the success of the project is the Raspberry Pi needing to be reflashed right before the demo, because we have faced some instances were we are forced to reflash and reupload our code. Another risk is our hotspot not working fast enough or at all in the location of the demo, which is needed by all 3 of our subsystems.

There were no changes to the existing design of the system.

Posted on

Claire’s Status Report for 4/25

This week I finished the verification of the LED subsystem. I tested the remaining 3 full games for the move suggestions and the 30 board states for the latency and move suggestion accuracy. These last three games ended up having 99% average accuracy and 185ms average latency, which meets the <200ms metric we were aiming for. I also added tests to tell the latency between when the chess engine send an API request to the LED subsystem to turn on the opponent’s moves and when the LEDs are actually turned on. This is in addition for the 7 full games and 70 board states I collected last week where we had slightly less accuracy at 98% and also around a 185ms average latency. We did not make any design changes after the analysis of these test results since these meet the metric we were aiming for and we thought the experience of playing the game was how we envisioned. One thing we did talk about adding is a button for when the player is done making either their move or the opponent’s move so that the LEDs could be turned off for the CV, which hasn’t been trained with the LEDs lit under the pieces.

My progress is on schedule. Next week, I hope to finish the report and poster to be ready for the demo.

Posted on

Team’s Status Report for 4/18

The most significant risks that could jeopardize the success of the project is the verification and integration of the subsystems. All of the subsystems are integrated in pairs of two like the computer vision with the LED subsystem and the chess engine with the LED subsystem and the computer vision with the chess engine, but we still need to verify that all of the subsystem can all function as one. We are also slightly worried about our hotspot speed, brightness of the room, and height of the table because all of these factors during the demo can affect the experience of our project.

There were no changed to the existing design of the system.

Posted on

Claire’s Status Report for 4/18

This week I integrated the LED subsystem with the computer vision system and the chess engine. I formatted my functions that can show the move suggestions and the opponent’s moves as API function calls so that the integration engine could send requests in real time. I also started the verification process by testing 7 full games and 70 board states for the latency and the accuracy of the move suggestions.

We are on schedule. The next week I hope to finish the verification of the integration of all the subsystems like testing the remaining 3 full games for the move suggestions and the 30 board states for the latency and move suggestion accuracy.

As I’ve designed, implemented and debugged my project a new tool I learned to use was the Raspberry Pi Imager to flash my Pi and upload code onto it. I read Intro to Robotic’s documentation on how to connect to a Raspberry Pi as a learning strategy to acquire this new knowledge.

Posted on

Team’s Status Report for 4/4

The most significant risks that could jeopardize the success of the project is still the integration of the subsystems. We did not realize that the computer vision portion may be more complicated than intended and that the output format we chose, an FEN string, may be harder for the other subsystem for interpret than intended. These risks are being managed by building the portions of all 3 subsystems that depend on the CV in conjunction so that any tweaks to make either side of the exchange easier can be done and tested more quickly.

There were no changes to the existing design of the system.

We are planning to run the CV, move suggestion, opponent move generation on 100 different board states and testing the accuracy. Each subsystem during these 100 different boards states will also be measuring the latency and seeing whether they are under our goals of 500ms, 100ms, and 5s respectively. We also plan to run 10 full games to see whether the move deemed “most optimal” is indeed the most optimal and also whether the LLM is able to provide meaningful help during these 10 games.

Posted on

Claire’s Status Report for 4/4

This week I reordered the LEDS to consistently skip 2 LEDs in between even with the slack at the ends. I tried to store the power bank, Raspberry Pi, and breadboard is a way that preserved the structure of the wires by unplugging all of these individual components before the demo, but I accidentally wired the raspberry pi off by one on pin 10 instead of pin 12 during the first day of the demo and blew out all the LEDs that I had previously connected. So this week I rewired all the LEDs onto the wooden strips back to its original state. I hope to glue everything into place so that I do not have to worry about wires popping out and to get starting on the verification of the move suggestions generated from my code.

Despite this I am on schedule and no changes need to be made. This next week I hope to test the move suggestions on the 100 different board state and piece combinations that are part of our testing plan. For my verification plan , I will generate these board states randomly with an RNG to decide the index each piece is at and which piece’s potential moves are being questioned. Then, I will have to manually check whether the suggestions are correct and if any are wrong, take note of the accuracy percentage.  I will make a spreadsheet and keep track of the board states that cause incorrect suggestions and see if I can find a pattern with the wrong ones. If the computer vision subsystem is able to out an FEN string of some sort, I will also integrate that into the generation of my moves since right now it uses command line inputs. If I can get the FEN string output from the CV, I will also have to test the latency during these 100 different boards by subtracting the timestamp of when the LEDs are turned on by when the FEN string is inputted into the LED system.

     

Posted on

Team’s Status Report for 3/28

The most significant risks that could jeopardize the success of the project is still the integration of the subsystems. We are starting to integrate the LED system with the printed out boards, but the computer vision depends on this set up and the LED system will then also depend on the chess engine. We may have to make a replica of the board out of cardboard or paper in order to get started on the computer vision part since we think there could be potential obstacles with this subsystem.

No changes were made to the existing design of the system. One slight change we made was skipping some LEDs at the end of each strip in order to allow for better U shaped bends to the next row, which means we may have to buy more LEDs and LED connectors than intended.

Posted on

Claire’s Status Report for 3/28

This week I attached the LED strips to the printed out board and altered the indexing of the LEDs to parallel how I taped the LEDs onto our wooden strips. Since I needed to use one or two extra LEDs at the ends of each strip in order for the connectors to be able to attach without touching the wood strips, I had to factor in this into the code. I then used this to check that I was lighting up the correct lights under the zones for things like the starting and ending sequence.

My progress is on schedule. Next week I hope to connect the rest of the board once the other half of the board and more wooden strips are printed. I also hope to test the move highlighting since at that point I would be able to see the LEDs light up under the entire board.

Posted on

Team’s Status Report for 3/21

The most significant risks that could jeopardize the success of the project is the integration of the subsystems. We are still at the phase of building our subsystems separately so it is hard to tell how long or difficult it will be to integrate them together. We didn’t plan for the integration to take as long as the building of the subsystems, but if we do happen to need more time for integration we will make our testing plan shorter. Instead of 10 full games and 100 different board states, we could do 5 full games and 50 different board states instead.

No changes were made to the existing design of the system. We purchased more LED strips, but this is not a change a just a consequence of our previous choices to skip every 2 LEDs. One slight improvement we made was to cut acrylic circles to put into the cut outs from the wooden board so the light from the LEDs could diffuse up to be seen at the top of board so the player does not have to be directly above the board staring down into the cutouts to see which color, if at all, is being shown. These acrylic circles will incur small TechSpark costs.

Posted on

Claire’s Status Report for 3/21

This week I successfully got the same logic that I was using an Arduino Uno 3 for to work on the Raspberry Pi 4. This includes the move suggestions and starting and ending sequences. Hopefully this makes it easier to write code that can communicate with the computer vision system and chess engine since I can write code in Python now. I also verified that the wiring of my LEDs would work under the board and that I would indeed have to use my LED connectors instead of bending the LED strips under the board with Yoyo’s printed prototype of the board. An image is attached below.

My progress is on schedule. Next week I hope to get the hardware complete. The board printing and engraving is set to be complete the start of this next week so I hope to have attached all the LEDs under the board by the end of this week. I also hope to use this new set up to verify that my move suggestions are correct since I can have an easier time seeing them light up under the grid now.