dimensionalOS / dimensionalOS/dimos

[Bug]: xArm7 sim: planner model base at z=0 vs MJCF link_base at z=0.12 — grasps physically miss by 12cm

Open
#3,484 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Python
Stars
4.5k
Forks
808
Avg merge
3d 5h
Merged PRs (30d)
233

Description

Description

In the xArm7 MuJoCo sim setups (e.g. xarm-perception-sim-agent), the manipulation/planning stack's kinematic model and the simulated physical model disagree by 0.12 m in z (exactly the table height). Every grasp planned against perception or scripted coordinates executes 12 cm too high in physics, and the planning collision world is shifted by the same amount, so arm links sweep through the table and objects while the planner reports free space. Skills return success (Pick complete — grasped 'sphere' successfully) while the physical scene is destroyed.

Root cause
  • dimos/data/xarm7/xarm7.xml: <body name="link_base" pos="0 0 .12"> — the MJCF mounts the robot base at z=0.12.
  • dimos/robot/manipulators/xarm/config.py (make_xarm_model_config): the planner-side URDF xacro uses attach_xyz: "0 0 0" — base at z=0. make_xarm7_sim_robot_config() passes no z_offset.

Same joint vector [0.015, 0.376, -0.018, 1.570, 0.005, 1.505, -0.004]:

  • planner FK (get_robot_state, and link7 TF): link7 z = 0.3505
  • file-model FK (offline MuJoCo on data/xarm7/scene.xml): link7 z = 0.4707

Δ = 0.1202 m.

Reproduction
  1. Run an xArm7 sim agent blueprint (we used a headless variant of xarm-perception-sim-agent on current main).
  2. Via the agent (or direct skill calls): clear_perception_obstacles → scan_objects → pick the detected object by its reported name.
  3. Observe: the skill returns Pick complete — grasped '<name>' successfully, but in the sim the arm's approach/retract knocks every object off the table. With a viewer this is directly visible; we additionally instrumented MujocoSimModule to publish free-joint body ground truth (apple/orange/cup PoseStamped @ 20 Hz) and recorded e.g. orange z: 0.175 → 0.045, cup z: 0.190 → 0.035, apple z: 0.170 → 0.040 at the moment of the "successful" pick.

Cross-check without perception:

  • move_to_pose(0.50, 0.0, 0.10) (planner frame) produces a physical touch on the cup (cup z blips +2 mm) — i.e. physical contact happens at planner-z + 0.12.
  • A horizontal sweep at planner-z = 0.17 (the objects' physical height) passes 12 cm above all objects: no contact at all.
What we tried
  • z_offset=0.12 in make_xarm7_sim_robot_config (RobotModelConfig.base_pose) is not sufficient: with the offset applied, a pick still flung all objects off the table (perception registration frame / planning world coupling). So this likely needs a decision on which frame is canonical rather than a one-line offset. Possibly related to the dedicated grasp scene work in #3405 — does xarm_grasp_sim/scene.xml keep the base at z=0.12, and if so how does the planner model stay consistent there?
Additional notes
  • Once objects are contacted, repeated planning attempts can leave the trajectory controller in a latched FAULT state that the reset skill does not clear (all subsequent planning fails with Cannot plan: state is FAULT). Happy to file this separately if it's not already known.
  • Ground-truth instrumentation, rpc traces, and per-object z timelines from the runs above are available if useful.
Environment
  • dimos main (2026-08), xArm7 + MuJoCo sim, headless (EGL), agent = DeepSeek via MCP
  • Linux x86_64

This issue was investigated and drafted with AI assistance (Kimi Code CLI); all experiments were run and measured on the referenced setup.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by comparing dimos/data/xarm7/xarm7.xml and dimos/robot/manipulators/xarm/config.py, then reproduce the reported FK and grasp behavior with the xarm-perception-sim-agent setup. Review the related grasp-scene work in #3405 and determine which frame should be canonical. Done means planner FK, perception coordinates, collision geometry, and MuJoCo motion agree so grasps and table collisions behave physically.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
robotics
Issue type
Bug
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
42/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.