Many robotic systems can solve a Rubik's cube. Software-focused systems can solve a Rubik's cube with general-purpose robot hardware (such as the Shadow Hand illustrated above), but requires complicated control and slow solving time. Hardware-focused systems leverage specialized hardware to achieve simple control and fast solving time, but cannot be applied to other tasks. In this project, we have built a Rubik's cube solving system with a semi-general robot (Sawyer arm with parallel gripper), relatively simple control, and medium solving time (~10min for any cube).
hardware vs. control vs. planning complexity tradeoff: Solving Rubik's cube is extremely difficult without any hardware help. On the other hand, adding hardware contraptions (holders, suspension, etc.) can help simplify control (ex. only requiring a few motion primitives), but may require additional planning and reduces the generalizability of the overall system. Where should the balance lie? How to design enough hardware so that the control problem becomes solvable, without sacrificing too much generalizability?
high-precision manipulation: At each solving step, given a face that needs to be rotated, the robot has to 1) reach that desired face and 2) turn that face 90, 180, or 270 degrees. Both of these moves require high precision. How do we achieve the desired manipulation with the Sawyer arm, which is known to be imprecise?
sequential manipulation with compounding errors: Solving a Rubik's cube requires multiple solving steps, and imprecision from one step (ex. failing to turn a face completely 90 degrees) may be detrimental to the subsequent steps as a wrong face might be turned. How to make the Sawyer arms perform these moves robustly and precisely?
We believe our system (with modifications) has the potential to be used in factory assembly (ex. furniture, toys, etc.), because assembly, like solving Rubik's cube, requires sequential and precise, but defined manipulation of objects.