Project

# Title Team Members TA Documents Sponsor
51 Networked Physical Chessboard for Remote Play
Danny Guller
Payton Schutte
Quinn Athas
Wenjing Song design_document1.pdf
design_document2.pdf
other1.pdf
# Networked Physical Chessboard for Remote Play

Team Members:
- Danny Guller
- Quinn Athas
- Payton Schutte

# Problem

Online chess makes it easy for intermediate players to find games quickly, but it removes much of what makes chess feel engaging in the first place. Playing on a screen lacks the tactile feedback of moving real pieces, the spatial awareness of a full board, and the sense of presence that comes from sitting in front of a real board. While traditional in-person chess restores these elements, it usually requires both players to be in the same physical location, which limits who you can play and how often.
Some existing commercial systems attempt to bridge this gap by combining physical boards with online connectivity, but these solutions are often extremely expensive and inaccessible to most players. As a result, there is currently no widely available, cost-effective way to enjoy a truly physical game of chess with a remote opponent. Players are therefore forced to choose between convenience and the authentic physical experience of the game, motivating the need for a more affordable and accessible solution.


# Solution

Our solution is a pair of internet-connected physical chessboards that allow two players in different locations to play a real game of chess using physical pieces. Each board tracks the state of the game locally and synchronizes moves with the remote board in real time. By combining physical interaction with networked communication, the system preserves the tactile and spatial experience of chess while removing the requirement for both players to be in the same place.
Each board uses Hall effect sensors embedded beneath every square to detect the presence and movement of magnetized chess pieces. When a player moves a piece, the system detects changes in the board state and infers the intended move by comparing the previous and current configurations. To avoid ambiguity caused by partial lifts, piece adjustments, or accidental touches, players must confirm their move using a button on a digital display before it is transmitted.
Once a move is confirmed, it is sent over the internet to the opponent’s board. LEDs on the receiving board highlight the source and destination squares, guiding the opponent to physically replicate the move. The use of Hall effect sensors also enables future expansion, such as differentiating piece types using different magnet strengths or polarities, without requiring major hardware redesign.

# Solution Components

## Subsystem 1: Piece Detection (Hall Sensors + ADC Row Readout)

To detect pieces on all 64 squares without exhausting the microcontroller’s GPIO resources, the board uses one analog Hall effect sensor per square combined with an ADC-based row readout architecture. Eight 8-channel ADCs are used, with each ADC responsible for one row of the chessboard. Each ADC samples the eight Hall sensors in its row and reports the digitized values to the microcontroller over a shared communication line (I2C or SPI).
This design limits the number of devices on the communication bus to eight while still allowing the system to poll all squares frequently enough for responsive move detection. The microcontroller continuously polls the ADCs, reconstructing a full 8×8 chess board where pieces correlate to high magnetic fields.
A key challenge in this subsystem is avoiding false positives caused by magnetic fringe fields affecting neighboring squares. Because magnetic field strength decreases rapidly with distance, cross-square interference can be mitigated by careful square spacing and threshold selection. The system will also perform a calibration step to record baseline sensor values for each square and detect pieces based on deviations from that baseline rather than using a single global threshold. This approach improves robustness to sensor variation and environmental changes.


## Subsystem 2: Move Inference, Legality Checking, and Piece Identification

The system infers piece identity primarily through game state tracking rather than direct sensing. Starting from a standard chess setup, the controller maintains an internal board representation and updates it after each confirmed move. As long as pieces are not intentionally swapped, this approach allows the system to correctly track piece types over the course of the game. Even if physical pieces are swapped, the board will only let legal moves of the original piece be played.
During a player’s turn, the controller monitors changes in square occupancy and generates a proposed move hypothesis, including captures. Before the move can be confirmed, the system checks whether it is legal under standard chess rules given the current board state. If the move is illegal, confirmation is blocked and the player is notified via visual feedback, prompting them to correct the placement.
As an optional advanced feature, we may directly identify piece types using magnets with distinct strengths or polarity patterns. In this case, the analog Hall sensor readings could be used to classify the piece type directly rather than relying entirely on historical tracking. This would improve robustness against cheating and recovery from incorrect piece placement. The main challenge is ensuring sufficient separation between magnet signal ranges so that piece classes remain distinguishable across all squares and across different boards. If time permits, this feature will be implemented with careful calibration and validation.


