Speed Optimize: Allow 180 degree spins and rotates

[paul-1]

I noticed that running many solves there were a lot of moves that were moving 180 degrees by a series of 90 degree motions. You already had the logic to rotate the cube/solution faces any direction based on how it was sitting. So why not figure out moves from any spot of the robot mechanics. So I added

1) The ability to rotate 180 degrees CW or CCW while spinning or rotating. 2) Added and optimized the move dictionaries. There are different dictionary moves depending on what angle the cube holder servo is currently sitting. When writing the new moves, I chose to optimize spins over flipping.

From my testing, This reduces moves by about 15-20 (180 degree moves are counted as 1) but the big win is 10-20 second faster solves. I left your original move dictionary in for reference. Please test it out.

[AndreaFavero71]

Hi Paul, it sounds like you've given me quite a bit to study :-). You've delved quite a lot into this little robot... and that tells me a lot. As I recall, the original move dictionary is based on the thought of returning to the neutral (home) position after each move of the solver; Any unnecessary moves (S1S3, S3S1) are removed once all moves are combined.

I will definitely try, but I won't be fast (I will have to travel a lot in the next few weekends).

[paul-1]

It’s the S3R1S3R1 moves that drew my attention.

No worries on time, this one is pretty big. Takes some thought, and testing. The animation remapping facelets was tricky, but I think I did that right.

Let me know if there is some clarification needed, or if you find a problem

Sent from my iPhone

On Mar 23, 2024, at 5:29 PM, Andrea @.***> wrote:



Hi Paul, it sounds like you've given me quite a bit to study :-). You've delved quite a lot into this little robot... and that tells me a lot. As I recall, the original move dictionary is based on the thought of returning to the neutral (home) position after each move of the solver; Any unnecessary moves (S1S3, S3S1) are removed once all moves are combined.

I will definitely try, but I won't be fast (I will have to travel a lot in the next few weekends).

— Reply to this email directly, view it on GitHubhttps://github.com/AndreaFavero71/cubotino/pull/26#issuecomment-2016607618, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ABRMN4L7YX57JIK4LLU2GDTYZXX4NAVCNFSM6AAAAABFE4HGE6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMJWGYYDONRRHA. You are receiving this because you authored the thread.Message ID: @.***>

[AndreaFavero71]

Hi Paul, I checked and tested your proposal; It works well, and it's a very nice addition to this project: Thank you.

I wrote a piece of code (a virtual solver, that also verifies the animation part) to fairly compare your proposal toward the current solution: The time benefit is clearly there (ca -13% out of a 10k random generated cubes, only 1.5% of the cases took longer).

There in a minor issue: When the last Spin or Rotation is 180deg, the animation doesn't match the final cube orientation on the Cube_holder (as the Cube_holder will be spinned to Home at the solving end).

After merging your PR, I'll release some changes solving this little issue and allowing the virtual solver. The virtual solver might help bright people like you to find and verify further optmizations.

[AndreaFavero71]

At https://github.com/AndreaFavero71/cubotino/blob/compare180to90/src/Compare_180vs90.py a virtual solver to compare two different Cubotino_T_moves.py (one should be named Cubotino_T_moves_orig.py). The same random generated cube status is solved by both the moves; The estimated servos time (based on the servos' timers) is returned from both the approaches. After every solving run, the cube status is verified if it describes a solved cube. It also has a graphical animation, but that's only useful at the start, not for large runs. This vistual solver can be used to statistically check different Cubotino's moves :-)

[paul-1]

I took a quick look at the virtual solver....interesting. Not sure if it was intended, but it still references the orig file. But this will help, This will make doing some tests to see if some of my assumptions were correct a lot easier.

How long did it take to run 10k tests?

[AndreaFavero71]

Hi Paul, two virtual solvers are available: Cubotino_T_test_random.py (in main) and Compare_180vs90.py (in compare180to90 branch).

1) The first one uses the Cubotino_T.moves.py and it checks the "as is" performances. This solver will remain in the main branch. 2) The second one compares two Cubotino_T_moves.py (of which one must be renamed in Cubotino_T_moves_orig.py) to compare the performances; The second one make use of the same random cuube status for both the "movements" strategies, making possible a fair the comparison. I put this comparison solver on a branch, as I didn't know how to share it, but it is not my intention to move it to the main branch. I thought this comparative approach would meet your interest :-)

Both the solvers prints some stats on the terminal, and write the most relevant data to a text file (tab separated data).

Timing wise, the bottleneck is the cube_solver, as it's set to deliver the first solution meeting one of the two requirements: time or moves quantity. The defaults in Cubotino are 2 second or 20 moves (Full turn metric); With these defaut values, a Raspberry Pi Zero2 delivers about 10K runs in about 2 hours. Because of the limited time, and 20 moves, the solving solutions will mostly rather high (from ca 16 to 23). To lower the solution lenght it will be necessary to give more time to the solver, and to lower the max number of moves; These two parameters are called "sv_max_moves" and "sv_max_time". Perhaps i should change the Virtual solver to automatically change these two parameters to increase the variaty of solution lenght....

By the way, 1.5% of the times the 180deg approach takes longer than the original one. On the CUBOTino Pocket, the code tests several solutions and takes the fastest.... I believe we'll land there :-)

[paul-1]

The virtual solver in the main branch is referencing orig https://github.com/AndreaFavero71/cubotino/blob/1ce2358df87772ab9fc906be4a3940d798fa297c/src/Cubotino_T_test_random.py#L66

Over optimizing moves might take longer than just running the first one.

[AndreaFavero71]

Corrected the import.