wow, that’s a lot of great work! thank you so much for sharing!
did you change the coordinate system at all? i know this is something that’s actually configurable on the firmware level.
on the PLR front end (LiquidHandler), we should standardize the coordinate system. X is from left (smaller) to right, y is from front to back, z is from left to right. All in mm.
this is what the source model is built on. wells with higher y wrt plate are further back (e.g. y of row A > y of row H)
similar to how the EVO backend (and every other backend) converts the universal PLR commands (e.g. aspirate) to specific backend commands (e.g. tecan firmware commands), the backend should also translate from the universal PLR coordinate system to the machine specific coordinate system.
all that should matter on the user-layer is the universal coordinate system. we should be converting/transforming it into the machine coordinate system just before sending those commands.
the zero point is largely arbitrary (relative positions matter most), but we should aim to have a single origin per machine (like the same for all EVO).
Let’s take your EVO’s coordinate system as an example. First, y is flipped so we should multiple all y numbers by -1 in the backend. Second, the y is offset by 345mm to the middle. Since y is bigger towards the front, we should add 345 to translate.
Awesome.
That would be great! See proposal here: Tecan evo supporting different arm configurations. It’s just a draft. I like it, but happy to discuss.
I believe only roma is currently supported for resource movement.
pick_up_tips is used for picking up tips (liha). In PLR, you would never pass a tip to pick_up_resource (we should actually add a check for this on the LiquidHandler level) since pick_up_resource is meant for resource movement, essentially everything but tips/liquid handling.
i think inferring from resource type (tube = pnp) on evo backend is an interesting approach. we should probably do that, in addition to an use_arm: Literal["roma", "pnp"] parameter (or pointing to the specific arm that is configured if we have that ability 
) to explicitly set it.
(the analog is the use_arm: Literal["iswap", "core"] = "iswap", parameter of STARBackend.pick_up_resource)