Closed RemkoPr closed 1 year ago
@RemkoPr do you have a possible solution in mind? I've never experienced this before actually.
I would like to avoid explicitly activating the gripper at the start of each code, because this is very inconvenient of the previous run stopped due to a collision or something.
For now, we will leave this as is.
In previous experiments, usually Robotiq grippers would be activated at the start of each code run. However, in most cases the gripper was already activated from a previous run, making it unnecessary to be activated again. This is currently handled under the hood in airo-mono: when a Robotiq2F85 object is created, the constructor calls
if not self.gripper_is_active(): self._activate_gripper()
withdef gripper_is_active(self) -> bool: return self._communicate("GET STA") == "STA 3"
This has, however, proven to be unstable (on the UR3e setup). One situation where this has been found to occur (sometimes) is when the gripper controlled via code, then the gripper is conrtrolled using PolyScope (after ending of the code run), and then re-running the code. Now, the gripper_is_active function will return True, but a move call on the gripper will get stuck.