Position Based Servoing for Bridging Navigation to Manipulation

[alexlin2]

Problem

Closes DIM-658

The nav stack (localPlanner → pathFollower) handles long-range navigation well but is too coarse for short-range body-frame moves needed before manipulation or docking. The existing local_movement C++ node in vector_robotics needs a Python equivalent inside dimos so the rest of the Python stack can use it natively with dimos transport.

Solution

Port vector_robotics/src/gadgets/local_movement/src/localMovement.cpp to a dimos Module at dimos/navigation/local_movement/local_movement.py.

What changed:

• local_movement.py — Full Python port: LocalMovement(Module) with LocalMovementConfig dataclass, PID controller (3 axes: x, y, yaw), terrain-based collision checking (vectorized with numpy), stuck/timeout detection, and a 50 Hz control thread. Uses normalize_angle from dimos.utils.transform_utils. State machine: IDLE → MOVING → COMPLETED / TIMEOUT / STUCK.
• demo_local_movement.py — Demo blueprint with ROSTransport wired to the same topics as the original launch file (/state_estimation, /local_movement, /terrain_map, /cmd_vel, /local_movement/status).
• __init__.py — Package re-exports.
• all_blueprints.py — Registered demo-local-movement blueprint and local-movement module.

Breaking Changes

None

How to Test

1. dimos run demo-local-movement — verify module starts and subscribes to ROS topics
2. Start navigation stack on G1
3. Verify /cmd_vel publishes TwistStamped commands and /local_movement/status transitions through MOVING → COMPLETED
4. Publish terrain points inside the vehicle footprint on /terrain_map and verify collision stops zero the blocked axis

Contributor License Agreement

• I have read and approved the CLA.