The Simulation Description Format (SDF) is an XML-based file format used to define the complete state of a simulated world, including robots, static objects, sensors, lighting, and their physical and visual properties. It serves as a scene description language for physics engines like Gazebo, Ignition, and NVIDIA Isaac Sim, providing a more feature-rich and flexible alternative to URDF (Unified Robot Description Format). SDF supports nested models, complex joint types, and detailed physics parameters essential for creating accurate virtual testbeds.
Glossary
SDF (Simulation Description Format)

What is SDF (Simulation Description Format)?
SDF is the primary file format for describing robots, objects, and worlds in high-fidelity physics-based simulation.
A core strength of SDF is its ability to describe entire simulation ecosystems in a single, hierarchical file. This includes specifying inertial properties, collision geometries, surface friction, and sensor models (e.g., cameras, LiDAR, IMU) with high precision. Its declarative nature allows simulation engineers to build and share reproducible virtual environments, which is foundational for sim-to-real transfer learning and the development of digital twins. The format's extensibility makes it a standard for embodied AI research and robotic system validation.
Key Features of SDF
The Simulation Description Format (SDF) is an XML-based standard for describing objects, robots, and environments within physics simulators. Unlike its predecessor URDF, SDF is designed as a complete world description format with native support for complex physics, nested models, and advanced sensor definitions.
World-Centric XML Schema
SDF is fundamentally a world description format, defined by a strict XML schema. It can describe an entire simulated scene, including:
- Static and dynamic objects (e.g., walls, boxes, articulated robots).
- Environmental properties like gravity, magnetic field, and atmospheric models.
- Global lighting and scene ambiance.
- Nested models, allowing complex robots to be composed of reusable sub-assemblies. This holistic approach contrasts with URDF, which is primarily a single-robot description format, making SDF more powerful for multi-robot simulations and complex virtual worlds.
Nested Model Composition
A core architectural feature is the <model> element, which can contain other models. This enables:
- Modular robot design: A mobile manipulator can be composed of a
wheeled_basemodel and anarmmodel. - Reusability: Common components (e.g., a sensor suite, a gripper) can be defined once and instantiated multiple times.
- Simplified kinematics: The pose of a nested model is defined relative to its parent, automatically handling coordinate transformations. This hierarchical structure is more intuitive for complex systems than URDF's flat tree of links and joints.
Physics and Actuator Modeling
SDF provides first-class support for detailed physical and actuation properties, moving beyond simple kinematics.
- Physics profiles: Different physics engines (ODE, Bullet, Simbody) can be configured with parameters for solver type, contact model, and constraint force mixing.
- Joint actuation: Joints can be modeled as revolute, prismatic, screw, or ball types with defined limits, damping, and friction.
- Actuator dynamics: The
<actuator>tag allows modeling of motor characteristics, including torque limits, velocity limits, and PID gain parameters for more realistic control simulation. - Collision vs. Visual Geometry: Geometry for physics (collision) can be defined separately from geometry for rendering (visual), allowing for simplified collision meshes to boost simulation performance.
Comprehensive Sensor Specification
SDF includes a rich, extensible framework for defining virtual sensors that feed data to a robot's control software.
- Sensor types: Native support for camera, depth camera, LiDAR, IMU, contact, force-torque, magnetometer, GPS, and logical (e.g., RFID) sensors.
- Noise models: Each sensor can include configurable Gaussian noise parameters to simulate real-world sensor imperfections.
- Update rates and topics: Sensors define their publishing frequency and the ROS or other middleware topic on which data is broadcast.
- Pose and frame: Sensors are attached to specific links with precise poses, enabling accurate simulation of sensor placement and field-of-view.
Plugin System for Extensibility
The <plugin> element is a critical mechanism for adding custom behaviors and interfaces to models and the world.
- Runtime behavior: Plugins are shared libraries loaded by the simulator (like Gazebo or Ignition) to control a model, a sensor, or a system.
- Common use cases:
- ROS control: A plugin bridges simulated joints to ROS
joint_state_controllerandeffort_controllerinterfaces. - Custom actuators: Implementing non-standard motor models.
- World dynamics: Adding wind, moving platforms, or scripted object spawners.
- ROS control: A plugin bridges simulated joints to ROS
- Separation of concerns: This keeps the core SDF description declarative (describing what exists) while plugins handle procedural behavior (describing how it acts).
Versioning and Backward Compatibility
SDF is a versioned standard, managed by the Open Robotics community, with a formalized evolution process.
- Major versions: Significant releases (e.g., SDF 1.4, 1.5, 1.6, 1.7) introduce new elements and deprecate old ones. The current long-term support version is SDFormat 1.7.
.sdfvs..world: A file containing a single<model>is typically a.sdffile. A file containing a<world>with multiple models is a.worldfile. Both use the SDF schema.- Parser libraries: Official libraries (
libsdformatin C++,sdformatin Python) handle version conversion and validation, ensuring that older model files can be used in newer simulators. - Specification: The formal schema and documentation are maintained at http://sdformat.org, providing a single source of truth for implementers.
SDF vs. URDF: A Detailed Comparison
A technical comparison of the two primary XML-based formats for describing robots and their environments for simulation.
| Feature / Capability | SDF (Simulation Description Format) | URDF (Unified Robot Description Format) |
|---|---|---|
Primary Purpose | Describe entire simulated worlds (robots, static objects, lighting, sensors, physics) | Describe the kinematic/dynamic tree of a single robot |
Model Nesting & Composition | ||
Native Support for Multiple Robots | ||
World Description (Static Objects, Lighting) | ||
Sensor Description (Camera, IMU, LiDAR, Contact) | Comprehensive, native sensor definitions | Limited, often requires ROS extensions |
Physics Properties (Friction, Contact Model) | Per-link and per-collision definitions | Limited inertial properties only |
Joint Types | Extensive (revolute, prismatic, screw, ball, universal, fixed, continuous) | Basic (revolute, prismatic, fixed, continuous, planar, floating) |
File Extension & Versioning | .sdf or .world, explicit version attribute (e.g., <sdf version="1.9">) | .urdf, no formal version attribute |
Default Simulation Tooling | Gazebo (primary), Ignition (now Gazebo) | ROS (Robot Operating System) visualization & tools (RViz, MoveIt) |
Backwards Compatibility | Strict versioning; newer parsers can read older formats | Informal; can break with ROS distribution updates |
Where is SDF Used?
The Simulation Description Format (SDF) is the foundational world-building language for high-fidelity robotic simulation. Its XML-based structure and rich feature set make it the standard for defining complex virtual environments across several critical engineering domains.
Frequently Asked Questions
Essential questions about the Simulation Description Format (SDF), the XML-based standard for defining robots, objects, and worlds in high-fidelity physics simulation.
The Simulation Description Format (SDF) is an XML-based file format used to describe the complete state of a simulated world, including robots, static objects, sensors, lights, and their physical and visual properties. It serves as a universal, versioned specification for populating physics engines like Gazebo, Ignition Gazebo, and NVIDIA Isaac Sim with complex, hierarchical models. Unlike its predecessor URDF, which is primarily for single robot descriptions, SDF is designed to describe entire simulation scenes with support for nested models, more sophisticated physics, and a wider array of sensor types.
Enabling Efficiency, Speed & Accuracy
Intelligent Analysis, Decision & Execution
We build AI systems for teams that need search across company data, workflow automation across tools, or AI features inside products and internal software.
Talk to Us
Search across company data
Give teams answers from docs, tickets, runbooks, and product data with sources and permissions.
Useful when people spend too long searching or get different answers from different systems.