## Subsystem 3: Networking and Synchronization

This subsystem enables two ESP32-based chessboards to communicate over the internet using a centrally hosted server. Each board connects to the server over Wi-Fi and joins a shared game session, with the server responsible for storing and relaying moves between the two players.
Communication is handled using HTTPS and a simple REST-style API. When a player confirms a move, the ESP32 sends the move to the server via an HTTP POST request. The opponent’s board periodically polls the server using HTTP GET requests to retrieve any new moves that have occurred since the last update.
Each board tracks the most recent move number it has processed. If a board temporarily disconnects, it can reconnect and request any missed moves, allowing the game to resume without resetting or manual intervention. The server enforces move ordering and prevents duplicate updates, ensuring that both boards remain synchronized throughout the game.


## Subsystem 4: Local User Interface (Display + Controls)

The local user interface allows players to set up and control the system without needing a separate phone or computer. It provides functionality for entering or selecting a game session code, confirming Wi-Fi and server connectivity, indicating whose turn it is, and displaying basic status or error messages such as “waiting for opponent,” “illegal move,” or “connection lost.”
The UI also supports the move confirmation workflow by clearly indicating when a move is ready to be sent and when it has been successfully transmitted and received.
Our preferred implementation is a small touchscreen display connected to the ESP32, which allows intuitive menu navigation and direct session code entry. As a simpler and lower-cost alternative, we may use a small OLED display with several physical buttons for menu navigation and code entry. In both cases, the interface is intentionally minimal: a player should be able to power on the board, connect to Wi-Fi, join a game, and begin playing with minimal setup. The final choice will depend on integration complexity, responsiveness on the ESP32, and available development time.


## Subsystem 5: Game Play Loop

The game play loop is intentionally simple to simulate in-person chess as close as possible. At the start of the game, the board is set up in the standard configuration. White will be prompted on the screen to make their first move after all pieces are set on each board. White will move their piece, if the move is legal, the display will prompt white to submit their move, locking their board state. Black’s display will prompt that white has made a move and LEDs under the moved piece’s square will light up indicating which piece to move and where. Black can not submit a move until their board matches that of the white player. After black replicates white’s move, black plays their move and is prompted to submit. Each move is checked for legality before a submit prompt is revealed. Board state is checked as well to ensure both players' boards are identical. If there are discrepancies in board state on either side, the display will prompt which pieces are out of place and where they should be. Once a winner is determined, the game ends and the display shows who won.


# Criterion For Success

The project will be considered successful if two physical chessboards located in different places can reliably play a complete game of chess while connected only through the internet. Each board must accurately detect player moves using the Hall effect sensor grid, require explicit move confirmation, and prevent illegal moves from being transmitted.
Confirmed moves must be transmitted to the server and received by the opponent’s board in the correct order, with the source and destination squares clearly indicated using LEDs. The system must maintain synchronization between boards even in the presence of temporary network interruptions, allowing a board to reconnect and recover the current game state without manual reset.
Finally, the system must support the completion of a full legal chess game of at least 30 moves without desynchronization, missed moves, or unintended move confirmations, while providing clear user feedback throughout gameplay.

# Components:

- Hall effect sensor: DRV5055A4QDBZR 12.5 mV/mT, ±169-mT Range
- MCU: ESP-32 (includes Wi-Fi antenna and capability)
- ADC: TLA2528IRTER 12-bit, 8-channel, I2C
- Display: DSI Touch Screen LCD Display 800x480

Habit-Forming Toothbrush Stand

John Kim, Quinn Palanca, Rahul Vasanth

