Dual-Arm Robotic Rubik's Cube Solver

System

Planning runs on a host computer; the rig only executes clamp, release and rotate commands.

The mechanism

With the grippers fixed to the frame, only two of the six layers are within reach at any time. The controller keeps a 3×3 integer matrix from the machine frame to the cube's own frame and updates it after every roll. For each requested move it searches breadth-first over sequences of single-gripper rolls for the shortest one that brings the target layer into a gripper's slot, picking whichever arm needs fewer rolls. Half turns run as two quarter turns, because the wrist only travels ±90°.

1. ParseRead the next Singmaster token, e.g. R'.
2. MapConvert it to an axis, a layer and a direction in the cube's frame.
3. Choose an armThe one whose slot needs fewer rolls to reach that layer.
4. Roll if neededOne gripper holds and turns; the other opens, then re-clamps.
5. Turn the layerBoth grippers hold; the active wrist turns 90°.
6. ResetRelease the active gripper, return its wrist to neutral, clamp both again.

Primitive packets

The interface between the planner and the rig is deliberately small: an ordered list of four kinds of command. The simulation never streams poses or trajectories; whatever the controller decides is written down as these packets, and the same list drives the real motors.

On the wire, the host sends each packet as one line of JSON carrying both grippers' target state, and blocks until the Arduino answers DONE:

{"L":{"state":1,"angle":1.5708,"action":"ROTATE"},
 "R":{"state":0,"angle":0.0,"action":"HOLD"},
 "t_ms":400}                       // → "DONE"

Two additions came from running the real rig. Stepper clamps slowly lose grip under load, so after each return to a dual hold the bridge sends a short RECLAMP that presses both jaws inward again. And after a release leaves the cube in one gripper, it waits 300 ms while the holding side keeps creeping inward before the next rotation starts.

Reading the cube

The camera's auto-exposure and auto-white-balance are switched off at start-up, so colours don't shift when the white arms move through the frame. The scan rolls the cube through five poses, each showing two faces; the ten face views are sorted by position into rows and columns and fused into the 6×3×3 state the solver needs.

Simulation

The model is built from the team's CAD assembly. The arms are reduced to the same four motors the real rig has: a wrist and a clamp on each side.

This is a recording of the MuJoCo model running the robot's controller, played back in your browser with the real CAD meshes. The packet list on the right is exactly what would be sent to the Arduino at that moment. Drag to orbit; hold ctrl or ⌘ and scroll to zoom.

Playback runs at 60 controller steps per second at 1×; it shows the order and geometry of motions, not the real rig's timing. Each "Scan and solve" recording starts from a random 20-move scramble, runs the same five-pose scan as the robot, reads the state, and solves it.

Rendered in MuJoCo

Results in simulation

1000 random 20-move scrambles, each scanned, solved and executed by the controller.

Real robot

Recorded on the integrated rig. The controller and packet stream are the same ones shown above.

Team

BibTeX

@misc{huang2026cubesolver,
  title  = {Dual-Arm Robotic Rubik's Cube Solver},
  author = {Huang, Qixuan and Xu, Yiming and Wang, Rong and Shen, Zhuoyang},
  year   = {2026},
  note   = {ECE 445 Senior Design Project, University of Illinois Urbana-Champaign}
}