Chapter 9: Make a Custom Robot Trustworthy — URDF, Calibration, Identification, and Sim-to-Real

Overview

Receiving a URDF is the beginning of custom-robot integration, not the end. A URDF can describe a plausible link tree while carrying a wrong axis sign, an approximate inertia, decorative collision geometry, missing transmissions, or controller semantics that exist only in a vendor SDK. An importer can preserve the picture while changing the physical experiment. This chapter therefore treats the robot asset, calibration records, identified parameters, controller configuration, and validation data as one versioned digital-twin release.

The practical objective is modest but demanding: make the same safe, measured excitation in reality and simulation; explain the remaining difference; and prevent later software or asset changes from silently making it worse. We first audit geometry and semantics, then calibrate frames, identify timing and dynamics in stages, fit contact and sensors only where the task needs them, and validate on held-out motion. Domain randomization and adaptation come after a measured nominal model. Broad policy learning, VLA, and world models remain #S12/#S13 topics.

After reading this chapter... - You can turn an incoming URDF and vendor manual into a machine-checkable asset audit. - You can import into USD and MJCF while tracking semantic loss rather than trusting appearance. - You can separate joint-zero, world/base, TCP, camera, and hand–eye calibration. - You can design bounded excitation and staged identification for delay, friction, actuation, and dynamics. - You can compare real and simulated motion with held-out time- and frequency-domain metrics. - You can build an uncertainty budget, justify randomization ranges, and enforce regression gates.

1. Freeze the incoming package and write its contract

Do not begin by “fixing” the only copy of the URDF. Preserve the original archive, checksum every file, record the supplier and date, and create a working copy under version control. Collect the matching controller manual, joint naming table, CAD or mass properties, electrical/gear data, calibration certificate, SDK version, firmware version, and a description of what each command means. Record whether position means motor-side, output-side, or already calibrated joint position; whether effort means commanded current, estimated torque, or a measured value; and where limits are enforced.

Define three states. The source asset is untouched supplier evidence. The normalized asset has explicit units, stable names, portable mesh paths, and documented fixes. A simulator realization is a particular USD or MJCF conversion plus simulator-only contact, drive, or sensor configuration. Never overwrite the source with a realization. Give each state a digest and connect it to calibration and identification versions in a manifest.

A custom asset is trustworthy only after topology, units, axes, signs, zeros, limits, frames, collisions, mass, inertia, transmissions, coupling, and actuator semantics are checked. ^{[1] [2] [5] [7]} This is an inspection claim, not a promise that those fields are correct merely because they exist.

Structural and physical audit

Start with the kinematic tree. Confirm one intended base, expected parent–child topology, no disconnected operational links, and no accidental loop that URDF cannot represent. For every joint, compare name, type, parent, child, origin, axis, positive direction, home/zero, hard range, soft range, velocity, effort, and damping against the vendor source and a slow read-only or reduced-motion observation. Revolute axes must be unit vectors in the joint frame; a sign error can hide at zero and invert control later.

Check mimic joints, coupled fingers, differential mechanisms, tendons, and closed chains explicitly. A mimic relation is only a kinematic relation; it may not reproduce force sharing, backlash, tendon elasticity, or a mechanical differential. Check transmissions and hardware interfaces separately from joint geometry. For a hand, list independent actuators, sensed joints, passive joints, coupling matrix or tendon route, and the meaning of one command unit.

Inspect visual and collision meshes independently. Visual meshes may be detailed and non-watertight; collision shapes should be stable, correctly scaled, and sufficiently faithful at task contacts. Display collision-only geometry and test self-collision pairs. Overly coarse fingertips change grasp contact; overly detailed meshes create unstable or expensive contact. Record every disabled collision pair and its physical justification.

Mass must be positive. The center of mass must lie in a plausible location. The inertia tensor must be symmetric, positive definite, expressed about the declared center in the declared frame, and consistent with mass and dimensions. Unrealistic tiny inertia, copied diagonal values, a millimeter-scale mesh interpreted as meters, or an inertia taken about a different origin can all compile. Use CAD or manufacturer data as a prior, not unquestioned truth. The physically consistent inertial-parameter literature explains why arbitrary least-squares values can violate rigid-body physics ^[18].