Habit-Forming Toothbrush Stand

Featured Project

I spoke with a TA that approved this idea during office hours today, and they said I should submit it as a project proposal.

# Habit-Forming Toothbrush Stand

Team Members:

- Rahul Vasanth (rvasant2)

- Quinn Andrew Palanca (qpalanc2)

- John Jung-Yoon Kim (johnjk5)

# Problem

There are few habits as impactful as good dental hygiene. Brushing teeth in the morning and night can significantly improve health outcomes. Many struggle with forming and maintaining this habit. Parents might have a difficult time getting children to brush in the morning and before sleep while homeless shelter staff, rehab facility staff, and really, anyone looking to develop and track this habit may want a non-intrusive, privacy-preserving method to develop and maintain the practice of brushing their teeth in the morning. Keeping track of this information and but not storing it permanently through a mobile application is something that does not exist on the market. A small nudge is needed to keep kids, teenagers, and adults of all ages aware and mindful about their brushing habits. Additionally, many tend to zone out while brushing their teeth because they are half asleep and have no idea how long they are brushing.

# Solution

Our solution is catered toward electric toothbrushes. Unlike specific toothbrush brands that come with mobile applications, our solution applies to all electric toothbrushes, preserves privacy, and reduces screen time. We will implement a habit-forming toothbrush stand with a microcontroller, sensors, and a simple LED display that houses the electric toothbrush. A band of sensors will be wrapped around the base of the toothbrush. Lifting the toothbrush from the stand, turning it on, and starting to brush displays a timer that counts seconds up to ten minutes. This solves the problem of brushing too quickly or losing track of time and brushing for too long. Additionally, the display will provide a scorecard for brushing, with 14 values coming from (morning, night) x (6daysago, 5daysago, . . . , today) for a "record" of one week and 14 possible instances of brushing. This will augment the user's awareness of any new trends, and potentially help parents, their children, and other use cases outlined above. We specifically store just one week of data as the goal is habit formation and not permanent storage of potentially sensitive health information in the cloud.

# Solution Components

## Subsystem 1 - Sensor Band

The sensor band will contain a Bluetooth/Wireless Accelerometer and Gyroscope, or Accelerometer, IR sensor (to determine height lifted above sink), Bluetooth/Wireless connection to the microcontroller. This will allow us to determine if the electric toothbrush has been turned on. We will experiment with the overall angle, but knowing whether the toothbrush is parallel to the ground, or is lifted at a certain height above the sink will provide additional validation. These outputs need to be communicated wirelessly to the habit-forming toothbrush stand.

Possibilities: https://www.amazon.com/Accelerometer-Acceleration-Gyroscope-Electronic-Magnetometer/dp/B07GBRTB5K/ref=sr_1_12?keywords=wireless+accelerometer&qid=1643675559&sr=8-12 and individual sensors which we are exploring on Digikey and PCB Piezotronics as well.

## Subsystem 2 - Toothbrush Base/Stand and Display

The toothbrush stand will have a pressure sensor to determine when the toothbrush is lifted from the stand (alternatively, we may also add on an IR sensor), a microcontroller with Bluetooth capability, and a control unit to process sensor outputs as well as an LED display which will be set based on the current state. Additionally, the stand will need an internal clock to distinguish between morning and evening and mark states accordingly. The majority of sensors are powered by 3.3V - 5V. If we use a battery, we may include an additional button to power on the display (or just have it turn on when the pressure sensor / IR sensor output confirms the toothbrush has been lifted, or have the device plug into an outlet.

# Criterion For Success

1. When the user lifts the toothbrush from the stan and it begins to vibrate (signaling the toothbrush is on), the brushing timer begins and is displayed.

2. After at least two minutes have passed and the toothbrush is set back on the stand, the display correctly marks the current day and period (morning or evening).

3. Track record over current and previous days and the overall weekly record is accurately maintained. At the start of a new day, the record is shifted appropriately.

Project Videos