Automate internal workflows
Use AI to route work, draft outputs, trigger actions, and keep approvals and logs in place.
Useful when repetitive work moves across multiple tools and teams.

Add AI to products and internal tools
Build assistants, guided actions, or decision support into the software your team or customers already use.
Useful when AI needs to be part of the product, not a separate tool.
Related Terms
SDF is a core component of the modern robotics simulation stack. These related terms define the ecosystem of formats, engines, and techniques used to build and validate virtual robotic systems.
Physics Engine
A physics engine is the core computational software that simulates Newtonian mechanics, calculating object motion, collisions, and contacts. SDF files define the what (objects, properties), while the physics engine defines the how (laws of motion).
- Core Function: Solves rigid-body dynamics equations in real-time using constraint-based solvers for contact resolution.
- Integration with SDF: The SDF
<physics>tag configures engine parameters like solver type, timestep, and gravity. The<collision>geometry and properties define the input for the engine's collision detection and contact dynamics systems. - Examples: Bullet (used in PyBullet/Gazebo), ODE (Gazebo classic), DART, and MuJoCo (proprietary, high-fidelity).
Digital Twin
A digital twin is a high-fidelity, data-driven virtual representation of a physical system that mirrors its state and behavior in real-time. SDF provides the foundational static description for robotic digital twins.
- Beyond Static Description: While an SDF file describes the initial configuration and properties, a digital twin is a live, synchronized simulation instance.
- Role of SDF: The SDF defines the twin's structure, sensors, and physical parameters. Real-time sensor data and control commands then animate this model, enabling predictive maintenance, hardware-in-the-loop (HIL) simulation, and offline "what-if" analysis.
- Fidelity Requirement: Effective digital twins require high simulation fidelity, which is heavily influenced by the accuracy of the SDF's inertial, collision, and actuator models.
Sim-to-Real Transfer
Sim-to-real transfer is the process of deploying policies, controllers, or models trained in simulation onto physical hardware. The accuracy of the SDF description is a primary factor in bridging the reality gap.
- The Reality Gap: Discrepancies between simulated and real-world robot behavior caused by imperfect modeling in the SDF (e.g., inaccurate friction, motor dynamics, or sensor noise).
- SDF's Role: A high-fidelity SDF model with precise mass, inertia, joint damping, and sensor noise profiles reduces this gap. Techniques like domain randomization often programmatically vary SDF parameters (e.g., masses, textures) during training to create more robust policies.
- Validation: The SDF is iteratively refined using data from physical systems to improve transfer success.

About the author
Prasad Kumkar
CEO & MD, Inference Systems
Prasad Kumkar is the CEO & MD of Inference Systems and writes about AI systems architecture, LLM infrastructure, model serving, evaluation, and production deployment. Over 5+ years, he has worked across computer vision models, L5 autonomous vehicle systems, and LLM research, with a focus on taking complex AI ideas into real-world engineering systems.
His work and writing cover AI systems, large language models, AI agents, multimodal systems, autonomous systems, inference optimization, RAG, evaluation, and production AI engineering.
Partnered with leading AI, data, and software stack.
How We Work
Custom AI workflows for your Business
One-fit-all AI don't work for modern businesses. At Inferensys, we aim to understand your business & custom requirements; which we use to define most efficient agentic workflows, the data, and the tools for your business.
01
Review the use case
We understand the task, the users, and where AI can actually help.
Read more02
Pick the right approach
We define what needs search, automation, or product integration.
Read more03
Build the first useful version
We implement the part that proves the value first.
Read more04
Improve from there
We add the checks and visibility needed to keep it useful.
Read moreThe first call is a practical review of your use case and the right next step.
Talk to Us