in the front end API, we have to split between pipetting channels and arms because they do different thing. It’s nice to be able to pass capabilities around as those are the universal interfaces. It’s nice to be able to pass the core gripper arm (transient object) to functions that require an arm
(the machine specific state tracking will need to be tracked by the backend)
could you elaborate on this?
yes good point, the spaces need to be constrained
In the front end API you are going by capabilities, but what if an arm has the capability to pipette? What if we were to integrate a 6-axis arm that had a automatic tool changer, it could do both pipetting and movement. (i.e. Trilobio has a tool changer on their liquid handler 4 axis arm). This is now no longer an “arm” which its capability is moving plates and it is not longer a channel as it can also move plates! It is both! This is also technically what the CO-RE grips are… they are pipette channels on an arm that can move plates.
An arm has an end-effector that defines its capability, not the way it moves defining it’s capability.
should it not be something like:
star.gantryarm.ichannels
star.gantryarm.iswap
Maybe this just makes things pedantic and hard to share resources?
Then the capability will change. The capability refers to what the robot can do in that point.
The core grippers are the first example: Updating PLR API for machine interfaces discussion - #4 by rickwierenga
other robots in this space can follow a similar pattern:
cap = await robot.pick_up_tool()
star.gantryarm.ichannels
star.gantryarm.iswap
yes, see Modeling liquid handlers - #14 by rickwierenga
An arm has an end-effector that defines its capability
Yes, in physical reality that’s the closest since every machine essentially either has a gantry or joint arm. But the question is whether we should model these robots down to that level. Maybe later it will turn out we will benefit from that. For now I am thinking about “abstractions as they functionally occur”, like the arm capability just means resource movement, the liquid handler capability means tip handling and liquid handling. These capabilities are easy to pass around and use in writing robot agnostic code.
I really like this more and more. Add arms module with Arm/GripperArm hierarchy, Brooks and iSWAP backends by rickwierenga · Pull Request #957 · PyLabRobot/pylabrobot · GitHub
Joints are not useful on the front end since they return robot specific values. There is no potential for making it hardware agnostic. You cannot pick up resources at joint locations because we model everything as cartesian since it is universal. Backends will still expose pick_up_at_joint_position, but will have to use _begin_holding _assign_after_drop etc. separately to do the resource updates. (will be relatively straightforward after we have nice abstractions for arm state updates, we currently do not have that in v0.2)