Chessbot

Control Systems Design Term Project 2022

Project Overview

The goal of this engineering project was to design and build a chess robot that could replicate an online chess game to moves on a physical board. The motivation for this project was to enable people with dexterity difficulties to play on a physical chessboard. This project demonstrated a mix of mechanical design and visualization, as well as electrical design, theory and implementation in conjunction with firmware design. This project was a team effort between myself, Sam Hudson and Scott Dunn, Mechanical Engineering graduate students emphasizing their work in the field of mechatronics.

"Chessbot" Prototype

Mechanical Design

The mechanical design of the Chessbot was conceived with three important missions in mind, move the pieces autonomously without interfering with other pieces, be able to detect the pieces before moving them to establish accuracy, and to not obstruct either player's view of the board.

With these missions in mind, our team designed an autonomous chessboard that moved the pieces with a magnet under the board via solenoid activation. The board was also designed with glass so our infrared sensor could detect whether the piece is within range of the magnet. And finally, we carried the solenoid and magnet under the board using a design called an "H-bot", which utilizes two pulley systems to enable a 2 degree of freedom translation. Our board was designed to be oversized to test the capabilities of our chessbot, and provide a good example of how well the chess pieces moved from a magnetic attraction from the other side of the board.

I took charge of the H-Bot pulley system and derived kinematics used to build drivers for both the stepper motors. The kinematics derivation included the rotational velocities of the pulleys needed to determine the direction of the solenoid, as well as the number of steps of each pulley to travel a certain distance.

Chessbot Solidworks Isometric View

Chessbot Prototype

H-Bot Diagram

Electrical Design

The PCB design was centered around the ESP32 microcontroleer board. The board was design to be capable of controlling two stepper motors, two limit switches, a linear actuator and an infrared reflective sensor. The PCB design was created using the software EAGLE.

The circuit was first tested on a bread board to confirm certain parts of the board were designed correctly. After confirming the correct design of the board, our team sent the files to JLC PCB to fabricate the PCB. Our team collaborated together to design the electrical circuits within the board. Certain factors influenced different parts of the board, for example creating a bigger contact area for parts that required a higher power input for energy dissipation. We designed the board to be portable, utilizing a 2.5mm DC jack allowing a standard 12V power supply to be used.

Instead of soldering each electrical component individually to the board, our team utilized a stencil and soldering paste to attach most of the pieces on the board. We simulated the effects of a reflow oven using a hot plate and a heat gun. This method proved far more efficient than soldering each piece individually.

Chessbot Board EAGLE CAD

Assembled Board Front

Assembled Board Back

Software Design

The complexity of the software necessitated the use of object-oriented programming principles. Dependency injection was used to enable loose coupling between each class. This allowed the team to split the programming work up without adding complexity when programs were integrated together.

I took charge of programming the tasks while Sam Hudson took charge in programming the server integration. I programmed the tasks in C++. First I programmed the objects that were dependencies, required to instantiate the task objects. These included the motor drivers and kinematics for the h-bot. Each task was made into an object, containing a run method which acted as the finite state machine for the task. In the main program, all dependent objects were instantiated (the motor drivers, kinematics, and API handler). Then, the task objects were instantiated using the dependent objects. Each task object was then defined as a FreeRTOS task with its run method and task period. By first creating a task diagram and Finite State Machines for each task, I was able to organize my pathway into translating these ideas into code. I believe this methodology increased my efficiency and execution for my task in this project.

ChessBot UI

FSM Controller Task

Task Diagram