Figure 9.1 — Identification and policy-training pipeline for Precise Adaptation through Continuous Evolution (PACE). Source: Bjelonic et al., 2025, Figure 3. This is legged-system evidence; a custom arm still needs its own semantic audit and held-out validation.

2. Import to USD and MJCF without losing meaning

Isaac Sim can import URDF into a USD articulation, and its importer exposes choices such as base fixation, drive type, gains, and inertia handling ^{[1] [2]}. MuJoCo compiles MJCF into its own model with bodies, joints, geoms, inertias, actuators, tendons, equalities, contacts, and sensors ^[5]. Conversion is not a neutral file-format change. Treat the original robot semantics as requirements and each simulator as an implementation.

Visual agreement after import is insufficient because USD and MJCF can represent drives, contacts, tendons, constraints, and sensors differently. ^{[3] [4] [5]} A matching screenshot establishes neither matching degrees of freedom nor matching response.

After import, regenerate an invariant report rather than comparing XML text. Count links, independent and passive joints, actuators, limits, collision shapes, and sensors. For a small pose suite, compare forward kinematics of named frames against an independent reference. Apply positive joint displacement one joint at a time and compare direction. Query mass, total center of mass, gravity torque, and default state. Then run zero-input settling, bounded single-joint steps, and collision-distance tests.

Build a semantic-loss checklist. USD drive stiffness and damping are not automatically identical to a vendor impedance loop. MJCF actuator gear, force range, activation, armature, damping, friction loss, and solver contact parameters each have specific meanings. URDF mimic, transmissions, safety controllers, plugins, and custom tags may be ignored or translated incompletely. Closed chains or tendon routing often need native constraints after import. Camera intrinsics, distortion, rolling shutter, tactile outputs, encoder quantization, and controller delay usually need explicit modeling.

Exporting a modified USD back to URDF can discard USD-native information, so do not use round-trip equality as proof ^[3]. Keep explicit patches or generation scripts and a human-readable change log. A release should state which simulator is authoritative for which test: Isaac Sim may be chosen for ROS, cameras, and scene integration, while MuJoCo may be chosen for fast contact or control experiments. Exchange validated assets, task definitions, trajectories, and logs; do not assume live numerical equivalence.

3. Calibrate geometry as separate estimation problems

First decide what is calibrated and what remains fixed. Joint offsets and geometric link parameters affect forward kinematics. Base-to-world places the robot in the cell. TCP identifies the active tool center and orientation. Camera intrinsics describe projection; camera extrinsics place the sensor. Eye-in-hand calibration relates camera and flange; eye-to-hand and robot-world–hand-eye variants solve different transform chains. A table or fixture frame is another calibrated object, not “the world” by convenience.

Joint-zero, base-world, TCP, camera-intrinsic, hand-eye, and robot-world-hand-eye calibration are distinct problems requiring held-out poses. ^{[8] [9] [10] [11] [13]} Solving one does not absorb unexplained error in the others without creating parameter ambiguity.

Use a ladder. Verify encoder repeatability and mechanical home first. Estimate joint-zero or geometric corrections with a metrology target or external tracker across the usable workspace. Calibrate the actual TCP and payload mounting. Calibrate camera intrinsics at the working focus and resolution, then hand–eye/extrinsics with timestamped robot and target poses. Finally calibrate task fixtures and validate the whole chain on poses not used for fitting.

Pose diversity matters more than collecting many nearly identical samples. Excite translations and noncommuting rotations within a safe, well-observed volume. Avoid a single plane or narrow wrist rotation. Synchronize robot and camera measurements; motion during an unknown offset appears as spatial calibration error. Reject or model frames with poor target localization. Save raw images, detected features, robot states, timestamps, target definition, solver settings, and residuals so another solver can be tested without recollection.

