robotiq_driver: velocity state is always 0.0, so every gripper_cmd goal reports stalled / reached_goal false

[ebarnett3]

The velocity state interface is never computed — it is registered, set to 0 once, and stays there. parallel_gripper_action_controller derives stall detection from that value, so every goal trips stall detection and reports stalled: true / reached_goal: false, even when the gripper reaches the commanded position exactly.

Pre-existing, not a regression: PickNik's pre-SDK driver had the same three references to gripper_velocity_ (NaN at construction, the state-interface registration, = 0 in on_activate) and never updated it in read(). The SDK migration preserved the behaviour and made it explicit — read() now assigns 0.0 each cycle, since the gripper's status block carries position and motor current only.

Measured on a 2F-85 (Jazzy, v1.1.0)

goal	landed at	result
position: [0.7]	0.69859 rad	stalled: true, reached_goal: false
position: [0.6]	0.59729 rad	stalled: true, reached_goal: false
position: [0.0]	—	stalled: true, reached_goal: false

Both landings are well inside goal_tolerance (0.02). Sampling /joint_states during an active move yields one distinct velocity value: 0.0.

Controller defaults involved: stall_velocity_threshold = 0.001, stall_timeout = 0.05, allow_stalling = true. Because stalling is allowed, the action still finishes SUCCEEDED — so a client that checks the action status sees success, while a client that checks result.reached_goal sees false on every successful grasp.

Verified on Jazzy. Humble's position_controllers/GripperActionController uses the same velocity-based stall detection, so it is expected to behave the same way there; not yet measured.

The obvious fix is the wrong one

Differentiating position in read() does not work as-is. gPO is 8 bits over roughly 0.8 rad, so one count is ~0.003 rad; at the default 100 Hz exchange most cycles show no change at all and the occasional count-flip produces a large spike. A raw derivative would therefore alternate between 0 and a spike, making stall detection flap rather than behave — arguably worse than the current consistent wrongness.

A real fix needs some combination of:

• filtering the derivative (and accepting the lag that adds),
• re-tuning stall_velocity_threshold / stall_timeout against the resulting signal on hardware,
• or deriving motion state from something other than velocity — e.g. gOBJ, which reports exactly whether the fingers are moving, stopped on an object, or at the requested position (see robotiq_driver: expose effort (gCU) and object-detection (gOBJ) state interfaces #26, which would expose it).

gOBJ is likely the better route: it is the gripper's own answer to the question stall detection is trying to infer.