Hardware / Software Project
Flagfall Bishop
A fully working robotic chessboard built by an 8-person team. My role was leading the software side and building the control logic that interpreted ambiguous physical board input, coordinated LEDs and move validation, and connected the board to the chess engine and robot movement system.
Watch Demo GitHub Repo
About the Project
Flagfall Bishop was a physical chessboard automated with robotics. When a player picked up a piece, the board detected the movement, showed colour-coded possible moves, validated the final action, and passed it to a custom chess engine running on a Raspberry Pi. The engine then sent the responding move to an Arduino-controlled CoreXY system with a magnet, which physically moved the opposing piece on the board.
The project was ambitious even by the standards of the cohort. It combined physical input, robot control, engine integration, move legality, LED feedback, and recovery from human error in one system that had to work in real space rather than in a clean simulated environment.
Why this project stands out
- Built as a fully working multidisciplinary project rather than a software-only prototype, with the final system ready for live demo.
- Led the software side of an 8-person team and acted as the main project representative in presentations and faculty communication.
- Solved a difficult state interpretation problem where each square could only report occupied / not occupied, so higher-level move intent had to be inferred in software.
- Won the Technicians' Award, chosen by the technical staff who worked most closely with the cohort's projects.
My Contribution
My main responsibility was the central software control layer for the whole system. I built the state machine that determined what was currently happening overall, whether it was the player's turn, the engine's turn, whether to activate piece detection, or when to hand off to the movement system.
I also built the logic that interpreted what the player was actually doing on the board. Because each tile only had a reed switch, the hardware could only tell whether a square was occupied. The software had to infer everything else: whether the player had picked up one of their own pieces, an enemy piece, whether a capture was happening, whether castling was underway, or whether the player had made an error and needed a recovery path.
That same logic also drove the LED guidance system, including possible-move highlighting, prompts for pick-up and placement, and more complex feedback for edge cases like castling and invalid states. Alongside the software work I also helped with assembly, wiring, soldering, and general hardware construction.
State Machine and Input Interpretation
The most interesting technical problem in the project was not chess rules in the abstract, but interpreting messy physical interaction reliably enough that the rest of the system could trust it. The board could only see occupancy changes, so the software had to turn low-level square events into higher-level game actions and maintain a coherent state even when players made unexpected moves.
System Integration
Board Input and Validation
Reed switches under each square detected whether pieces were present. The software layer interpreted those events, validated moves, and ensured the board could distinguish between normal moves, captures, castling, and invalid interactions.
LED Guidance
The board used LEDs to guide the player through available actions and recovery states. This depended directly on the move-interpretation logic, since the correct visual feedback changed based on what the system believed the player was trying to do.
Chess Engine Pipeline
Validated moves were sent to a custom engine running on a Raspberry Pi, which calculated the responding move and handed it off to the robot-control layer.
Physical Robot Movement
An Arduino-controlled CoreXY system with a magnet physically moved the responding piece across the board. The software had to coordinate cleanly with that movement system rather than treating it as an isolated subsystem.
Demo Video
The strongest evidence for this project is that it actually worked end to end as a live physical system.