Is this page helpful?

System Identification Extension#

The System Identification extension estimates robot simulation parameters from recorded motion. Use it when a robot asset is structurally correct, but its simulated joint motion or effort response does not match measurements from the reference robot.

Three Franka robots in Isaac Sim showing the system identification flow from an excited reference, through a mismatched initial simulation, to an identified simulation that recovers the reference pose. — From left to right: excite and record the reference system, reproduce the motion with an initial model, then identify and validate parameters that close the simulation gap. The orange pose makes the initial mismatch visible; the green pose recovers the reference behavior.#

The System Identification UI is not enabled by default. Open Window > Extensions, search for system identification, and enable isaacsim.robot_setup.sysid.ui. The interactive extension automatically enables the isaacsim.robot_setup.sysid backend. Open the tool from Tools > Robotics > Asset Editors > System Identification.

Overview#

System Identification replays recorded commands in simulation, compares the simulated response with measured telemetry, and adjusts selected model parameters to reduce the residual error. The extension provides:

Guided setup for the robot, data, parameter space, pre-solve checks, solver, and results.
CSV, ROS 2 bag, MCAP, and local LeRobot-format trajectory ingestion.
Joint-state, effort, and end-effector-pose residuals.
Joint-drive, actuator, rigid-body, inertia, joint-limit, and command-delay parameter families.
Interactive Isaac Sim PhysX and standalone Newton MuJoCo rollout paths.
Exportable headless configurations for differentiable Newton Featherstone rollouts.
Levenberg-Marquardt, CMA-ES, Bayesian, and Adam optimization backends.
Training and held-out validation chunks, parameter sensitivity estimates, USD writeback, and provenance.
Exportable run specifications and a headless job API for repeatable automation.

Conceptually, the solver searches for parameters \(\theta\) that minimize a weighted sum of differences between measured and simulated signals:

\[\theta^* = \underset{\theta}{\operatorname{argmin}} \sum_k \sum_r w_r \left\|y_{r,k}^{\mathrm{measured}} - y_{r,k}^{\mathrm{simulated}}(\theta)\right\|^2\]

Here, \(r\) is an enabled residual channel, such as joint position, velocity, effort, end-effector pose, or another recorded state signal. Parameter bounds keep the search inside a physically meaningful region.

System Identification complements the Gain Tuner. The Gain Tuner evaluates and edits joint-drive gains directly. System Identification fits selected drive, actuator, inertial, and timing parameters against recorded trajectories and validates the fitted model on data withheld from optimization.

For a complete fixed-base Franka walkthrough using recorded MCAP motion, measured command alignment, Newton MuJoCo CMA-ES rollouts, and held-out acceptance gates, see Tutorial 14: System Identification of a Franka.

What you can identify#

Enable only parameters represented by the selected simulator and exposed by the recording.

Parameter family	Examples	Useful excitation or measurement
Joint drive and friction	Friction, stiffness, damping, integral gain, and armature.	Reversals, varied speeds, accelerations, and free-space joint motion.
Actuator dynamics and timing	Integral gain and actuator command delay.	Fast command transitions, accurate timestamps, and motion that exposes stateful controller behavior.
Rigid-body mass properties	Global or per-link mass, center of mass, and inertia.	Coupled multi-joint motion, varied configurations, acceleration, and measured effort.
Joint limits	Lower and upper limit scales.	Slow, supervised motion near the usable range.

Several parameter combinations can produce similar motion. Start with the smallest plausible parameter set, fit it, and expand only after the Check page reports useful sensitivity. Narrow, physically justified bounds are more effective than broad bounds.

Prerequisites#

Prepare the following inputs:

isaacsim.robot_setup.sysid.ui enabled from Window > Extensions (search for system identification).
A USD stage that contains the robot articulation.
The robot prim path, such as /World/Robot.
Time-synchronized command and measured joint-position samples.
Joint velocity, effort, or end-effector-pose samples for any additional residuals.
One or more trajectories that excite the parameters being estimated.
A separate motion segment for validation, when possible.

Tutorial assets for the Franka and double-pendulum walkthroughs live in the Content Browser at IsaacSim/Samples/SystemIdentification/.

The telemetry command must represent the input that reached the modeled controller. Record commands and measurements from a shared clock, or measure their alignment offset explicitly. Verify effort location, frame, and sign conventions before using effort residuals.

Trajectory generation and excitation#

This extension consumes recorded trajectories; it does not generate excitation trajectories. Identification quality depends more on the information in the recording than on the number of optimizer iterations. You cannot recover a parameter if the motion never exposes its effect.

For a practical first recording:

