Auto-RubikAI: Modular Robotic Planning

• Auto-RubikAI is a modular autonomous planning framework that integrates a symbolic knowledge base, vision-language model, and language model to solve structured Rubik’s Cube tasks with interpretability and minimal data.
• The system employs a perception-to-reasoning-to-execution pipeline that converts RGB-D inputs into a 54-character cube state descriptor and synthesizes precise robotic control code.
• In evaluations, Auto-RubikAI achieved an overall task success rate of 79% across randomized configurations, demonstrating reliable performance in both simulation and real-world tests.

Auto-RubikAI is a modular autonomous planning framework that integrates a symbolic Knowledge Base (KB), a vision-LLM (VLM), and a LLM to solve structured manipulation tasks exemplified by Rubik’s Cube restoration. It is presented as an alternative both to predefined-script robot systems and to data-hungry end-to-end learning pipelines, emphasizing interpretable, multi-step task execution with minimal data requirements and no prior demonstrations. The reported deployment spans simulation and real-world execution on a 7-DOF robotic arm, with a stated end-to-end task success rate of 79% across randomized configurations (Fan et al., 8 Jul 2025).

1. Concept and scope

Auto-RubikAI treats Rubik’s Cube restoration as a structured embodied task in which perception, symbolic reasoning, and precise physical execution must be tightly coupled. In the system’s framing, the cube is not merely a puzzle but a proxy for manipulation problems such as wiring, calibration, inspection, and mechanical assembly, where correctness depends on ordered, logically constrained operations rather than generic pick-and-place behavior (Fan et al., 8 Jul 2025).

This choice of benchmark is consistent with robotics literature that treats Rubik’s Cube manipulation as unusually demanding because it stresses both precise manipulation and sequential manipulation at the same time. In that benchmark formulation, the $3 \times 3$ cube requires sub-centimeter end-effector positioning accuracy, while long sequences of rotations expose pose-estimate drift, regrasping difficulty, and error accumulation across time (Yang et al., 2022). Auto-RubikAI adopts the same high-level intuition, but places symbolic task reasoning at the center of the architecture rather than treating the cube only as a manipulation benchmark (Fan et al., 8 Jul 2025).

The system is explicitly motivated by three limitations in prior approaches. Traditional scripted robot systems are described as brittle under scene changes; pure LLM-based systems are described as weak at the group-theoretic and combinatorial reasoning needed for exact restoration; and data-heavy learning approaches are described as costly, difficult to reproduce, and prone to physically ungrounded actions. Auto-RubikAI answers this by assigning symbolic correctness to the KB, perceptual grounding to the VLM, and procedural code synthesis to the LLM (Fan et al., 8 Jul 2025).

2. Tri-module architecture

The architecture is organized as a perception-to-reasoning-to-execution pipeline. A human first provides a free-form instruction,

$$L = \text{“Solving Rubik’s Cube with Minimal Move”}.$$

The VLM then parses RGB-D observations and infers the scrambled cube state, which is converted into a 54-character textual descriptor $D$. The KB consumes $D$ and returns a restoration sequence

$S = (St_1, St_2, \ldots, St_i),$

where each $St_i$ is a symbolic cube move. The LLM receives $L$ and $S$, decomposes the symbolic plan into robotic subtasks, and generates structured control code that invokes mapping, localization, gripper, and rotation routines (Fan et al., 8 Jul 2025).

This division of labor is the defining property of the system. The VLM is responsible for grounded scene understanding, the KB for exact restoration logic, and the LLM for translating symbolic steps into executable procedures. The paper presents this as a closed-loop embodied system rather than a monolithic policy network. The resulting execution chain is perception $\rightarrow$ symbolic reasoning $\rightarrow$ code generation $$L = \text{“Solving Rubik’s Cube with Minimal Move”}.$$0 motion execution, followed by a final symbolic verification step through the KB (Fan et al., 8 Jul 2025).

The architecture is also described as retrieval-free. Instead of relying on demonstrations or retrieved program templates, Auto-RubikAI uses prompt chaining to progressively refine symbolic actions into lower-level instructions. A move token such as R3 is first expanded into higher-level commands such as moving the gripper to the right layer, rotating that layer, and returning to an initial pose; subsequent prompts further reduce these commands into executable calls (Fan et al., 8 Jul 2025).

3. Symbolic knowledge base and restoration formalism