Hand-eye accuracy depends on pose diversity, synchronization, localization, and model assumptions; no algebraic solver is universally best. ^{[9] [10] [12] [14]} Compare solvers on held-out transform consistency and task-space error, not only their training residual.

Report translation and rotation residuals separately, plus TCP or reprojection error across workspace regions. Inspect residual direction: a constant bias suggests a frame or target offset; error growing with reach suggests joint/link geometry; error correlated with speed suggests time alignment or compliance. Define acceptance from task tolerance, sensing resolution, and safety margin. This book does not invent one universal millimeter threshold for every arm and camera.

Figure 9.2 — Platform scope evaluated by the legged-system-centered PACE study. Source: Bjelonic et al., 2025, Figure 4. Do not transfer its platform counts or performance results to fixed-base arms.

4. Design synchronized, bounded identification experiments

Identification begins with observability and safety, not an optimizer. List available signals: commanded mode and target, controller timestamp, encoder position/velocity, current, estimated torque, external force/torque, TCP pose, camera/tactile data, safety state, temperature, and supply voltage. State their units, frames, clocks, filters, rates, quantization, and whether values are measured or inferred. Log raw signals where permitted and preserve controller configuration.

Create training excitations and held-out excitations with different trajectories but the same safe envelope. Excite one mechanism at a time before multijoint motion. Stay away from hard limits and unexpected contact; use reduced speed/effort, a cleared cell, an observer, and the validated Chapter 7 stop path. Persistent excitation should cover the frequencies and configurations relevant to the task without trying to make every parameter identifiable ^[17].

Synchronize acquisition on a common clock or estimate offsets. A command-to-state delay can masquerade as damping; filtered velocity can bias friction; structural flex can appear as joint offset; a warm gearbox can differ from a cold one. Record experiment ID, robot/asset/calibration/controller versions, payload, pose range, temperature, safety events, and the exact sample selection used for fitting.

A staged identification order

1. Clocks and command delay: fit or measure transport, scheduling, controller, sensing, and filtering delay using low-amplitude free-space signals. Check whether delay varies with load or rate.
2. Encoder bias and scale: compare static or slowly varied external pose after geometric calibration. Do not let dynamics compensate for a kinematic bias.
3. Gravity and payload: use diverse static/slow configurations to check mass, center of mass, payload, and torque/current consistency.
4. Inertia and armature: use bounded multisine or Fourier-like motion with adequate acceleration across configurations. Separate motor-side reflected inertia where the model supports it.
5. Friction: include positive/negative velocities, reversals, multiple speeds, dwell, and temperature. Distinguish viscous, Coulomb, stiction/Stribeck-like, and hysteretic behavior only as data justifies.
6. Torque–current and saturation: identify sign, offset, gain, dead zone, current/torque/rate limits, and supply dependence from independently safe evidence.
7. Position/PD/impedance loop: fit the closed-loop response of the mode actually used, including gains, feedforward, filters, rate limits, and delay. Never equate a UI gain number with an ideal spring without a response test.

Inertial identification estimates identifiable base-parameter combinations, so excitation and physical consistency matter as much as optimizer fit. ^{[15] [16] [17] [18]} Do not report every URDF link inertia as independently measured when the experiment only identifies combinations.

Use a regressor or simulator-based fit appropriate to the controller access, but constrain physically meaningful quantities. Compare fitted parameters with CAD/BOM priors and flag implausible compensation. Training loss alone rewards a model that absorbs timing, friction, and calibration mistakes into inertia.

Closed-loop identification must address feedback-correlated noise and validate torque or trajectory prediction on held-out excitation. ^{[19] [20]} Instrumental-variable or other closed-loop-aware methods may reduce bias, but the decisive check is prediction outside the fitting trajectory.

For torque-accessible systems, report measured or estimated versus predicted torque/current per joint. For position-controlled black boxes, compare command-to-state trajectories and frequency response; do not pretend internal torque is observed. Fit in stages, freeze accepted stages, and reopen them only with evidence. Maintain parameter covariance, bootstrap ranges, or at least sensitivity intervals rather than a single magic vector.

