on_activate runs the full reset-then-activate handshake every time. The reset clears rACT, so the gripper releases whatever it is holding and then sweeps the fingers through their full range, blocking for up to activation_timeout (15 s by default).
on_activate is not reached only on a deliberate reset — any controller-manager restart goes through it. A cell that restarts its stack with a part in the gripper drops the part.
This is pre-existing PickNik behaviour carried forward by the SDK migration, not a regression, but it is the highest-consequence behaviour in the driver. Raised in review: #20 (discussion_r3668847184).
Wanted
A hardware parameter selecting between reset-then-activate and activate-only, so starting the driver against an already-activated gripper leaves it alone.
The semantics have prior art in the Robotiq URCap, which distinguishes Activate(1, withReset=False) from Activate(1).
Whether this needs a matching entry point in the grippers SDK or can be composed from what Gripper already exposes is part of the work — the SDK's activate() already leaves a healthy, already-activated gripper undisturbed, while recoverFromFault() is the unconditional reset path.
Workaround until then
Keep the gripper's workspace clear when starting or restarting the stack, and do not restart with a part held.
on_activateruns the full reset-then-activate handshake every time. The reset clearsrACT, so the gripper releases whatever it is holding and then sweeps the fingers through their full range, blocking for up toactivation_timeout(15 s by default).on_activateis not reached only on a deliberate reset — any controller-manager restart goes through it. A cell that restarts its stack with a part in the gripper drops the part.This is pre-existing PickNik behaviour carried forward by the SDK migration, not a regression, but it is the highest-consequence behaviour in the driver. Raised in review: #20 (discussion_r3668847184).
Wanted
A hardware parameter selecting between reset-then-activate and activate-only, so starting the driver against an already-activated gripper leaves it alone.
The semantics have prior art in the Robotiq URCap, which distinguishes
Activate(1, withReset=False)fromActivate(1).Whether this needs a matching entry point in the grippers SDK or can be composed from what
Gripperalready exposes is part of the work — the SDK'sactivate()already leaves a healthy, already-activated gripper undisturbed, whilerecoverFromFault()is the unconditional reset path.Workaround until then
Keep the gripper's workspace clear when starting or restarting the stack, and do not restart with a part held.