Unsuccessful Attempts

We explored several alternative approaches during development. Some were feasible in principle but did not fit our constraints (hardware restrictions, compute/memory limits, robustness).

Inference attempt Euler-angle instability Kociemba constraints

Sixth-Face Color Inference

We initially explored inferring the colors of the sixth face from the color information of the other five faces to reduce user inputs. While feasible in principle (valid cubes have strict constraints), we were not able to build a robust inference procedure within our timeline. In practice, small input mistakes, ambiguous corner/edge consistency, and the need for additional validity checks made the approach unreliable, so we ultimately required explicit entry for all six faces.

Euler-Angle Orientation Estimation

We also attempted an Euler-angle approach: roll and pitch from the gravity vector (accelerometer) and yaw from the horizontal projection of the magnetometer. However, results were unstable. Yaw estimation was highly sensitive to accurate axis alignment and required proper tilt compensation. When the cube tilted, a vertical component entered the magnetometer reading and yaw could deviate significantly or jump abruptly.

We also observed a severe wrap-around artifact at the -180°/+180° boundary: when heading crossed this overlap region, computed yaw could flip by nearly 360°, making the cube appear to “spin” suddenly. Due to drift, flicker, and sudden heading changes, we switched to TRIAD (rotation matrix directly from vectors), which was more stable.

Kociemba Solver

We could not adopt a Kociemba(-Lite) solver under our constraints. Besides complexity and memory/compute overhead (pruning tables, cube-coordinate encodings), our move set was fundamentally restricted by hardware.

Because the MPU6050 and GY271 must remain rigidly mounted with consistent axis alignment, our physical setup prevented performing U and D rotations during operation. Since Kociemba’s pipeline assumes access to the full move set (including U/D) to guarantee completeness/optimality, it was not applicable. In contrast, an IDDFS solver over the remaining four faces required minimal memory and was straightforward to implement and verify, so we adopted IDDFS.