fix(driver): estimate joint velocity so stall detection works

[jlongvalRobotiq]

Fixes #29.

Where this comes from

The gripper MCP (mcp/, on feat/mcp) is going through an acceptance matrix before its merge to main, with the expected result for each case written down before the run. Pathway B runs it on a real 2F-85 on the bench, and on the first move it hit #29: every move came back stalled, not at the goal, and at a position partway along. A close over nothing was reported as "stopped on an object" at 77.9 mm, while the fingers carried on to 1.1 mm a moment later. The bug is in the driver, so the fix goes against main, not into the MCP stack.

Why

The driver's velocity state interface was always 0.0. parallel_gripper_action_controller declares a stall when velocity stays below 0.001 rad/s for stall_timeout (0.05 s), so the stall check fired 50 ms into every goal and returned the result while the fingers were still moving. Anything reading the result, not only the MCP, got a wrong answer.

read() now feeds each position sample, with the controller manager's timestamp, into the SDK's VelocityEstimator (robotiq/grippers#42). The estimator is a first-order low-pass filter over the change in position, and it never divides by the sample interval, so a short interval cannot blow it up. With a 100 ms time constant, one spurious position count on a 2F-85 (0.0035 rad) shows up as 0.035 rad/s and falls back under the stall threshold within about 0.4 s of the fingers stopping. Any commanded speed stays far above the threshold. on_activate resets the estimator, so the calibration sweep and the settled starting position don't count as motion.

stall_timeout goes from 0.05 s to 1.0 s, in both controller configs. The controller starts that clock when it accepts the goal, but the first position count from the gripper arrives 50 to 200 ms later (Modbus round trip plus motor start). At 0.05 s, about one close in ten still returned early. At 0.3 s, the slow final approach still tripped it once in twenty moves: near the end, position counts come more than 0.4 s apart and the estimate decays under the threshold in between. With 1.0 s, a real stop is reported about 1.4 s after the fingers stop (the estimate's decay plus the timeout).

What

• hardware_interface.hpp/.cpp: a Robotiq::VelocityEstimator member with a 100 ms time constant, fed in read(), reset in on_activate.
• robotiq_controllers.yaml and robotiq_controllers.humble.yaml: stall_timeout: 1.0.
• extern/grippers: moved to the head of feat: VelocityEstimator, a filtered rate from successive positions grippers#42 (7f5a6a0), which sits on the commit already pinned.

Before merge

Draft until robotiq/grippers#42 merges. After it does, extern/grippers gets re-pinned to that merge commit, not the PR head.

Verified

Bench, real 2F-85 with TSF fingers, the MCP train on top: open and close report reached with the fingers at their stops, a close on a block reports stopped_on_object at the block's width, and the 20-cycle open/close run (40 moves) had no wrong result.

[ebarnett3]

The stall detection this fixed is now decided from the gripper's object detection (#100, #101), so the driver's velocity estimate has no consumer on the real gripper. I recommend closing this PR: #29 tracks the remaining joint_states velocity at low priority, the branch stays for when it is picked up, and it would need re-pinning to robotiq/grippers#42's successor then.