Smart3: The Self-Solving Rubik’s Cube

My cube, when scrambled and placed on a desk, starts turning its faces to solve itself. It recognizes its color arrangement and solves from its current state, rather than reversing scrambled movements. It works independently without the need for an external computer or cameras, and can solve itself in about 30 seconds, no matter how scrambled.

Many people have never disassembled a Rubik’s Cube, so I’ll explain its structure.

First, there are 6 shafts. The rotatable center pieces are attached to the end of them (Figure A), and there are edge pieces and corner pieces around the center pieces (Figure B). When you turn the faces by hand, the edge pieces and corner pieces move and the colors scramble. The pieces don’t come off because they’re hooked on each other.

The Self-Solving Rubikʼs Cube turns the face by turning the shaft with a motor (Figure C). I put 6 sets of gears, motors, motor drivers, and rotary position sensors — along with a single board microcontroller, a battery, and an accelerometer — inside the Rubikʼs Cube (Figures D and E).

The accelerometer recognizes when the Self-Solving Rubik’s Cube is placed on the desk. When the microcontroller commands the motor driver, the motor connected to it rotates, turning the gears, and, in turn, the face.

The microcontroller can recognize the rotation angle of the shaft with the rotary position sensor, and will command the motor driver to stop the motor when the shaft reaches the target angle.

The rotary position sensor I selected is magnetic. It recognizes the rotation angle of a diametrically magnetized neodymium cylinder magnet attached to the end of the shaft
(Figure F).

Generally, a machine that solves Rubikʼs Cube with robot arms uses cameras or color sensors. I came up with the idea of using rotary position sensors. I programmed the microcontroller so that the rotary position sensor would detect when the face was turned by hands and the color arrangement data in the memory would change.

The Self-Solving Rubikʼs Cube does this all the time, so the color arrangement data in memory always matches the actual color arrangement.

The idea of using rotary position sensors was good because there was no need to add new sensors — but it has the limitation that the colors must be aligned before the Self-Solving Rubik’s Cube is powered on.

There are many different methods for solving Rubikʼs Cube. For my project, I went with CFOP (Cross – F2L – OLL – PLL), one of most commonly used methods in speed-solving a Rubikʼs Cube.

A computer, using a brute force solution, can solve a Rubikʼs Cube with about 20 moves. The more human-oriented CFOP program I made takes an average of 52 moves. It’s longer, but better oriented for the microcontroller inside, and probably more entertaining for Rubikʼs Cube fans.

My CFOP program calculates all the moves needed to solve the cube when it is placed on the desk. This takes about 3 seconds.

The single board microcontroller I selected is the RedBear BLE Nano V2 (end of production). I didn’t need BLE, but I selected it because it’s small, and its 512KB of flash memory was adequate for the CFOP program. I used the Mbed Online Compiler for programming it (Figure G).

It’s worth noting that I couldn’t solve Rubik’s Cube before starting this project, and had to learn how to do so before programming. Turns out, it’s pretty fun.

The first thing I did was to measure the parts of a commercial Rubik’s Cube with a caliper and create 3D data of it. Then I made prototypes from that on a 3D printer. The size of Rubik’s Cube is 57mm (2.24″), and the internal space is small; therefore, the prototypes were very big
(Figures H and I).

Problem: They couldn’t roll on the table, as they need to when solving themselves. This was because the power of the motor wasn’t strong enough.

Finally, I redesigned the 57mm (2.24″) Rubik’s Cube with a larger internal space (Figure J). And I repeated parts selection and design changes to make an internal mechanism that fits in that space. The biggest parts were the servomotors (Figure K).

I decided to disassemble the servos to access the gears and motors and use just them. I spent a lot of time considering their arrangement (Figure L). Then I made a 13-piece gearbox and put the servo gears and motors in it (Figure M).

I put other electronic parts in the remaining space (Figures N and O).

The cube’s electronic circuit has a lot of room for improvement. For example, the battery may be damaged because this circuit does not limit the current of the motor driver. I wouldn’t advise using it for reference, but wanted to share the version that first solved itself in 2018 nonetheless (Figure P).

This was the most difficult part of this project. The six faces of Rubik’s Cube are made up of 26 separate pieces. Because each face shares pieces with its neighbor, a face that is misaligned prevents the other faces from turning — ideally the face would turn exactly 90 degrees each time. However, because the faces are made up of separate pieces, even if the shaft turns exactly 90 degrees, the faces will slip a little each time. Therefore, the face must be able to turn even if the other faces are slipping a little.

Two things are needed to solve this. One is a gap between the pieces. The other is to add springs into the centerpiece. These springs pull all the pieces to the center of Rubik’s Cube (Figure Q). This will leave a gap between the pieces only when the face is stuck, while keeping the face from sticking in normal use. It’s the same mechanism used on a commercial Rubik’s Cube.

I first printed all 26 pieces with a 3D printer to a slightly larger size (Figure R). I filed them little by little over a month with precision needle files and sandpapers. During that time, I found the proper width of the gap and proper strength of the spring by repeatedly assembling them (Figure S).

I then polished the parts well with compounds to reduce surface friction and allow them to slip like molded products (Figure T). I also applied silicone oil to the surface.

When I started this project I had no experience with 3D printers or 3D CAD, and had little experience with electronics. Immediately after I left my job, I moved to the neighborhood of the makerspace DMM.make AKIBA in Akihabara, Tokyo (Figure U), where I learned everything by spending almost every day working on the Self-Solving Rubik’s Cube. This makerspace is open 24 hours a day and there are many stores selling electronic parts in the neighborhood.

Learning 3D CAD (I used Rhino 5.0) allowed me to examine all the parts’ arrangements over and over again on the computer, so I was able to pack them into the cube (Figure V). I modified and printed the gearbox and pieces multiple times a day on an Afinia H480 3D printer (Figure W).

In this way, I was able to repeat trial and error in a short period of time, so I was able to create hardware that would work without any mechanical design experience. Thanks to these two tools and the makerspace, I was able to complete the Self-Solving Rubik’s Cube.

The year after I completed the Self-Solving Rubik’s Cube, I debuted a new feature: the ability to solve itself while floating in midair (Figure X).

I have not disclosed the mechanism for this — as I said, I like to surprise people. Have fun imagining how it works!

Follow Takashi Kaburagi on YouTube to see his Self-Solving Rubik’s Cube in action, and all of his other projects.