From URDF to OpenRGD: importing what the file proves — and nothing else

SECTION 01

The import begins with a partial profile.

The current toolchain exposes a direct import path for URDF. Its output is intentionally small. Rather than generating an apparently complete OpenRGD project, it emits only the Foundation modules that the importer can justify from the source material.

That design makes the absence of information useful. If the imported source cannot prove kernel identity, alignment, cognition, safety policy, HAL bindings or controller configuration, those concepts do not appear as silently inferred facts.

rgd import robot.urdf --out partial-robot

partial-robot/
└── spec/
    └── 01_foundation/
        ├── description.jsonc
        └── actuation_dynamics.jsonc

SECTION 02

What the importer can preserve.

The supported evidence boundary includes robot and link structure, inertial data, joint topology, declared limits, authored dynamics and mimic relationships. Where physical values are present, the importer preserves them with type-correct semantics rather than flattening them into untyped text.

That is enough to create meaningful machine-readable grounding, but it is intentionally not enough to operate a robot.

• Robot name, links and supported structural relationships.
• Mass, inertial origin and complete inertia tensor when authored.
• Joint type, parent-child topology, origin and axis.
• Declared revolute and prismatic limits.
• Damping and friction when present in source.
• Explicit mimic relationships.

SECTION 03

Missing values stay missing.

The importer does not improve a source by inventing convenient numeric defaults. Absent numeric values remain absent. Malformed or non-finite physical values fail import. That rule matters because a deterministic-looking zero can be more dangerous than an explicit unknown.

The same principle applies to concepts outside the URDF evidence boundary. Transmissions, controller configuration, vendor plugins, bus addresses, calibration and safety policy are not inferred merely because a physical system will eventually need them.

SECTION 04

Integrity and validation are separate steps.

After import, the toolchain can validate source-tree identity and selected modules with rgd hash, rgd check and a deterministic non-actuating rgd boot. These operations improve confidence that the profile is internally coherent and that the content being reviewed is the content being consumed.

They do not transform source identity into physical validation. A correct hash says that bytes match. It does not say that a motor is wired correctly or that a limit is safe for a particular installation.

rgd hash partial-robot
rgd check partial-robot
rgd boot partial-robot

SECTION 05

Enrichment is explicit and remains unverified until proven.

OpenRGD also supports an explicit seed-enrichment path. The important part is not that enrichment exists; it is that inherited assumptions remain labeled. A generated project records seed_compatibility_status = UNVERIFIED rather than pretending that inherited calibration, HAL, safety or behavioral assumptions are now facts about the imported body.

This is the pattern we want for every importer: preserve evidence, expose transformation, label assumptions and keep physical authority elsewhere.

rgd alive robot.urdf --out RGD-robot --seed default