Add joint velocity readings (client-side differentiation)

[mmmarinho]

Summary

FRI does not transmit joint velocities (the monitoring message carries only measured/commanded positions and torques). This PR adds joint velocity readings by differentiating the measured joint positions at the FRI send period, entirely on the driver/external-PC side. No cabinet/app changes required.

How it works

• LBRJointCommandOverlayClient now differentiates getMeasuredJointPosition() on each command() call, using robotState().getSampleTime() (the configured FRI period, e.g. 1 ms) as Δt.
• The differentiator:
  • keeps its own previous-position buffer (so it is not affected by command() updating measured_joint_values_),
  • unwraps ±π joint-angle jumps (so crossing the ±180° boundary doesn't produce a velocity spike),
  • guards against non-finite samples,
  • applies a 1-pole low-pass (10 Hz) to damp finite-difference noise.
• New accessor get_measured_joint_velocities() mirrors the existing get_measured_joint_torques().

Interface respected (sas_robot_driver)

No framework changes were needed:

• RobotDriverKuka overrides the base RobotDriver::get_joint_velocities() virtual (whose default throws "Not implemented yet.") and delegates to the client.
• The sas_robot_driver_ros control loop already calls get_joint_velocities() (in a try/catch) and RobotDriverServer::send_joint_states() already fills sensor_msgs/JointState.velocity when non-empty. So velocities now flow through the existing /joint_states topic with no changes to sas_robot_driver.

Verification

• Builds cleanly in murilomarinho/sas:jazzy (colcon build, exit 0). Only pre-existing deprecation warnings (unrelated).
• Confirmed via nm that sas::RobotDriverKuka::get_joint_velocities() override and the client getter are linked into libsas_robot_driver_kuka.so.
• Line endings preserved (the edited files use CRLF, matching the repo).

Notes / caveats

• This is a numerical derivative of ~1 kHz sampled encoder data — good for monitoring/control but not a servo-loop velocity reading. If a cabinet-authoritative value is later needed, options are FRI IO passthrough with cabinet-side differentiation or reading the KRL $SQ register (both require app-side work).

---

This PR was created by an AI agent (OpenHands) on behalf of the user.

[mmmarinho]

Don’t think this filter makes much sense, will come back to this at some point.