The KB is the system’s symbolic core. Its function is to compute restoration steps that the authors argue current LLMs cannot reliably derive from a scrambled state. The cube state is encoded as a 54-character descriptor, with the VLM producing strings such as DLLRULLFFUBBLRFLRBUDRBFUBLDRFFRDFRBLFDFBLDDUUDDRUBUURB according to the color sequence of the central squares. From a canonical orientation in which the robot faces the red surface, the face notation is defined as $$L = \text{“Solving Rubik’s Cube with Minimal Move”}.$$1 for orange, $$L = \text{“Solving Rubik’s Cube with Minimal Move”}.$$2 for yellow, $$L = \text{“Solving Rubik’s Cube with Minimal Move”}.$$3 for red, $$L = \text{“Solving Rubik’s Cube with Minimal Move”}.$$4 for blue, $$L = \text{“Solving Rubik’s Cube with Minimal Move”}.$$5 for white, and $$L = \text{“Solving Rubik’s Cube with Minimal Move”}.$$6 for green. A move token such as B1, U2, or R3 denotes the target face and a rotation amount of $$L = \text{“Solving Rubik’s Cube with Minimal Move”}.$$7, $$L = \text{“Solving Rubik’s Cube with Minimal Move”}.$$8, or $$L = \text{“Solving Rubik’s Cube with Minimal Move”}.$$9 (Fan et al., 8 Jul 2025).

The system compares several solver families before selecting its KB strategy. CFOP is described as the standard human speedcubing method, optimized for human solving speed rather than minimum move count. Two-Phase is described as splitting restoration into a constrained first phase and a finishing permutation phase. DeepCubeA is described as a learned cost-to-go heuristic combined with A* search (Fan et al., 8 Jul 2025). In the broader literature, DeepCube solved 100% of randomly scrambled cubes while achieving a median solve length of 30 moves without human assistance (McAleer et al., 2018). Auto-RubikAI instead adopts a modified Two-Phase method as its KB, arguing that this variant required fewer steps than CFOP and DeepCubeA in the reported comparisons (Fan et al., 8 Jul 2025).

The reported move-count reductions are central to that claim. On 30 randomly shuffled cubes, the average-step reduction of the Knowledge Base method relative to CFOP, DeepCubeA, and Two-Phase was 78.3%, 35.7%, and 14.3%, respectively. On five human speedcubing record scrambles, the average-step reductions relative to CFOP, human record, and Two-Phase were 79.8%, 58.7%, and 13.6%, and the paper states that the selected KB method solved those cases in below 20 steps (Fan et al., 8 Jul 2025).

A direct implication of this design is that Auto-RubikAI does not ask the LLM to solve the cube. The KB provides the exact restoration sequence, while the LLM is restricted to translating that sequence into robot-executable structure. This separation is the system’s main answer to the symbolic unreliability of generic LLMs (Fan et al., 8 Jul 2025).

4. Perception, prompt chaining, and motion generation

The perception module uses RGB and depth images from Intel RealSense D435i cameras. To balance speed and accuracy, the system combines OWL-ViT for open-vocabulary object detection with Segment Anything Model for segmentation. The segmented cube is then used to identify center colors and positions, verify orientation-color consistency, and construct the 54-character symbolic descriptor sent to the KB (Fan et al., 8 Jul 2025).

Beyond cube-state parsing, the VLM builds a semantic 3D map

$D$0

from which four map types are constructed: an interaction map, an ignore map, a rotation map, and a gripper control map. The interaction map is processed with a Euclidean distance transform, while the ignore map is processed with a Gaussian filter. These maps support grounded resolution of instructions such as targeting a specific cube layer, retrieving valid gripper orientations, and generating physically feasible motion sequences (Fan et al., 8 Jul 2025).

The motion generation stage is formulated as a constrained optimization problem over waypoints $D$1 for each subtask $D$2:

$D$3

subject to joint, velocity, and acceleration bounds on the 7-DOF arm. The completion term is

$D$4

and the path-length term is

$D$5

The planner then performs greedy shortest-distance search on the interaction and ignore maps, while rotational constraints are handled through a rotation graph and gripper-state constraints through a gripper control graph (Fan et al., 8 Jul 2025).

Prompt chaining is the mechanism that connects symbolic actions to this geometric layer. For a symbolic instruction such as R3, the LLM first emits a higher-level sequence—move to the right layer, rotate that layer, return to the initial pose—and subsequent code_generator calls recursively reduce these commands into executable functions. The paper states that after three parsing cycles, R3 becomes executable robot control code (Fan et al., 8 Jul 2025).