Exercise every joint associated with the selected parameters.
Include changes in speed and direction to separate friction from damping.
Include acceleration and coupled multi-joint motion when identifying mass and inertia.
Use multiple amplitudes or frequencies instead of repeating one operating point.
Avoid abrupt command discontinuities and sustained saturation.
Begin with conservative velocity, acceleration, effort, and workspace limits on a physical robot.
Keep a distinct trajectory or chunk out of the solve for validation.
Use fixed-base or in-air motion when preparing a headless differentiable Featherstone run.

Periodic sine sweeps, multisines, or smooth spline trajectories are common starting points because you can control their bandwidth, amplitude, derivatives, and hardware constraints. The best trajectory is not necessarily the most aggressive one. It is the safest trajectory that makes the selected parameters distinguishable above measurement noise.

For deeper treatment of excitation design, refer to:

These resources describe experiment-design methods, not trajectories that are automatically safe for a specific robot. Validate generated commands against the robot’s joint, velocity, acceleration, effort, and workspace constraints before hardware execution.

Recipes#

Use the Recipe menu to pre-fill a common workflow. Applying a recipe changes the normal controls without locking them. The following recipes cover the drive and inertial workflows described on this page.

Recipe	Intended use	Starting solver
`drive_calibration_inair`	In-air friction, stiffness, and damping calibration.	Headless differentiable Featherstone with Adam.
`full_inertial_inair`	In-air per-link mass, center of mass, inertia, and joint-drive calibration.	Headless differentiable Featherstone with Adam.
`manipulator`	Free-space arm identification with drive and rigid-body parameters.	Levenberg-Marquardt.

Recipes are starting points. The UI can edit and export the differentiable Featherstone configuration used by the in-air recipes, but it does not execute that rollout path. Run the exported specification through the headless entry point. Confirm the execution path, controller feedforward, parameter bounds, residual signals, and output settings for the actual robot.

Identification workflow#

The window uses the following gated six-page workflow:

Robot \(\rightarrow\) Data \(\rightarrow\) Parameters \(\rightarrow\) Check \(\rightarrow\) Solve \(\rightarrow\) Results

Move through the pages in order. Each later page depends on the current robot, telemetry, parameter-space, and preflight signature. If any of those inputs change, rerun Check before solving. Selected-row count is not an identifiability result; use the rank, condition, sensitivity, and per-parameter verdicts reported by the current check.

System Identification Data page showing a recorded Franka trajectory divided into training and validation chunks. — The six-page workspace keeps the robot, telemetry, parameter selection, preflight checks, solve, and validation results in one gated workflow.#

1. Robot#

Select the robot articulation and execution path. The choices differ in both runtime host and UI support.

Physics engine	Use
Isaac Sim (PhysX)	Interactive. Uses the open Isaac Sim stage and authored USD drives. Start the timeline before solving.
Newton (MuJoCo)	Interactive or headless. Runs standalone Newton rollouts without the PhysX timeline and supports derivative-free or batched candidate evaluation.
Newton differentiable (Featherstone)	Headless only. The UI can configure and export this path, but execution must use a headless run specification. It supplies exact gradients for its supported drive and inertial parameters.

Advanced settings are backend-specific. PhysX clone controls do not apply to standalone Newton, and Featherstone substeps do not apply to PhysX or Newton MuJoCo. Controller feedforward must match the controller that produced the recorded motion.

The execution host, physics backend, and actuator runtime are separate run-spec choices. A Newton solver selection does not convert the open PhysX stage into Newton. Headless workflows can use implicit USD drives, explicit Newton actuators, or a mixed arrangement. Each joint must have one control owner during a rollout.

2. Data#

Choose a telemetry source and click Load Trajectory.

Source	Expected input
CSV	Time, commands, measured joint position, and optional velocity, effort, or pose columns.
ROS 2 bag	A ROS 2 bag directory or compatible recording plus a topic mapping.
MCAP	An MCAP file plus a topic mapping.
LeRobot	A local LeRobot-format dataset and selected episode.

Local LeRobot-format ingestion requires PyArrow 24.0.0 in the active environment. CSV, MCAP, and ROS 2 bag ingestion do not require PyArrow.

After loading, confirm the sample count, joint count, sampling rate, available channels, time range, and trajectory preview. A mapping file resolves source-specific topics or columns into the canonical signals.

Divide the data into chunks:

Train chunks contribute to the solver cost.
Validation chunks are held out and evaluated after the solve.
Weight controls a training chunk’s relative contribution.
Excitation tags group validation results by motion type.

Use Auto split for a first pass. Use explicit chunks for separate sweeps, static holds, or other motions that you want to weight and interpret independently. The viewport preview can step through or play the selected chunk.

3. Parameters#

Select Opt only for parameters that the data can constrain. The parameter table groups values by joint, link, and global scope. Each optimized row has an initial value and lower and upper bounds.

