Updates to core grippers

[rickwierenga]

updates to the core gripper APIs on STAR:

• deprecate channel_1 and channel_2 parameter and just use one core_front_channel
• core_front_channel is 0-indexed whereas channel_1 and channel_2 are 1-indexed
• rename get_core → pick_up_core_gripper_tools
• rename put_core → return_core_gripper_tools
• support both “at waste” and “on waste” variants of the grippers

the old functions/parameters still work but will be removed soon.

also added a tutorial:

Co-Re Grippers — PyLabRobot documentation

[CamilloMoschner]

This is awesome, thank you @rickwierenga !!

May I ask: Is there a reason for declaring the core_front_channel rather than the core_back_channel?

The core_front_channel can never be channel_0.

This might be a bit confusing because we’re saying we’re using 0-based indexing (as all Python does), and now we do for the overall core_gripper system in PLR, but we can never declare a core_gripper command with channel_0 as its attribute, if I understand this change correctly?

[rickwierenga]

whether it’s front or back is arbitrary

venus uses front, so this will help with venus->plr conversion. I never want to do something based on venus instead of first principles, but in this case what’s the principle? the venus argument is small but the only one

I think the reason is most people use the front channels for moving. on 12 channel (maybe 10?) robots this is actually required, as the back channels can’t even reach the core grippers otherwise

@CamilloMoschner

but we can never declare a core_gripper command with channel_0 as its attribute, if I understand this change correctly?

yes front channel can never be 0

with the back_channel it could never be num_channels-1 - 1

[CamilloMoschner]

@rickwierenga

I never want to do something based on venus instead of first principles, but in this case what’s the principle?

I would say the principle is that Python (and therefore PLR) is using 0-based indexing, so programmers’ expectation is that PLR starts counting from 0.

But that is not enabled if the attribute choice is set to not start from 0.

@rickwierenga

on 12 channel (maybe 10?) robots this is actually required, as the back channels can’t even reach the core grippers otherwise

True - though if one would indeed use channels_10/11 (Python/0-indexed) they would not be able to move anything to the highest y-positions (i.e. carrier site 4, Python/0-indexed); that is just one of the limitations of a Hamilton liquid handling workstation with >8 channels… maybe that is the actual reason for the existence of MFX modules with just a CO-RE gripper parking position (?)