Refactor keyboard teleop to EEF twist task#2683
Conversation
|
Preview deployment for your docs. Learn more about Mintlify Previews.
💡 Tip: Enable Workflows to automatically generate PRs for you. |
…teleop # Conflicts: # dimos/control/test_control.py
Greptile SummaryThis PR moves keyboard arm teleop onto routed end-effector twist commands. The main changes are:
Confidence Score: 5/5This looks safe to merge.
Important Files Changed
Reviews (4): Last reviewed commit: "remove protocol" | Re-trigger Greptile |
| values = twist_to_numpy(twist) | ||
| candidate.translation = candidate.translation + values[:3] * dt | ||
| angular_step = values[3:] * dt | ||
| if np.linalg.norm(angular_step) > 0.0: | ||
| candidate.rotation = pinocchio.exp3(angular_step) @ candidate.rotation |
There was a problem hiding this comment.
The coordinator uses TwistStamped.frame_id only as the task name, and this integration applies linear and angular values directly in the FK/world pose. Any caller that sends a normal end-effector/body-frame twist will move along world axes after the tool rotates, so a rotated wrist can translate or rotate in a direction different from the commanded EEF-relative motion.
❌ 1 Tests Failed:
View the full list of 1 ❄️ flaky test(s)
To view more test analytics, go to the Test Analytics Dashboard |
Co-authored-by: greptile-apps[bot] <165735046+greptile-apps[bot]@users.noreply.github.com>
Problem
Keyboard arm teleop owned robot-derived state: it read coordinator joint state, required FK model and EEF joint configuration, tracked an absolute EEF pose, and published PoseStamped targets. That mixed input-device behavior with coordinator-owned control responsibilities and made manipulator keyboard blueprints carry duplicate FK wiring.
Solution
Testing