SDF

Use this skill for SDFormat/SDF outputs that must describe simulation or visualization semantics: models, worlds, links, joints, frames, poses, inertials, collision/visual geometry, sensors, lights, physics, plugins, and simulator metadata.

SDF correctness is primarily a pose, frame, unit, and simulator-compatibility problem. Well-formed XML is not enough. Because language models are weak at spatial reasoning, never generate or edit SDF poses, joint axes, mesh scales, inertials, or plugin parameters from visual impression alone. Derive them from CAD transforms, drawings, simulator documentation, measured dimensions, or an explicit assumption recorded in the design ledger.

Format boundary

• URDF: ROS robot structure: links, joints, visual/collision geometry, inertials, limits, and robot-state publishing.
• SDF: simulator/world semantics: model/world layout, physics, surfaces, sensors, lights, plugins, includes, and simulator-specific behavior.
• SRDF: MoveIt planning semantics: planning groups, end effectors, group states, disabled collisions, virtual/passive planning metadata.

Do not use SDF to patch an incorrect URDF unless the task is explicitly simulator-specific. Do not use SDF to define MoveIt planning groups.

Required workflow

1. Find the source of truth. Treat the Python file defining gen_sdf() as source of truth. Treat configured .sdf files as generated.
2. Identify the target consumer. Record whether the target is Gazebo, another SDFormat consumer, a visualization-only tool, a world handoff, or a model package. Record the required SDF version.
3. Create or update the design ledger. Use references/design-ledger.md before writing XML. Include document kind, frame convention, units, model/world scope, frames, links, joints, geometry, inertials, sensors, plugins, mesh URI policy, and assumptions.