Hacker News Reader

Comment by stormbrew | Hacker News Reader

A lot of people have pointed out that solving a cube isn't really a Hard Problem, and that the really interesting thing is the automechanic aspects of it to begin with, but honestly I think it'd actually be harder to make it track the rotations and replay them backwards than to just solve the cube from any static state.

Kinda feel like this is a pretty good example of how solutions to problems can be counterintuitive to people.

View on HN

Doesn't it need to track the rotations in order to solve it anyway though?

Why? It just needs to record the current position, regardless how it got there.

That's how I solve a partially solved cube when I pick them up -- just look at where it is and what's next, don't worry about how it got there.

It doesn't have eyes. Or, perhaps more significantly, a way to track the edge and corner cubelets from the initial "solved" position to the current configuration. Face angle isn't enough, you need the path that was taken to get there.

Gotcha, so in other words, it needs the previous spin to help decide what’s next? (It doesn’t have self-perspective)

Yes but the current position of all 6 motors is not enough to determine the state of all 26 cubes. Tracking moves with an encoder for each motor (which you want anyway to ensure you didn't overshoot on a move) sounds like the way to go.

I imagine theres some protocol to tell the controller the cube is solved (e.g. only turn it on in a solved state) and it just tracks moves from there to determine the current state.

Reply on news.ycombinator.com