Rubik’s Robot So Fast It Looks Like A Glitch In The Matrix

From Ferraris to F-16s, some things just look fast. This Rubik’s Cube solving robot not only looks fast, it is fast: it solved a standard cube in 380 milliseconds. Blink during the video below and you’ll miss it — even on the high-speed we had trouble keeping track of the number of moves this solution took. It looked like about 20.

Beating the previous robot record of 637 milliseconds is just the icing on the cake of a very cool build undertaken by [Ben Katz]. He and his collaborator [Jared] put together a robot with a decidedly industrial look — aluminum extrusion chassis, six pancake servo motors with high-precision optical encoders, and polycarbonate panels for explosion containment which proved handy during development. The motors had to be modified to allow the encoders to be attached to the rear, and custom motor controllers were fabricated. [Jared] came up with a unique board to synchronize the six motors and prevent collisions between faces. Machine vision is provided by just two PlayStation Eye cameras; mounted at opposite corners of the enclosure, each camera can see three faces at a time. They had a little trouble distinguishing the red from the orange, which was solved with a Sharpie.

[Ben] and [Jared] think they can shave a few milliseconds here and there with tweaks, but even as it is, this is a great lesson in optimization and integration. We’ve covered Rubik’s robots before, like this two-motor slow and steady design and this six-motor build that solves a cube in less than a second.

27 thoughts on “Rubik’s Robot So Fast It Looks Like A Glitch In The Matrix

  1. I wonder… could this be scaled to a cube with more rows and columns?

    Then, instead of ‘solving’ the cube it could think of each square along the front side as being a pixel in a display.

  2. This kind of thing just destroys life. I’ve lost interest in almost every game that, when played by a computer, makes me look pathetic (which is pretty much all of them).

    1. That’s an interesting perspective, considering we made computers to…you know… do things faster/better than humans can.

      So what if a machine can do it faster? A puzzle is meant for human enjoyment.

        1. I had a solving hangover once. I learned about sudoku, resolved several, invented algorithm for solving them, implemented it as a program and then I didn’t have a problem to solve anymore, sudoku’s were now boring. That’s probably what parent poster is talking about.

  3. It looks like a significant amount of time is consumed waiting for the servos to overshoot and settle. Tweaking the PIDs might shave 5-10% off the time.

    Pretty impressive in any case

  4. This is impressive, but I’m concerned that this (and other similar solutions) are not “regulation” Rubik cubes. The 6 drive shafts are permanently attached to the cube faces which bypasses the need for finger grippers—nice, but it changes the rules.

    It’s kind of like when IBM’s Watson played on Jeopardy, except that it was fed the questioins in text form (so could bypass the burden of image or speech recognition–no small task).

    1. I had a similar thought here. Since the “grippers” never let got of the center piece of each side, does that mean it cannot solve any shuffle of a rubiks cube (such as when two or more center pieces have the same color)? Or is it a property of a rubiks cube that all center pieces always have different colors (I’m not that familiar with it)?

      And yes, it’s also the question of actually analysing the cube, coming up with a solution and then performing it. Sure, those two are already solved problems that can be executed extremely fast, but I guess it would add a few hundred ms if you would add that part.

      1. You got it the second time. The center pieces can’t move relative to each other and there is one of each colour. There are (on a 3×3 cube) 3 types of piece, center, side and corner. A corner cannot occupy a center or side, etc.

  5. My guess is that the actual solving time isn’t counted. I would expect this device takes a picture, which would probably take longer to take, save, and process than the time touted as the solve, use that picture (set of pictures) to deduce the moves needed, then once all that is done, they start the timer and it makes the moves that have been stored by the processing software. Maybe I’m wrong, but the article doesn’t give that much detail. Can we get a video from randomization through completion?

    1. I don’t think the processing of photos, and algo for the solve is anything compared to the mechanical manipulation of the cube. I don’t see it adding more than a couple of ms on a optimised setup running of a fast desktop CPU

    2. The time includes everything from the camera (150 frames per second, low latency) and computer vision that looks at the initial state, through the solve, and the motor action. So it’s even stricter than the typical human rules where you can pick up the cube and look at for thirty seconds before starting the clock.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.