Looks like it's solving to me. It's taking longer to solve and there's a screenshot of some solving code in the description.

I notice also that it appears to not be able to move the middles sections, so instead it twists the middle and one side and then twists the side back again - so that adds an extra inefficiency.

EDIT if you look at the first video, the first move the solver makes is not the inverse of the last one the player made, so I'm sure it has its own solver. Also, there are pretty standard solver algorithms (I've never looked them up because I don't want to spoil the game for myself but I have a really inefficient one I've figured out myself).

I'm pretty sure it's using some version of Fridrich. It looks like it in the video, and the source code screenshot has a file name, "solve_f2l.cpp", that would appear to be referring to the "first two layers" step, which is usually abbreviated as f2l.

For finding a solution by computer, it has the advantage of being almost completely a rote application of algorithms.

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.

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.

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.

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)

You can see its not just playing back the reverse order:

- first human shuffle move was rotate around white side

- last cube movement was rotation around green side

Ergo the cube did not just follow the same steps in reverse order

That does not really matter I think. The cool part is that they very able to build a cube that looks similar like Rubik's but has electronics and motors embedded that are able to turn it.

Solving the cube with a computer is a solved problem for a long time and there are myriads of algorithms. Granted the solutions are not perfect (i.e. using the minimum number of steps needed which is always <= 20), but mostly come close (~25 steps).

I think it has psychological significance.

It's one thing to have an object that violates expectations by taking action that an outwardly similar object does not. It's a surprise move that turns the tables on the person interacting with the object. (You could almost view it as a threat or a power dynamic thing.)

Having those actions be as intelligent as possible raises this surprise to another level. If I fiddled with it for 5 minutes and it put it back in 30 seconds, I'd feel even more like I just got owned by the object.

note too a replay solution could have infinite steps to have to reproduce, assuming its not optimized to take any shortcuts to jump to a re-occurring state.

I don't think one is much harder than the other (since solver algorithms already are a solved problem), the hardware seems more impressive to me than whether you put software on it that tracks and reverses movement or has a solver algorithm in it.

From the video it looks like a solver algorithm by the way, and not going for least amount of movements either, it seems to move much more during the solve than the movements the person did. To save battery they should go for optimal amount of moves!

A Rubiks cube solving algorithm seems like a trivial part of the problem if you can run code on it and give commands to make various turns already.

It's solving itself.

The C++ snippet includes permutations for the Fridrich method's first two layers (F2L), which wouldn't be required for a reverse-replay.

It does need to know it's starting configuration though ! So it starts from a solved cube and needs to record the steps to compute the starting unsolved configuration.

It was mixed 10 times (half rotations counting as 1).

It was “solved” with 56 moves.

Seems like a solve algo to me.

Given the source code screenshot it looks like it's using CFOP to solve, so it's not just replaying a scramble.

The problem here is that "self solving" would necessitate that the cube be able to determine what is "wrong" with itself and ultimately figure out not only the "right" self-configuration, but how to get there. That may be a bit much to ask of a cube considering how hard it is for a human to do that.

Stranger still, it might turn out that the cube decides that it's fine the way it already is and it doesn't need to conform to a "right" configuration based on our expectations. In which case; perhaps we're already invented what you're looking for?

Yeah -- what I'm most curious about is how it determines its initial state. Does it need to be powered up and "zeroed" like a scale before it's scrambled? How does the algorithm know which actuator needs to be moved and which direction it needs to be moved in?

It is not as relevant, it is the hardware that looks cool.

No, to me it looks like it did CFOP with an orange cross on the table, and the white cross when he held it in his hand.