"Gripper" Implementations Discussion

Has anyone else implemented a simple/complex gripper algorithm they'd like to share?

I'm in need for something a bit more efficient than what I have, and was wondering if someone had something they'd like to share, hopefully in Java?

I warn you, what I have is very inefficient and was made a few months ago in a rush to test something.

Anyone that wants to optimize what I have there, in Java, is welcome to do so! If you do, ignore the bit about rotations being worthless, as well as the filtering. The algs I'll be using for this will simply be in the style of "F U D2 F' "etc.

I'll be implementing *something* for a project that should be released within the next day, so any scrap ideas are very much welcome!

statue

I should have it finished by tonight

Better implementations can surely be found

I remember that Badmephisto made something similar a while back but I believe he lost the source code and any online versions of it are dead and gone, I guess he might be able to talk about the way he implemented it though, if you get in contact with him.

Yeah, I have his source. I've edited it, translated it, etc.
It's kinda big, and I really don't need it to be that complex for a while.

He lost his source, by I decompiled it when qq or someone posted the .pyc files here somewhere a while back.

Your approach makes sense, and seems to be useful. I'd change a few things in the next version(s):
- rotations should cost less time, and multiple rotations in a row need to be considered as one.
- L moves should cost MUCH less time, similar to R moves, but there should be something to add time when you have to "switch" from L to R or back. So something like R L U R' U L' should ideally cost more time than (L U L' U')2. And pure left-handed algs should be about the same as the mirrored version. In fact, maybe you could introduce a "hand bias" variable - a bias of +1 would mean R is fast and L is slow, 0 would mean ambidextrous, and -1 would mean R is slow and L is fast. Then each person would set their hand bias personally (determining it through testing) and could generate algs that work best for them.
- This might just require adding more alternatives into the alg list, but the program should be able to try equivalents like R' F R2 U' R' and l' U l R U' R', to see what is fastest.
- Similar point to the rotation one, we would want to treat moves like l R as one move, to avoid treating it as much more time-consuming than an R2, which I don't think it is. Perhaps you could implement something where you subtract a little time whenever two moves on the same axis are together - so you get something like a .05 "bonus" for having l R, or U D', or whatever. This would mirror actual solving where you can do them more or less simultaneously.
- I'd suggest adding a small amount of time for "bad" quarter turn sequences such as R U, and subtracting a small amount for "good" sequences such as R' U. It's a lot faster to do (R U R' U')10 than to do (R U)20, or even (R' U)20.

Also, I assume it wouldn't be hard at all to make an OH gripper with this approach - what do you think?

Alright. Before any changing goes down, I have to convert it to Java, for what I'm using it in.

Once that happens, and everything's published there, I will consider those suggestions.

Right now, I need a Java version of that there, and I'm not exactly sure how to change it. I had one conversion (deepSubDiver, thanks) but I don't understand what's happening with it, nor can I figure out its bugs.

Any help in this conversion would be highly appreciated.

I think that another thing to add would be to tell weather or not you would need to regrip. Just like qq was saying with (R U R' U')10 vs (R U)20 and (R' U)20. I don't have that much time right now to post more stuff but I will come back and think of some stuff.

I know there's a lot to fix and update. This above was simply two things:

1 -Here's my source for a python implementation. It's simple. I need it to be in Java halp?

2 -Does anyone else have implementations complete? If so, can I see?

Ctrl-F "R U R' U'" B)

Finished the java version here.
I don't know python so I had to guess at what things mean so my code might not be that efficient.

qqwref said:

- L moves should cost MUCH less time, similar to R moves, but there should be something to add time when you have to "switch" from L to R or back. So something like R L U R' U L' should ideally cost more time than (L U L' U')2. And pure left-handed algs should be about the same as the mirrored version. In fact, maybe you could introduce a "hand bias" variable - a bias of +1 would mean R is fast and L is slow, 0 would mean ambidextrous, and -1 would mean R is slow and L is fast. Then each person would set their hand bias personally (determining it through testing) and could generate algs that work best for them.
- I'd suggest adding a small amount of time for "bad" quarter turn sequences such as R U, and subtracting a small amount for "good" sequences such as R' U. It's a lot faster to do (R U R' U')10 than to do (R U)20, or even (R' U)20.

Click to expand...

I'm one of those people with L faster than R (and U' faster than U), maybe you could make it so the user can change the times for each move.

Why is R U bad and R' U good? R U is much easier for me to do, and when doing it repeatedly you can do this. Am I just weird? Or maybe I do R' U wrong.

Looking forward to the release, Stachu.

mr. giggums said:

Finished the java version here.
I don't know python so I had to guess at what things mean so my code might not be that efficient.

Click to expand...

Thanks a lot!