Hello! This is a bit off topic. I wanted to share some thoughts, as a hardware developer, about the first post.
Given its aim, I feel like PLR is overly judgy of the hardware. It is too opinionated for an agnostic front-end.
I might argue that it is not the OT2 API that was constrained. If I am guessing correctly, it may instead have been that the APIs on the STAR and EVO did not offer a good abstraction for operations in the first place, and PLR (PyHamilton at the time) compensated.
After all, it would have been easier to just command “aspirate from tube1 and pour in well3”, instead of spatially modelling every aspect of the workspace.
To me PLR is about backends and decks - thin adapters for what the hardware offers - and exposing a uniform front-end to all users. This front-end is still not fully uniform (e.g. backend_kwargs and some idiosyncrasies around resources) and ironing that out would be more interesting from my perspective.
In this sense, updating PLR to the latest OT API sounds PLR-ly, and I’m glad to see this happening, while installing third-party software on the robot (to make it do what others do) sounds strange. Unless PLR’s aim is to take over the robots, the message is that others should be like Hamilton.
I think that PLR should focus on more abstract, non-spatial commands instead, and expect less from the machines. That is, to move away from the hardware instead of towards it. This is what I expect from an agnostic front-end.
Sorry for the intrusion. I hope these opinions can be helpful 