5. Identify contact, material, and sensors at task scale

Free-space agreement is necessary before contact fitting. Then choose representative, safe contact primitives: fingertip approach to a rigid plane, gripper closing on calibrated objects, tangential slide under controlled normal load, small release/drop where permitted, and force/torque or tactile indentation. Measure geometry and surface condition. Repeat across relevant speed, load, material, temperature, and object variation.

Friction, backlash, elasticity, armature, delay, saturation, torque mapping, gains, and temperature should not be collapsed into one damping constant. ^{[21] [22] [6] [20]} Several combinations can fit one trajectory and fail differently at reversal, impact, or load.

For contact, compare onset pose, penetration or compliance proxy, normal force or current, tangential slip, rebound, sticking transition, and final object pose. Solver parameters are numerical as well as physical; a smaller timestep or more iterations may change results. Record simulator version, timestep, solver, integrator, contact margins, geom approximation, material parameters, controller rate, and all filters. Fit only what the measured experiment can distinguish.

Sensors need their own models. Calibrate force/torque bias, frame, scale, cross-axis coupling, bandwidth, filtering, and saturation. For cameras, model intrinsics/extrinsics plus exposure, depth validity, noise, occlusion, and latency at the task distance. For tactile sensing, compare contact location, force/indentation response, hysteresis, spatial resolution, dead taxels, drift, and rate. Terry's tactile-skin survey notes are available in Korean and English. DexForce's force-informed demonstrations are discussed in Korean and English.

The goal is not photorealistic or waveform-perfect simulation everywhere. Declare the task-sensitive outputs. A VLA perception study may need camera geometry, latency, and appearance variation but only coarse motor torque. In-hand manipulation may need fingertip geometry, contact, hand coupling, tactile delay, and controller bandwidth. Global contact planning, discussed in Terry's Korean and English notes, needs credible feasibility and contact transitions. Spend identification effort according to that dependency map.

6. Validate by replay in time and frequency domains

Create paired trials from a common experiment specification rather than forcing simulation to replay a noisy real state exactly. The specification includes initial state and tolerance, payload/object, command trajectory, controller mode and gains, sample clocks, environment, and stop criteria. Run the real excitation safely, then reproduce the measured command and conditions in each simulator realization. Do not fit on the validation trials.

Matched real and simulated safe excitations should report joint, torque or current, TCP, contact, and task errors on held-out trials. ^{[17] [20] [23]} PACE is legged-robot evidence and requires manipulator-specific adaptation.

Time-domain metrics include joint position/velocity error, phase lag, overshoot, settling, peak and integrated torque/current error, TCP position/orientation error, contact onset, peak/impulse or force trace, slip, object pose, and task outcome. Report per joint, configuration, direction, payload, speed, and contact mode rather than only one average. Plot residuals against position, velocity, acceleration, load, time, and temperature to expose structure.

Frequency-domain validation separates problems hidden by trajectory RMSE. Estimate command-to-joint or torque-to-motion frequency response where access and safety allow. Compare magnitude, phase, coherence, resonance, and bandwidth over the task-relevant band. Low-frequency bias suggests gravity, zero, or friction; growing phase error suggests delay/filter; resonance mismatch suggests compliance or inertia; direction-dependent residuals suggest friction/backlash. Do not interpret frequencies beyond sensor, command, or excitation support.

Acceptance thresholds are project-set. Derive them from the manipulation tolerance, collision clearance, grasp margin, controller bandwidth, sensor resolution, policy observation/action rate, and risk analysis. Write the threshold before viewing the held-out result. A model can pass free-space motion and fail contact, or pass mean error and fail the tail that causes drops. Promotion requires every safety-critical metric plus the declared task metric, not a favorable aggregate.

Figure 9.3 — PACE validation example combining real/sim trajectories and a delta phase portrait. Source: Bjelonic et al., 2025, Figure 1. An arm requires separate held-out TCP, joint, current/torque, and contact replay.

7. Build an error budget before adding robustness