The basic table includes joint friction, stiffness, damping, integral gain, armature, and a global link-mass scale when supported. Additional parameter families exposes per-link mass, center-of-mass offsets, positive-definite log-Cholesky inertia, joint-limit scales, and actuator command delay.

Use Expert bounds only when you understand the parameterization and simulator limits. A zero-width, unphysical, or excessively broad interval can make a solve invalid or poorly conditioned.

4. Check#

Click Run Check before starting optimization. The check reports:

Missing, inconsistent, or low-quality telemetry.
Timestamp, sampling, command-alignment, and signal-quality issues.
Controller-feedforward mismatches and actionable configuration suggestions.
Per-parameter identifiability based on the selected data and current setup.
Blocking compatibility issues between the engine, actuator runtime, residuals, and parameters.

Resolve errors before solving. Treat a weak identifiability verdict as a request for better excitation, tighter scope, or a staged solve. More iterations cannot add information absent from the recording.

The check captures the current robot, data, chunks, engine, residuals, and parameter selection. Changing those inputs makes the result stale. Run the check again.

5. Solve#

Leave Optimizer set to Auto for the first run.

Optimizer	Best fit
Levenberg-Marquardt	Smaller, smooth least-squares problems.
CMA-ES	Delay, higher-dimensional, or non-smooth searches.
Bayesian	Expensive derivative-free evaluations with a modest evaluation budget.
Gradient Descent (Adam)	Supported headless differentiable Featherstone problems.

Auto resolves from the exported run specification. It selects Adam for a supported headless Featherstone configuration, favors CMA-ES for command delay or larger non-smooth parameter spaces, and otherwise favors Levenberg-Marquardt for smaller smooth problems.

Advanced solver settings control iteration and rollout budgets, sampling, residual weights, and backend-specific hyperparameters. Give a residual nonzero weight only when its telemetry exists and its conventions are known.

Review Outputs & stage changes before running:

Apply optimized parameters to USD authors accepted values onto the open stage.
Write USD provenance stores isaac:sysid:* metadata on the articulation.
Export provenance sidecar writes the full run context to JSON.
Pause viewport rendering reduces interactive rendering work during optimization.
Export RunSpec saves a reproducible JSON configuration for headless execution.

For an interactive Isaac Sim PhysX rollout, start the timeline, then click Run System ID Optimization. Interactive Newton MuJoCo rollouts do not require the PhysX timeline. If the configuration selects Featherstone, use Export RunSpec and execute it headlessly; the interactive run button is not the supported execution path for that solver. The same button cancels an active interactive run.

6. Results#

During a solve, the Results page displays progress, cost per iteration, and available rollout comparisons. After completion, it reports:

Initial and optimized parameter values.
Per-parameter sensitivity ranges and constraint verdicts.
Active residual channels and convergence notes.
Joint-position, velocity, and effort comparisons when available.
Metrics for held-out validation chunks and excitation groups.

Do not select a result from training cost alone. Prefer a solution that improves held-out validation, behaves well on motions not used for fitting, and retains physically plausible parameter values. Treat a wide sensitivity interval or weakly constrained verdict as uncertainty, not as a precise measurement.

Use Export Run Report to write the latest result summary to JSON.

Use a validation ladder rather than one pass/fail number:

Known-truth recovery checks that the pipeline can recover an injected parameter from synthetic telemetry. It is the quickest way to expose mapping, scaling, and parameter-application defects.
Recorded held-out motion checks whether the fitted model generalizes beyond its training chunks.
Backend and execution parity compares configurations that should agree within declared numerical tolerances, such as captured and uncaptured rollouts. It is a separate implementation gate, not evidence of physical fidelity.
Task validation tests the accepted USD on motions and contacts representative of deployment.

A low residual can pass one rung and fail another. For a reproducible known-truth example, see Tutorial 15: Validate System Identification with Sim-to-Sim Recovery.

Important

Newton MuJoCo CUDA graph capture is enabled by default on CUDA and is appropriate for repeated, fixed-shape population evaluation. Captured and uncaptured rollouts both reset MuJoCo’s rollout-local warm-start, actuator-activation, applied-force, and control buffers before restoring the initial joint state. Compare the two paths with numerical tolerances rather than bitwise equality because small GPU floating-point differences can remain. For a new stage or RunSpec, run an uncaptured comparison with the same parameters, trajectory, timestep, and residual channels. Disable capture if the difference exceeds the acceptance threshold. Graph creation, finite output, or stable replay memory do not establish parity.

In a reference Franka run with 16 candidates and 800 steps, graph replay reduced median evaluation time from 13.59 seconds uncaptured to 0.515 seconds captured, a 26.4x speedup after warmup. This ratio is workload- and hardware-specific; capture failures are reported and fall back to uncaptured execution.

Applying and saving results#

Applying optimized values changes the open stage. Save the stage or intended physics layer to persist the edits. If writeback is disabled, the solve and report remain useful without modifying the asset.

