Sub-optimal / not solution to R1 U1 F1 about rubikscube-twophasesolver HOT 4 CLOSED

PS. Adding an extra twist: R1 U1 F1 L1
= BUUBUULLDFBBFRRFRRUFRUFRLDRFRUFDBDDBLLFLLFBDDLLDUBDUBR
-> Cube solution: 4 moves L3 F3 U3 R3
Solves optimally.

from rubikscube-twophasesolver.

@jm493, by manually applying F3 U1 D2 R2 L2 U2 D2 R1 L2 to a cube scrambled R1 U1 F1 the cube gets correctly solved.
Thanks to your note I have found a semantic error in the optim_moves2 function of the Cubotino autonomous robot, that was preventing the robot from correctly solving the cube. I have just released the correction.
I cannot comment on the RubikTwoPhase returning less moves when running on a Raspberry Pi Zero2 compared to a Mac, by providing the same timeout.

from rubikscube-twophasesolver.

@AndreaFavero71 Thanks. I see now.
Re-orientate the cube from its post-scan position back to its starting position before applying the moves.

I have installed your latest code, and it generated the same 9-move solution, which the robot applied to correctly solve the cube.
So, the "not solution" part of this issue is solved, we still have the 9-move / 10-move suboptimal answer issue.

from rubikscube-twophasesolver.

sv.solve(cubestring,19,2) has no issue at all.
In the documentation you can read:

This solves the cube described by the definition string with a desired maximum length of 19 moves and a timeout of 2 seconds. If the timeout is reached, the shortest solution computed so far is returned even if it is longer than the desired maximum length.

So your desired maximum length is 19 and the returned solution with 10 moves is within this specification. If a solution with <=19 moves is found this is returned immediately no matter if there are any shorter solutions which might be found within your 2 s timelimit. So you should use sv.solve(cubestring,0,2) or even sv.solve(cubestring,0,0.1) for example and the 3 move solution is returned.

from rubikscube-twophasesolver.