Create an error budget with categories: asset topology/geometry, frame calibration, timing, sensing, actuation, rigid-body dynamics, friction/transmission, compliance/backlash, contact/material, environment/object, and stochastic or unmodeled residual. For each category record metric, estimate, uncertainty, affected task output, evidence, owner, and next discriminating test. Avoid double counting: a camera timestamp error can appear as hand–eye error; a motor delay can appear as damping.

What PACE contributes—and what it does not

PACE presents a physics-informed method for automated system identification and controller evolution on legged robots ^[23]. Its transferable lesson is experimental architecture: collect synchronized hardware data, fit selected parameters, validate behavior, retain uncertainty, and integrate the improved model into a learning/control loop. Its locomotion metrics, contact pattern, floating-base observability, actuator layout, and controller objective differ substantially from a fixed-base arm and dexterous hand.

PACE reports three primary platforms, ten additional robots, and a 32 percent ANYmal cost-of-transport reduction, none of which transfers quantitatively to fixed-base arms. ^[23] Do not convert that number into an expected manipulation success or energy improvement. For an arm, replace locomotion cost and foot–ground tests with held-out TCP, joint, current/torque, controller-response, grasp/contact, and task metrics. Hand tendon coupling, fingertip contact, camera/tactile timing, and table fixtures require new experiments.

Randomize residual uncertainty, not ignorance

Domain randomization is most defensible after a measured nominal model, with ranges tied to residual uncertainty. ^{[24] [25] [26] [27]} Broad randomization can create robustness, but it can also train on impossible robots, hide a sign error, reduce useful precision, or shift learning effort away from the real system.

Choose distributions from calibration covariance, repeated identification, temperature/load variation, manufacturing tolerance, and held-out residuals. Preserve correlations: mass and inertia, delay and command rate, friction and temperature, camera pose parameters, or tendon coupling may not vary independently. Distinguish episode-constant parameters from rapidly varying noise. Test whether the real validation traces fall inside simulated predictive envelopes without making the envelope meaningless.

Bayesian simulation inference, active identification, and adaptive randomization can select plausible parameter distributions ^{[25] [27]}. They do not eliminate parameter nonidentifiability or unsafe excitation. Record priors, bounds, posterior or selected ranges, simulator version, and the real data used. Hold out a final real set that never guides range selection.

8. Residual and online adaptation need a rollback path

A residual dynamics model or online adapter may improve the remaining structured error, especially when rigid-body/contact models are incomplete. Keep it outside the safety authority: limit its output, monitor state validity and uncertainty, and fall back to the last validated nominal controller. Never let online learning edit the canonical asset or calibration silently.

Version the base model, residual model, data window, update rule, bounds, and enable state. Run shadow-mode comparison first. Test distribution shift, sensor dropout, stale timing, saturation, contact transitions, and restart. Require a bounded improvement on predeclared held-out metrics without regression on safety metrics. If the adapter changes after deployment, that is a new release candidate.

Regression tests should include asset invariants, FK frame poses, joint direction and limits, zero-gravity/gravity settling, single-joint step and frequency response, held-out multijoint motion, TCP accuracy, collision distances, representative contact, sensor frame/timing, and task replay. Store golden traces with tolerances and provenance, not screenshots. A dependency, simulator, mesh, controller, firmware, payload, calibration, or fitted-parameter change invalidates the affected subset and triggers it again.

9. A practical low-gap program

Keep asset, calibration, fit, controller, and validation IDs together. A dataset or policy must record that tuple. When the physical hand, fingertip, camera mount, cable routing, payload, firmware, or table changes, consult the dependency map and invalidate the relevant calibrations/tests. “Same URDF” does not mean same system.

10. Failure diagnosis and bounded Codex prompts

Use Codex to scaffold evidence, not to authorize motion:

Read the URDF, meshes, controller/transmission configuration, and vendor documentation.
Do not edit files or connect hardware. Produce a machine-checkable invariant report for
tree topology, units, joint axes/signs/zeros/limits, mimic/coupling, transmissions,
visual/collision meshes, mass/COM/inertia plausibility, frames, and actuator semantics.
List each unknown with the exact source or bounded fake/simulation test needed.

