Simulation & digital-asset dossier · 06

Drake model directives: assembling traceable multibody scenarios for design and verification

Use YAML model directives, PackageMap resource resolution, URDF or SDFormat inputs and MultibodyPlant as an explicit assembly graph, while retaining the source, rights and parser behaviour of every referenced package.

Evidence statusModel-based design and verification toolbox · explicit assembly schema · remote resources require independent provenanceSources checked 4 August 2026

Identify the exact asset first

A catalogue name cannot replace the exact format, upstream commit, generation arguments, runtime and licence.

Drake is a C++ and Python toolbox for model-based design and verification in robotics, with an emphasis on exposed mathematical structure, multibody dynamics, optimisation, planning and control. Its model directives schema assembles multiple URDF or SDFormat resources, frames, welds, namespaces and collision filters into a MultibodyPlant; PackageMap resolves local or remote package resources.

Digital asset map

Put formats, geometry, dynamics, scenes, loaders, versions and provenance onto one dependency map.

01

Model inputs

Publicly available

URDF and SDFormat resources provide links, joints, geometry, inertials and referenced package assets.

Verify before adoption

Freeze source package, commit, parser version, file checksum, units, variant and all referenced meshes or textures.

02

Model directives

Publicly available

YAML directives can add models, model instances, frames, welds, included directive files and collision-filter groups.

Verify before adoption

Archive flattened directives, namespaces, frame transforms, weld graph, collision filters and processing order.

03

Package and remote resolution

Publicly available

PackageMap maps ROS-style package names to local paths and can download declared remote packages when requested.

Verify before adoption

Pin remote URLs, archive type, sha256, strip prefix, package.xml, local map and offline reconstruction procedure.

04

Plant, geometry & analysis

Publicly available

MultibodyPlant and SceneGraph expose model structure for dynamics, contact, planning, optimisation and verification workflows.

Verify before adoption

Record time step, scalar type, contact approximation, solver, geometry roles, context, parameters and analysis assumptions.

Layered licence reading

Loaders, model XML, meshes, textures, brands and generated outputs may belong to entirely different rights layers.

Asset layerKnown statusAdoption decision
Drake source

Drake states that its components use the BSD 3-Clause License, with noted portions potentially under other permissive licences.

Preserve notices, inspect noted exceptions and pin the release or commit used.

Referenced model packages

URDF, SDFormat, meshes and remotely resolved packages retain their own copyrights and licences.

Attach a package-level and file-level rights manifest to every assembled scenario.

Robot names, vendor geometry & datasets

Toolbox licensing does not grant unrelated trademark, design, dataset or hardware rights.

Separate analysis permission from redistribution, endorsement and manufacturing claims.

This table is a source-navigation and engineering-decision aid, not legal advice. Use original licence texts and qualified advice for an actual decision.

Model & asset validation gates

From identity freeze and structural checks to behavioural calibration and experiment replay, prove what the model can support one gate at a time.

  1. 01

    Resolved assembly manifest

    Evidence to preserve

    Drake release, flattened directives, package map, remote checksums, source licences, input files and generated plant summary.

    Stop condition

    Stop if any package URI, remote checksum or included directive cannot be resolved deterministically.

  2. 02

    Topology and geometry checks

    Evidence to preserve

    Model instances, link/joint tree, frames, welds, limits, inertials, geometry roles, collision filters and parser diagnostics.

    Stop condition

    Do not proceed with unresolved duplicate names, missing frames, invalid inertials or unintended collision exclusions.

  3. 03

    Numerical and behavioural validation

    Evidence to preserve

    Static equilibrium, energy, gradients, contact, integration sensitivity, controller response and comparison with analytic or measured references.

    Stop condition

    Do not treat solver convergence as proof that the model or task assumptions are physically correct.

  4. 04

    Reproducible verification claim

    Evidence to preserve

    Declared proposition, model boundary, uncertainty, solver and options, seeds, tolerances, counterexamples and retained failure results.

    Stop condition

    Do not generalise a proof, optimisation result or simulation beyond its declared model and assumptions.

FUURAA analysis

A digital asset becomes valuable when a team can explain where it came from, how it changed and which behaviours have been proven.

01

Best use

Building explicit multibody assemblies whose mathematical structure can support dynamics, optimisation, planning, control and verification research.

02

Main risk

A compact directive file can hide remote package changes, parser semantics, frame assumptions, collision filtering and numerical modelling choices.

03

FUURAA judgement

Publish the flattened directive graph and resolved package manifest beside every result; then state exactly which physical proposition the model evidence supports.

Applicability boundary

Simulation assets can accelerate research, training and integration; they do not automatically become manufacturing drawings, a physical digital twin or a safety case.

Can support

  • Traceable multibody scenario assembly
  • Optimisation, planning and verification research
  • Resource-pinned model regression

This page cannot replace

  • Validated physical robot engineering package
  • Independent safety and conformity assessment
  • Rights review for every referenced package
Continue into the robot product development pathFrom digital model and verification to controlled prototype →