Building an Automated Chessboard (Attempt #1 – Failed, but Worth It)

In some of my previous posts, I mentioned that I’m a big chess enthusiast. Naturally, it was only a matter of time before I tried to automate the game.

Of course, I’m far from the first person to attempt this. There are quite a few automated chessboard projects on YouTube. However, only a small fraction of them appear to be truly functional and reliable.

As a starting point, I used this excellent guide from Instructables:
https://www.instructables.com/Automated-Chessboard/
The author (Greg06) does a great job explaining both the challenges and the solutions in detail. The project includes a full list of materials and clear assembly instructions.

My second source of inspiration was:
https://oshwlab.com/skolodi/works
This project builds on the same foundation but goes deeper into areas that weren’t fully covered in the original. I actually discovered it through the comments section.

In this post, I’ll focus on what didn’t work well in my first attempt and what I would redesign.

Where Things Started to Break

The biggest challenge by far is the hardware. The software part will actually be the fun part later.

A critical realization: even a 1 mm deviation in the base structure can cascade into major inaccuracies later, ultimately making the entire system unusable. What looks like a negligible misalignment at the beginning can easily turn into pieces not aligning with squares, magnets missing their targets, or the whole movement system jamming.

During the build of version one, I noticed these small inaccuracies—but I didn’t give them enough attention. At the time, everything “almost worked,” which made it easy to ignore the problem and continue. Only near the end did it become obvious that all those small issues had accumulated into one large, unusable result.

At that point, I seriously considered abandoning the project. Instead, I decided to completely disassemble it and start again, this time focusing on eliminating each source of inaccuracy step by step.

Key Lessons Learned

1) Build on a solid base

The entire construction should be mounted on a rigid and stable base plate. In my first attempt, the structure had small degrees of freedom that I initially overlooked. Under load or during movement, these tiny flexes translated into positioning errors.

Another important point is accessibility. During development, you will constantly need to inspect, adjust, and fix things. If you close everything inside a box too early, even a small tweak becomes unnecessarily complicated.

In hindsight, building the final enclosure at an early stage was a mistake. It added complexity without providing any real benefit. A much better approach is to keep the system open and only design the enclosure once the mechanics are fully validated.

To improve rigidity, I used standard connectors for 20×20 aluminum profiles, which made the frame significantly more stable.

2) Adjustable height is essential

The top layer, which holds the chessboard surface and sensors, is supported by vertical spacers or legs. Initially, I used fixed-height supports, assuming I could calculate the correct spacing in advance.

That assumption turned out to be wrong.

The exact height depends on multiple factors: sensor placement, magnet strength, tolerances in materials, and even small variations in assembly. Without having the full system tested, it’s nearly impossible to determine the ideal spacing.

Because of that, the lack of adjustability became a major limitation. Even a difference of 1–2 mm can determine whether the system works reliably or not.

For the next iteration, I would definitely use adjustable standoffs or a mechanism that allows fine-tuning of the height during testing.

3) Solve pieces and magnetics early

One of the most underestimated aspects is the relationship between the chess pieces, their magnetic properties, and the actuation system underneath.

The size of the pieces, the type of magnets (or metal inserts), and the strength of the electromagnet all directly influence the design of the entire board. This includes the spacing between squares and the required precision of movement.

In my first attempt, I treated this as a secondary problem and focused on the structure first. That was a mistake.

A much better approach is to start with a simple testing platform—a thin board with adjustable legs—where you manually move pieces using a magnet underneath. This allows you to experiment and answer critical questions early:

• How strong does the magnet need to be?

• How close can pieces get before they start interfering with each other?

• How precise does the positioning need to be?

This phase also reveals practical constraints, such as what materials you can realistically source. In my case, I managed to obtain two 1 mm thick steel tubes to use as inserts in the piece bases, which influenced the final design.

Understanding these constraints early would have saved a lot of rework later.

4) Use a transparent top layer

During testing, visibility is extremely important. If you cannot see what’s happening underneath the board, diagnosing issues becomes guesswork.

In my build, a non-transparent top layer made it difficult to understand why certain movements failed. Was the magnet slightly off? Was the carriage misaligned? Was something colliding?

A transparent or at least semi-transparent top board makes debugging significantly easier. You can directly observe the interaction between the moving mechanism and the pieces, which speeds up iteration and reduces frustration.

5) Rail mounting must be precise

The movement system relies on rails and wheeled carriages. In the original design, the rails were supported only from the outer side, with wheels guiding movement from one direction.

While this approach helps reduce the overall size, it introduces instability. The carriage can tilt or shift slightly, especially under load or when changing direction.

I initially tried to compensate for this through calibration, but the mechanical instability was simply too large. No amount of software correction could fix it reliably.

The only viable solution was to switch to a design where the carriage is constrained from both sides of the rail. This significantly improves stability and positioning accuracy, even though it makes the construction slightly more complex.

6) Reed switches are not sufficient

For detecting piece positions, I experimented with reed switch sensors. While they are simple and easy to use, they turned out to be inadequate for this application.

First, they are very sensitive to exact positioning. Small offsets can result in inconsistent detection, which is problematic in a system that already struggles with mechanical tolerances.

Second, they only provide a binary signal (on/off). This creates ambiguity in real gameplay scenarios. For example, when a piece is captured, the system cannot reliably determine which piece was removed—only that a square changed state.

For a robust solution, a more advanced sensing method is needed, one that can uniquely identify pieces or at least provide more reliable positional data.

Final Thoughts

Even though the first attempt failed, it was far from wasted effort. In fact, it provided a much clearer understanding of the real challenges involved in building an automated chessboard.

Many of the problems only become obvious when you physically build and test the system. No amount of planning can fully replace that experience.

Huge thanks to both authors for their detailed work—this post is not meant as criticism, but rather as a reflection on the challenges and lessons learned along the way.

The next step is clear: version two, built on much stronger foundations and with a much better understanding of what actually matters.