[Unofficial] Robot solves cubic 3x3x9

[IAssemble]

Here is a video of my LEGO MultiCuber solving the cubic 3x3x9. Enjoy!

 

[WBCube]

Wow, that's pretty fantastic. So how long does it actually take for it to solve it?

 

[Hermanio]

Wow, that's pretty fantastic. So how long does it actually take for it to solve it?

Well, it says that it took 6 minutes 45 seconds in the video...

 

[WBCube]

Well, it says that it took 6 minutes 45 seconds in the video...

Oh wow, I can't believe I missed that

 

[IAssemble]

Wow, that's pretty fantastic. So how long does it actually take for it to solve it?

Thanks. I assume you are asking about the processing time on the smartphone (since the video shows the total solve time at the end)?

The algorithm I developed can instantly find a solution but can also search for many different ones. I allow the app 2 seconds of processing time to find the shortest solution it can in that time.

 

[Michael Womack]

Next try the roadblock cube or the crazy 3x3s

I like how it's solving it like the 3x3x5&3x3x7

 

[IAssemble]

Next try the roadblock cube or the crazy 3x3s

I like how it's solving it like the 3x3x5&3x3x7

Thanks for the suggestions. I'll add those to my list for the future as I'm already working on another design at the moment

It is similar to the 3x3x5 and 3x3x7 algorithm as I extended it from my earlier solvers.

 

[qqwref]

After you solve the three "middle layers", why not just directly solve the rest like a 3x3x3 to do the next two "layers" at once? It looks like you're using a ton of extra moves in that step when you could be orienting all the pieces and solving another layer in ~20 moves.

 

[IAssemble]

After you solve the three "middle layers", why not just directly solve the rest like a 3x3x3 to do the next two "layers" at once? It looks like you're using a ton of extra moves in that step when you could be orienting all the pieces and solving another layer in ~20 moves.

Well observed

I guess I could have included my high-speed 3x3x3 algorithm for this (after identifying "edges" appropriately to avoid parity issues)!

Actually, looking at the video, I think it took 41 turns to do the 4th and 5th layers so there is lots of room for improvement!

So how many moves would you expect to take to solve a 3x3x9 yourself?

Anyone like to reconstruct this one? lol

I think it was:

first three layers 27 turns
next two layers 41 turns
next two layers 14 turns
last two layers 21 turns

total 103 turns

EDIT:
I've just remembered why that wasn't an option for my algorithm.... It would have to preserve the orientation of the four three-layer centers (at least to +/-180 degrees)!

But actually I have been working on a high speed algorithm for solving a 3x3x3 cube including the center orientation (which adds another 4096 times more scrambled positions and potentially much bigger lookup tables)...!

On average I expect this takes about 3 turns more than solving a regular Rubik's Cube so maybe more like ~23 turns. What do you think?

 

[qqwref]

So how many moves would you expect to take to solve a 3x3x9 yourself?

A lot. None of my substages are anywhere near the movecounts you get because you can solve them with a computer. I would say that with the aid of a computer solver I could probably improve on your result though.

PS: Another option is to directly solve all pieces like a 3x3x3 at the very start. You would then solve layers 3, 5, and 7 (out of 9). You would want to make sure that layers 1, 5, and 9 are also solvable but I think you can always swap two edges from layers 3/7 to ensure that. This approach would require slice moves to solve layers 4 and 6 but after that you are pretty much home free.

 

[bobthegiraffemonkey]

At the risk of sounding stupid, can you orient everything first (taking account of parity) then permute everything? I would think that the first step is reasonably short, and by permuting all layers in parallel at the same time the second step could be fairly efficient. I don't cuboid much though so forgive me if this is silly.

 

[IAssemble]

At the risk of sounding stupid, can you orient everything first (taking account of parity) then permute everything? I would think that the first step is reasonably short, and by permuting all layers in parallel at the same time the second step could be fairly efficient. I don't cuboid much though so forgive me if this is silly.

I think this is close to what qqwref is suggesting by solving like a 3x3x3 to start to solve layers 3, 5 and 7 (or 1, 5 and 9 perhaps) leaving the rest only needing permuting.

However, permuting all layers in parallel is only efficient if you can do slice moves easily isn't it? The MultiCuber mechanism is reasonably efficient at performing multiple turns of different layers on the same axis (having the same effect as slice moves) but I'm not sure the overall move count (for MultiCuber) would be much less.

It might be interesting to experiment though... (thinks.... )

 

[qqwref]

Well, another fun idea is to solve multiple layers in parallel... how can you do this, you ask? Suppose instead of allowing all moves you only allow <R2,U,D> for each layer. (Each layer's solution should have an even number of R2's.) Then you can combine sequences such as
U D R2 U R2 D + u2 R2 d2 u R2 = U D u2 R2 U d2 u R2 D
Of course you would want to treat all of these moves as slice moves so they only affect that cuboid. Then you can figure out how to actually do the turns, based on where each layer should go, after you have the solution.

 

[IAssemble]

Well, another fun idea is to solve multiple layers in parallel... how can you do this, you ask? Suppose instead of allowing all moves you only allow <R2,U,D> for each layer. (Each layer's solution should have an even number of R2's.) Then you can combine sequences such as
U D R2 U R2 D + u2 R2 d2 u R2 = U D u2 R2 U d2 u R2 D
Of course you would want to treat all of these moves as slice moves so they only affect that cuboid. Then you can figure out how to actually do the turns, based on where each layer should go, after you have the solution.

Thanks. I think this is what bobthegiraffemonkey was suggesting.

It wouldn't need to be restricted to just R2 either if you could spot relative combinations of R2, L2, B2 and F2 that were used in each layer's permutation.

e.g. something like

R2 U F2 U F2 R2 + F2 u L2 d L2 F2 u' = u' d R2 U u F2 U d F2 R2 d'

Yes, that sounds like fun!

 

[qqwref]

I suppose you could do that too. Since F2 is equivalent to u'dU'D R2 ud'UD' (and so on) you could use the move, at each stage, which optimizes the number of moves in between. And if possible you should search for solutions with as few non-U/D moves as possible

 

[IAssemble]

I suppose you could do that too. Since F2 is equivalent to u'dU'D R2 ud'UD' (and so on) you could use the move, at each stage, which optimizes the number of moves in between. And if possible you should search for solutions with as few non-U/D moves as possible

Thanks for the ideas. I may come back to this sometime after my next robotic creation (or two)...