# Rubik’s Solver Uses FAC Machine Building System

We love a good Rubik’s Cube solver and the mechanical engineering on this one is both elegant and functional.

This is the first time we remember hearing about the FAC system, which is a standard set of parts which can be used to make any number of mechanical systems. [Wilbert Swinkels] must be a master with the system; the layout of the machine appears simple and uncrowded despite the multiple degrees of freedom built into it. Those include an insertion platform for getting the cube in and out, a gantry for three color sensors, and two axes (three grippers in all) for doing the actual solving. If you’ve used FAC before we want to hear what you think of it in the comments.

[Maxim Tsoy] handled the software which runs on a Rapsberry Pi Compute module. You’ll want to watch the demo video below. First you place the randomized cube on the insertion platform which retracts after the cube is in the grasp of the grippers. These work in conjunction with the color sensor gantry to scan every side of the cube. After a brief pause to compute the solution the grippers go to work.

It is possible to build a solver with just two swiveling grippers. Here’s a really fast way to do it.

# Solving Rubik’s Cube With An FPGA

For their final project for ECE 5760 at Cornell, [Alex], [Sungjoon], and [Rameez] are solving Rubik’s Cubes. They’re doing it with an FPGA, with homebrew robot arms to twist and turn a rainbow cube into the correct position.

First, the mechanical portion of the build. The team are using a system of three robot arms positioned on the left, right, and back faces of the cube relative to a camera. When a cube is placed in the jaws of this robot, the NTSC camera data is fed into an FPGA, where a Nios II soft core handles the actual detection of the cube faces, the solver algorithm, and the controller to send servo commands to the robot arms.

The algorithm used for solving the cube is CFOP – solve the white cross, the white corners, the middle layer, the top face, and finally the entire cube. In practice, the robot ended up taking between 60-70 moves. This is not the most efficient algorithm; the Thistethwaite algorithm only requires 52 moves. There’s a reason for this apparent inefficiency – the Thistlethwaite algorithm requires large look-up tables.

Once the cube is scanned and the correct moves are computed, the soft core in sends commands out through the FPGA’s GPIO pins. Each cube can be solved in under three minutes after it has been scanned, but the team ran into problems with scanning accuracy. It’s a problem that can be fixed with the right lighting setup and better aberrant cubie detection, and a great final project using FPGAs.

Video demo below.

# Rubik’s Cube Solver Made Out of Popsicle Sticks and an Arduino

[Matt] recently learned both how to solve a Rubik’s cube and the basics of an Arduino. Putting the two together, he decided to try his hand at making an automatic Rubik’s Cube solver!

We’ve seen this done quite a few times using LEGO Mindstorms, but we’re much more impressed with [Matt’s] clever use of popsicle sticks and mechanical linkages…. The device uses just two servos. One to rotate the base, and the second to flip the cube over.

He’s using an Arduino UNO (R3) with 2 Hitec HS-311 hobby servos, some popsicle sticks, hot glue, a paper towel roll, and a bit of plywood. He wrote the code to solve the cube himself, and has shared it on GitHub — but he didn’t stop there and decided to create a GUI to go with it using Python.

It’s not that fast, but it’ll solve a cube in about 20 minutes — stick around after the break to see it in action!

# Cube solving robot shatters the world record

This cube-shaped bot just shattered the robotic Rubik’s Cube solving record by about 8 seconds. It did it in a blazing 10.69 seconds to best the old record of 18.2 seconds. There was immediate confusion here at Hackaday as some of us thought the record was actually around six seconds. And it is, for humans. That’s right, the human record holder completed a cube in 6.24 seconds… faster than a robot by almost four seconds. It’s surprising that we can still beat mechanized devices at some repetitive mechanical operations.

Take a look at the speed run shown in the video after the break. What strikes us is that the motions are incredibly efficient, and the bot is very quite. Compare that efficiency to CuBear, a solver that uses a different motor for each side of the cube. That one doesn’t need to grip the cube making us think it could beat this version if the firmware were quite a bit faster.