For mixed or explicit Newton actuator workflows, temporary actuator promotion occurs in the session layer. Accepted values are copied to the root layer only when actuator writeback is requested. Cancellation or cleanup discards temporary session edits.

Keep the run specification, provenance sidecar, report, telemetry identity, and source revision together. These records make it possible to reproduce a fit and explain where an asset’s values came from.

Headless operation#

Headless execution is available for repeatable automation and is the only supported execution path for the differentiable Newton Featherstone bridge. The UI remains useful for selecting the robot, loading telemetry, choosing parameters, running the pre-solve check, and exporting a run specification.

The extension includes focused command-line tools:

Tool	Purpose
`headless_sysid_analyze.py`	Evaluate the currently authored parameters and run sensitivity analysis without changing the stage.
`headless_sysid_solve.py`	Execute an exported RunSpec and write result, checkpoint, and provenance artifacts.
`headless_sysid_apply_theta_to_stage.py`	Apply a selected result vector to a new USD after review. The input stage is not overwritten.
`headless_sysid_shift_commands.py`	Materialize a diagnosed command-alignment correction into a derived CSV.
`headless_sysid_simsim.py`	Generate synthetic telemetry from known parameters, identify them through the production pipeline, and score recovery.

Export the UI configuration and run it from an Isaac Sim source checkout:

python.bat tools\headless_sysid_solve.py --run-spec my_robot_sysid_run_spec.json

You can also synthesize a run specification from the primary inputs:

python.bat tools\headless_sysid_solve.py `
    --robot /World/Robot `
    --telemetry data.csv `
    --recipe manipulator `
    --stage robot.usd

Headless integrations can call isaacsim.robot_setup.sysid.execution.run_sysid() when they already own the stage and runtime lifecycle. Use isaacsim.robot_setup.sysid.headless_job.run_headless_sysid_job() for a complete Kit-hosted lifecycle. Use isaacsim.robot_setup.sysid.job_service.SysIdJobService when an automation client submits multiple serialized jobs to one persistent Isaac Sim process.

The service runs one job at a time because the USD context, timeline, and active physics engine are process-wide.

Differentiable Featherstone requires the following run-spec choices:

{
  "simulation": {
    "engine": "newton",
    "newton": {
      "solver": "featherstone_diff",
      "controller": "pd",
      "effort_clamp": "max_effort"
    }
  },
  "solver": {
    "optimizer": "gradient_descent"
  }
}

The following constraints apply to this headless path:

Use a fixed-base or in-air trajectory.
Supported targets are joint friction, joint stiffness, joint damping, link mass, center-of-mass offsets, and log-Cholesky inertia.
Joint armature, actuator command delay, integral gain, and joint-limit scale are not differentiable targets.
The bridge uses mapped-joint PD control. Set controller feedforward to match the controller used during data collection.
effort_clamp must be none or max_effort.
featherstone_substeps controls integration stability and applies only to this solver.
optimizer: auto selects Adam for a compatible specification; setting gradient_descent makes that choice explicit.
The standalone rollout does not use or require the PhysX timeline.

Limitations and practical notes#

System Identification estimates parameters of the selected model. It does not repair an incorrect articulation topology, joint axis, controller architecture, or sensor calibration.
Remote LeRobot dataset download is not part of the local loader.
The headless differentiable Featherstone bridge supports a narrower parameter set than the derivative-free paths.
Neural Newton actuators can be executed when already authored but are not mutable System Identification parameter targets.
Command-alignment correction and actuator command delay are different effects and must not be applied twice.
Large parameter spaces are often better handled as staged identification problems.

Troubleshooting#

Solve is disabled#

Load valid telemetry, select at least one supported parameter, and run a fresh check. Confirm that the robot prim path resolves to an articulation.

The cost decreases but validation gets worse#

Reduce the parameter set, tighten bounds, adjust residual weights, or collect more varied training data. This usually indicates overfitting or coupled parameters.

A parameter is weakly constrained#

Add a motion that exposes the parameter, or remove it from the current phase. Increasing the optimizer budget does not create missing excitation.

The simulated response is shifted in time#

Review the command-alignment suggestion on the Check page. Keep telemetry alignment separate from the actuator command-delay parameter.

The solver finds a bound for several parameters#

Reconsider the bounds, residual conventions, and model structure. A bound-hitting result can also indicate that multiple parameters are compensating for the same error.

Applied values disappear after reopening the stage#

Save the stage or target physics layer after applying a successful result. Session-layer changes are not persistent by themselves.

Differentiable Newton rejects a parameter or residual#

Confirm that the exported run specification is executing through the headless entry point. Remove unsupported joint-limit, delay, armature, or integral-gain terms, use a compatible in-air recipe, or select Newton MuJoCo with a derivative-free optimizer.