The Rubik's Contraption | Robot DaycareA collaboration with Jared.

Before any build log, here's a video:

That was a Rubik's cube being solved in 0.38 seconds. The time is from the moment the keypress is registered on the computer, to when the last face is flipped. It includes image capture and computation time, as well as actually moving the cube. The motion time is ~335 ms, and the remaining time image acquisition and computation. For reference, the current world record is/was 0.637 seconds.

The machine can definitely go faster, but the tuning process is really time consuming since debugging needs to be done with the high speed camera, and mistakes often break the cube or blow up FETs. Looking at the high-speed video, each 90 degree move takes ~10 ms, but the machine is actually only doing a move every ~15 ms. For the time being, Jared and I have both lost interest in playing the tuning game, but we might come back to it eventually and shave off another 100 ms or so.

Here's the contraption:

The contraption is built from:<br>6 Kollmorgen ServoDisc U9/N9-series motors. 2 were taken from my old robot arm project, the rest were found pretty cheaply on ebay. Each motor has a US Digital optical encoder on the back, also purchased for a bargain on ebay.<br>6 custom motor drivers.<br>2 PlayStation Eye cameras<br>1 Rubik's Cube. One of the cheapest available

Several cubes were broken and rebuilt in the process:

Build Log

The hardware started out with a 1-axis test setup cobbled together out of spare parts. Below is a big ServoDisc U12 and cruft encoder found lying around MITERS, the motor controller I built for 6.131 a few years ago, with everything wired into a Nucleo for control. I used this setup to implement the minimum time controller in hardware, and figure out a ballpark for how fast this thing could go.

The answer was pretty darn fast.

The plot shows a sequence of 90 and 180 degree moves. Each 90 degree move here took a little under 15 ms. And that was only at 40 volts.<br>We tested with an actual cube, using Bayley's Photron for high-speed recording. The "speed cubes" we used have pop-off caps at the center of each face. Beneath the cap is a screw you can use to adjust the amount of slop in the cube. We machined some square-drives that press into the recess beneath the cap, so no cube modification was required.

One counterintuitive trick for getting things to work well was to make the cube really tight. When the cube is loose (like it would be if a person were trying to solve it fast), the outer faces just cam outwards when you try to turn the center faces quickly - see the Cubsplosion video for what this looks like. It took tightening the cube way past what intuitively felt appropriate, in order to stop the camming action from happening.

From this point, the hardware was relatively straight forward. The big ServoDisc was swapped for six smaller ones; 2 from my old robot arm, and 4 more from ebay. The smaller ones have the advantage of having higher torque-to-inertia, so should are capable of even greater angular accelerations, and draw much less power in the process. I machined a bunch of motor-to-cube couplings, and threw together a box to hold everything out of some laser cut acrylic and scavenged 80/20.

To be specific, the motors are 4 ServoDisc N9M4T motors, and 2 UD9-E's. These two motors have identical performance, but the N-ones use neodymium magnets, so they're much thinner.

Each motor has a US Digital 2000 line optical encoder strapped on the back. While that much resolution definitely isn't necessary, we found the encoders for $14 apiece on ebay, brand new, which was an excellent deal. The encoders only had 1/4" bores through the optical discs, and none of our motors had 1/4" shafts. In fact, the N9's didn't have any shaft whatsoever protruding beyond the back of the motor. We stuck each motor in the lathe, held by the front shaft, and reamed 1/4" holes in the backs. 1/4" dowel pins were pressed into the holes, to add enough shaft to mount the encoders to. The N9's also had no features to mount the encoder sensor and housing to, so they were held on with some VHB.

I built some custom DC motor controllers to do the servo-ing:

The motor controllers aren't anything too fancy - in fact, they don't even have current sensors on them. Gate drive uses and external 12V power supply and bootstrapped gate drive optoisolators. They've each got an STM32F303K8 doing all the control. Commands are sent to each controller over a differential serial interface, and there are 2 extra GPIO pins broken out, which are used for synchronization between the 6 motors. The controller is built out of 100V FETs, so I was expecting it to run up to 60V with no issues, but we've managed to blow up one of them twice at that voltage, when the cube locked up. I'm not sure if it's a conventional FET-blew-up-from-too-much-current situation, or ringing on the bus causing the FETs to avalanche and die, or something like that. It is...