5. Robotic deployment and evaluation

The real-world platform consists of a Franka Emika Panda 7-DOF robotic arm, a Franka Hand gripper, Intel RealSense D435i RGB-D cameras, and a workstation with an Nvidia 1080 GPU. Simulation experiments are conducted in CoppeliaSim. The manipulated object is a standard $D$6 Rubik’s Cube with side length 5.6 cm. The paper states that the same modular architecture was transferred from simulation to the real robot without retraining (Fan et al., 8 Jul 2025).

The main embodied evaluation reports 200 trials. The paper’s evaluation text first mentions groups with 5, 10, 20, and 40 random scrambles, whereas the main results table uses 10, 20, 30, and 40 random scrambles; the reported table values are for the latter four groups, each repeated 50 times (Fan et al., 8 Jul 2025). Across those trials, the average KB solving success was 90%, the average LLM code parsing success was 92.76%, and the average overall task success was 79%. The overall task success rates by scramble group were 78% for 10 random scrambles, 74% for 20 random scrambles, 84% for 30 random scrambles, and 80% for 40 random scrambles (Fan et al., 8 Jul 2025).

The error analysis reports 42 failures out of 200 trials. Using

$D$7

with $D$8, the failure proportions were 47.62% for KB-related errors, 30.95% for LLM-related errors, and 21.43% for execution errors. KB failures were attributed to color recognition errors and solution timeout errors; LLM failures to annotation errors and code generation errors; and execution failures to wrong target localization, wrong action, and wrong gripper state or initial state issues (Fan et al., 8 Jul 2025).

The same paper also reports solver-level progress statistics. In all four scramble groups, the selected KB method completed restoration within 20 steps, with the reported distributions concentrated in the 6–20 step range depending on scramble count. This is consistent with the paper’s claim that the KB method reduces average solution steps relative to CFOP, DeepCubeA, and standard Two-Phase while preserving interpretability and safety (Fan et al., 8 Jul 2025).

6. Position within Rubik’s Cube AI and outstanding issues

Auto-RubikAI sits at the intersection of several Rubik’s Cube research traditions. Learned solvers such as DeepCube focused on symbolic cube solving without human knowledge and achieved 100% solve rates on randomly scrambled cubes with a median solve length of 30 moves (McAleer et al., 2018). Transformer-based work such as CubeTR reformulated the puzzle as sequence modeling and argued that attending to longer action sequences helps with sparse rewards (Chasmai, 2021). Vision-language systems such as CubeRobot addressed multimodal planning and reported 100% accuracy on low-level tasks, 100% on medium-level tasks, and 80% on high-level tasks across 43 subtasks, but were also noted to lack a rigorous symbolic cube-state model (Wang et al., 25 Mar 2025). Robotic systems have treated the cube as a dexterous manipulation challenge as well: one line of work used automatic domain randomization and a standard symbolic solver to execute cube subgoals with a humanoid hand (OpenAI et al., 2019), while another formalized cube manipulation as a general benchmark for precise and sequential robot manipulation (Yang et al., 2022).

Against that background, Auto-RubikAI is distinctive in making the KB—not reinforcement learning or unconstrained LLM reasoning—the source of symbolic correctness. A plausible implication is that the system is best understood not as an end-to-end policy, but as a modular stack in which each component is deliberately restricted to the subproblem it handles best: symbolic restoration, grounded perception, or program synthesis (Fan et al., 8 Jul 2025).

The limitations are correspondingly clear. The benchmark remains narrow, task-specific symbolic engineering is required, and the overall success rate remains below full reliability. The paper explicitly attributes failures to perception, code generation, and execution errors, and it does not provide a full formal specification of the modified Two-Phase KB, detailed camera-to-robot calibration mathematics, or a dedicated certified safety verifier (Fan et al., 8 Jul 2025). A plausible implication is that extension beyond Rubik’s Cube will depend on whether similarly compact symbolic modules can be constructed for other structured manipulation domains.

In that sense, Auto-RubikAI is less a universal Rubik’s Cube solver than a reference architecture for structured embodied intelligence: symbolic where combinatorial correctness is indispensable, neural where perception and interface generation are advantageous, and physically grounded through constrained robot execution (Fan et al., 8 Jul 2025).