Compare this normalized URDF, imported USD report, and compiled MJCF report read-only.
Build a semantic-loss matrix for DOFs, frame FK at named poses, limits, drives, mimic,
tendons/constraints, contacts, sensors, and plugins. Generate simulator-only invariant
tests and golden artifacts. Do not infer equivalence from matching names or appearance.

Given the qualified engineer's approved limits, logged signals, task frequency band,
payloads, and stop plan, draft a staged identification experiment. Separate clock/delay,
encoder bias, gravity/payload, inertia/armature, friction, torque-current/saturation, and
closed-loop gains. Include train/held-out excitation, synchronization, metadata, physical
constraints, residual plots, and abort criteria. Do not send commands or choose safety limits.

Audit paired real/sim logs. Verify versions and time alignment; calculate per-joint and TCP
time-domain residuals, current/torque errors when genuinely measured, contact/task metrics,
and supported frequency response. Slice residuals by configuration, speed, direction, load,
temperature, and contact. Return an error budget and discriminating next tests; do not tune
on held-out trials or widen randomization to hide structural errors.

11. Evidence boundaries and disagreements

Official NVIDIA, OpenUSD, and MuJoCo documents establish format and simulator semantics, not fidelity to a particular robot. Classical calibration and identification papers establish methods and limitations, not acceptance thresholds for this cell. Manufacturer values are priors unless independently validated. All product/software status is current only at the 2026-07-14 cutoff.

Identification versus randomization is not an either/or doctrine. Identification is valuable when safe excitation and informative measurements exist; randomization covers measured variation and residual uncertainty. Underidentified contact or proprietary low-level control may make a distribution more honest than a single parameter vector. The disagreement is resolved by held-out task evidence, not simulator preference.

Likewise, a simulator fit is conditional. Multiple parameter combinations can match one trajectory. Contact solver parameters may compensate for geometry; inertia may compensate for delay; hand–eye may compensate for timestamps. Physical consistency, diverse excitation, independent measurements, held-out configurations, and frequency-domain checks reduce but do not eliminate this ambiguity.

Safety limitations remain. Identification motion can encounter limits, resonance, unexpected contact, overheating, or unstable gains. This chapter does not provide universal excitation amplitudes, forces, currents, frequencies, or pass thresholds. A qualified local owner must approve bounds and stops. Safety standards and manufacturer procedures remain authoritative.

12. Final capability checklist and series bridge

• [ ] The immutable source asset, normalized asset, USD, and MJCF realizations have digests.
• [ ] Topology, units, axes, signs, zeros, limits, frames, collision, mass/inertia, coupling, transmissions, and command semantics are audited.
• [ ] Every conversion has a semantic-loss matrix and FK/DOF/limit regression tests.
• [ ] Joint-zero, base/world, TCP, camera intrinsics, hand–eye, and fixtures have separate records and held-out residuals.
• [ ] Clocks, delay, filters, controller mode, rates, payload, temperature, and safety events are logged.
• [ ] Identification is staged; fitted and held-out excitations are separated; physical consistency and uncertainty are recorded.
• [ ] Free-space, contact, sensor, and task metrics have project-set acceptance thresholds.
• [ ] PACE is used as legged-system methodology evidence, not a quantitative manipulator promise.
• [ ] Randomization ranges arise from measured nominal uncertainty and retain correlations.
• [ ] Residual/online adaptation has bounds, shadow mode, fallback, versioning, and regression gates.
• [ ] Every demonstration, policy, and result names its asset–calibration–fit–controller tuple.

With this checklist, the reader can receive a custom URDF, make auditable simulator realizations, calibrate the physical cell, identify task-relevant dynamics and contact, and demonstrate where simulation agrees or fails. #S12 can now study RL without treating unidentified physics as “randomization.” #S13 can study VLA and world models with explicit camera, timing, action, and embodiment semantics. The digital twin is not finished forever; it is a tested release with a known error budget.

