PiPER teleop IK loads MJCF (poor tracking); TeleopIKTask rejects instead of clamps and drops config

(These issues were found by me while testing PiPER teleop in sim; the analysis, summary, and suggested fixes below were produced by Claude.)

Two problems in the teleop IK path, hit while running teleop-quest-piper in MuJoCo sim (also compared against teleop-quest-xarm6/7). Refs at commit 23cd255.

1. PiPER teleop IK uses the MJCF model → much worse tracking than xArm
   PIPER_FK_MODEL points at an MJCF, while xArm points at a URDF:

• dimos/robot/manipulators/piper/config.py: PIPER_FK_MODEL = LfsPath("piper_description/mujoco_model/piper_no_gripper_description.xml")
• dimos/robot/manipulators/xarm/config.py: XARM6_FK_MODEL = LfsPath("xarm_description/urdf/xarm6/xarm6.urdf")

PinocchioIK.from_model_path branches on the extension (dimos/manipulation/planning/kinematics/pinocchio_ik.py:133):

if path.suffix == ".xml":
    model = pinocchio.buildModelFromMJCF(str(path))
else:
    model = pinocchio.buildModelFromUrdf(str(path))

In sim, PiPER teleop is noticeably jittery / poor at tracking compared to xArm. xArm6 is also 6-DOF and teleops smoothly, so this isn't a DOF/redundancy issue, and the IK solver is identical for all arms — the only difference is MJCF vs URDF loading.

piper_description already ships an equivalent URDF: piper_description/urdf/piper_no_gripper_description.urdf. Pointing PIPER_FK_MODEL at it (same 6 revolute joints, so ee_joint_id=6 is unchanged) makes PiPER teleop as smooth as xArm.

Suggested fix: use the shipped URDF for PiPER IK instead of the MJCF.

2. TeleopIKTask rejects the whole tick on overshoot instead of clamping

dimos/control/tasks/teleop_task/teleop_task.py, compute():

if not check_joint_delta(q_solution, q_current, self._config.max_joint_delta_deg):
    logger.warning(f"... joint delta exceeds {...}°, rejecting solution")
    return None

q_current is the arm's measured position, which lags the commanded position. Servo lag alone consumes the per-tick budget (max_joint_delta_deg default 5.0), so moving the controller at a normal speed trips the check, the tick is dropped, and the arm freezes — and the error only grows as you keep moving, so it doesn't recover. This makes teleop unusable at anything but very slow motion.

Clamping to the limit (q = clip(q_solution, q_current ± max_delta)) instead of rejecting turns this into a proper per-tick slew-rate limit: the arm follows at its max rate and catches up, while a genuine IK jump is still bounded. Same reject pattern is in cartesian_ik_task and eef_twist_task.

Related: create_task in the same file never forwards max_joint_delta_deg or timeout into TeleopIKTaskConfig, so they stay pinned at the defaults (5.0 / 0.5) and can't be tuned from a blueprint's params.

Suggested fix: clamp instead of reject; and forward max_joint_delta_deg / timeout in create_task.

Start with dimos/robot/manipulators/piper/config.py, dimos/robot/manipulators/xarm/config.py, and dimos/manipulation/planning/kinematics/pinocchio_ik.py to compare the PiPER and xArm model paths. Then inspect compute() and create_task in dimos/control/tasks/teleop_task/teleop_task.py. Done means PiPER tracks smoothly in teleop-quest-piper, joint overshoot is clamped rather than rejected, and blueprint parameters reach the task configuration.