Annotated research trail

These sources deepen calibration, identification, and measured sim-to-real transfer. They are grouped by the assumption or experiment to inspect, rather than used as a list of borrowed success rates. Read each result within its platform and protocol.

References

1. NVIDIA (2026a). URDF Importer Extension. Official Isaac Sim documentation.
2. NVIDIA (2026b). Import a URDF. Official Isaac Sim documentation.
3. NVIDIA (2026c). Export to URDF. Official Isaac Sim documentation.
4. OpenUSD (2026). UsdPhysics. Official specification documentation.
5. MuJoCo (2026a). MJCF XML Reference. Official documentation.
6. MuJoCo (2026b). DC Motor Model. Official technical note.
7. Murray, R., Li, Z., & Sastry, S. (1994). A Mathematical Introduction to Robotic Manipulation. Author-hosted book.
8. Hayati, S., & Mirmirani, M. (1985). Geometric Approach for Robotic Calibration. DOI: 10.1109/ROBOT.1985.1087372.
9. Tsai, R., & Lenz, R. (1989). A New Technique for Fully Autonomous and Efficient 3D Robotics Hand/Eye Calibration. DOI: 10.1109/70.34770.
10. Park, F., & Martin, B. (1994). Robot Sensor Calibration: Solving AX=XB on the Euclidean Group. DOI: 10.1109/70.326576.
11. Zhang, Z. (2000). A Flexible New Technique for Camera Calibration. DOI: 10.1109/34.888718.
12. Daniilidis, K. (1999). Hand-Eye Calibration Using Dual Quaternions. DOI: 10.1177/02783649922066213.
13. Liu, et al. (2024). Unified Robot-World and Hand-Eye Calibration. DOI: 10.1108/RIA-06-2023-0076.
14. Ulrich, M., & Steger, C. (2024). Hand-Eye Calibration with Uncertainty. DOI: 10.1109/TRO.2023.3330609.
15. Atkeson, C., An, C., & Hollerbach, J. (1986). Estimation of Inertial Parameters of Manipulator Loads and Links. DOI: 10.1177/027836498600500306.
16. Gautier, M. (1991). Identifying the Minimum Dynamic Parameters of Robots. DOI: 10.1109/ROBOT.1991.131896.
17. Swevers, J., et al. (1997). Excitation Trajectories for Identification of Base Inertial Parameters. DOI: 10.1177/027836499701600306.
18. Wensing, P., Kim, S., & Slotine, J.-J. (2018). Linear Matrix Inequalities for Physically Consistent Inertial Parameter Identification. DOI: 10.1109/TRO.2017.2769099.
19. Janot, A., Vandanjon, P.-O., & Gautier, M. (2014). Identification of Robots in Closed Loop. DOI: 10.1109/TRO.2014.2319567.
20. Oaki, J., et al. (2026). Robot Dynamics Identification. arXiv:2605.15949.
21. Armstrong-Hélouvry, B., Dupont, P., & Canudas de Wit, C. (1994). A Survey of Friction Models and Compensation90209-7). DOI: 10.1016/0005-1098(94)90209-7.
22. Canudas de Wit, C., et al. (1995). A New Model for Control of Systems with Friction. DOI: 10.1109/9.376053.
23. Bjelonic, M., et al. (2025). PACE: Physics-Informed Automated System Identification and Controller Evolution. arXiv:2509.06342.
24. Peng, X., et al. (2018). Sim-to-Real Transfer of Robotic Control with Dynamics Randomization. DOI: 10.1109/ICRA.2018.8460528.
25. Ramos, F., et al. (2019). BayesSim. DOI: 10.15607/RSS.2019.XV.029.
26. Tiboni, G., et al. (2024). DoRoThEA. ICLR 2024.
27. Memmel, M., et al. (2024). ASID. OpenReview.
28. Hogan, N. (1985). Impedance Control: Part I. DOI: 10.1115/1.3140702.
29. Tobin, J., et al. (2017). Domain Randomization for Transferring Deep Neural Networks. arXiv:1703.06907.