PACE: learning actuator parameters instead of guessing them for sim-to-real

The parameter guess that ruins a sim-to-real transfer

When a policy trained in simulation walks badly on hardware, the usual suspects are the physics parameters rather than the policy. Actuator dynamics, joint friction, command delay: the simulator has to be told what the motor actually does, and if those numbers are wrong the learned behaviour is wrong with them.

PACE attacks that specific problem. The project description calls it a systematic approach for sim-to-real transfer of legged robots, identifying actuator and joint dynamics with standard joint encoders. The README expands on it: PACE is a framework for sim-to-real transfer of diverse robotic systems, combining data-driven system identification with evolutionary optimization, and it enables accurate actuator modelling and a closer match between simulation and reality by explicitly learning physically meaningful dynamics parameters.

The name spells out the method. PACE stands for Precise Adaptation through Continuous Evolution, and the three bullet points in the README give the pipeline: estimate actuator and joint dynamics directly from measured data, use CMA-ES for parameter optimization, and apply the learned parameters to improve sim-to-real locomotion performance.

That is a different philosophy from the one most simulation stacks start with. Instead of randomizing a parameter over a range and hoping the policy tolerates the whole range, you measure the system and fit a specific value. The README also notes that the framework supports multiple robot platforms and actuator types, and the repository carries an example for ANYmal D.

The audience is robotics researchers and engineers working on legged locomotion, and specifically people who already use a simulator. That last point is not incidental, since the framework is designed to integrate with NVIDIA Isaac Lab and to follow its task and environment conventions.

CMA-ES over physically meaningful parameters

The optimizer choice is what gives the framework its name. CMA-ES, covariance matrix adaptation evolution strategy, is a derivative-free optimizer that works well on continuous parameter spaces where the objective surface is noisy and the gradient is unavailable, which is exactly the situation when the objective is a simulation that has to be run many times.

Running a physics simulation thousands of times is expensive, so the fitness of a parameter set has to be something you can compute cheaply and repeatedly. CMA-ES handles that by keeping a population of candidate parameter vectors and updating a search distribution between generations, which is a reasonable match for a fitness that comes from a rollout.

The README's usage snippet shows the three things a custom project imports. PaceCfg and PaceSim2realEnvCfg are configuration objects, CMAESOptimizer is the optimizer, and PaceDCMotorCfg with PaceDCMotor comes from the utils namespace. The motor classes are the point of contact with the hardware model: a DC motor is the actuator type the identification is centred on, and the configuration object is where a real motor's parameters enter the simulator.

One more import matters more than it looks:

from pace_sim2real import PaceCfg, PaceSim2realEnvCfg, CMAESOptimizer
from pace_sim2real.utils import PaceDCMotorCfg, PaceDCMotor
import pace_sim2real.tasks  # registers environments

Importing the tasks module registers the environments. That is an Isaac Lab convention rather than a PACE invention, and it is the clearest sign of how tightly the framework is coupled to the host simulator. Environments become available because an import happened, not because you registered them explicitly.

What the Isaac Lab coupling actually requires

PACE is not a standalone package. The README's installation section starts with installing Isaac Lab from the official guide, and recommends the conda or uv installation method because it simplifies running Python scripts from the terminal and managing dependencies.

The PACE repository itself is installed separately, outside the IsaacLab directory, in editable mode, using an interpreter that already has Isaac Lab available:

# Use 'PATH_TO_isaaclab.sh|bat -p' instead of 'python'
# if Isaac Lab is not installed in a Python venv or conda environment
python -m pip install -e source/pace_sim2real

The version constraint is the part to notice. PACE is developed and tested against Isaac Sim 5.0 with the latest Isaac Lab, and the README recommends Isaac Sim 5.0 or newer. On older versions such as Isaac Sim 4.5 you may see warnings like these:

Setting joint viscous friction coefficients are not supported in Isaac Sim < 5.0
Setting joint dynamic friction coefficients are not supported in Isaac Sim < 5.0

The README is careful about what those warnings mean. The examples may still run, but certain physics properties, joint viscous and dynamic friction among them, are not supported by the older simulator, so the physical fidelity and the sim-to-real accuracy are reduced.

That is a significant caveat for a framework whose entire purpose is identifying exactly those parameters. On a simulator that cannot represent the friction terms, the identification target is partially missing, and the README frames versions below 5.0 as legacy support with limitations rather than a supported configuration.

Running the ANYmal D example end to end

The documented example has three moving parts: activate the environment, collect excitation data, then fit parameters. The README notes that the chirp data comes from simulation, and that you can instead place your own real-world data in the data/ directory, which is the point of the whole exercise.

Activate the Isaac Lab environment and move into the repository:

conda activate <isaaclab_env>
cd path/to/pace-sim2real

Then collect the excitation data:

python scripts/pace/data_collection.py

The result is stored as data/anymal_d_sim/chirp_data.pt. A chirp signal is the natural excitation for identification because it sweeps through a range of frequencies, which is what lets the fit separate different dynamic effects rather than a single operating point.

Fitting comes next:

python scripts/pace/fit.py

That step estimates the actuator and joint parameters using CMA-ES and writes into logs/pace/anymal_d_sim/. The separation between the two stages is a useful property: data collection is the expensive, hardware-touching part, and it is done once, while the fit can be repeated with different optimizers or objectives without going back to the robot.

The documentation site is published at pace.filipbjelonic.com and is built with MkDocs using the Material for MkDocs theme, so the deeper details on the identification method, the configuration options and the parameter sets lives outside the repository.

What changed in v0.2.0, and what is still unsettled

There is one release so far, v0.2.0, published on 2026-10-13, and its title is the most informative line in the repository: Command delay and static/dynamic friction.

That tells you what the maintainers considered missing. Command delay is the gap between when the controller sends a position or torque command and when the joint actually moves, which is invisible to a simulator that applies commands instantly. Static and dynamic friction are the two components that govern whether a foot grips or slips. All three are exactly the kind of quantity you cannot guess and have to measure, which is consistent with the project thesis.

The version number is the other signal. A project at 0.2.0 with a single release, and the README's own warning that PACE is under active development and that APIs may evolve as the framework matures, tells you that interfaces will change. The repository structure reflects a young framework: source for the extension package, scripts for the example pipeline, docs for the site, mkdocs.yml for its build, and a .flake8 plus a pre-commit configuration for linting.

That last part is worth a moment, because the README gives the exact commands:

pip install pre-commit

pre-commit install

and pre-commit run --all-files to check everything at once. For contributors this means formatting is handled by hooks rather than by review comments.

If you are evaluating the framework for a deadline-bound project, treat the moving API as a real cost. If you are evaluating it for a research programme, the churn is expected and the maintainers are named.

Friction, friction again, and the limits of the offline loop

Reading the README as a whole surfaces two structural limits.

The first is that the identification loop needs real data, and the README's example collects chirp data in simulation and stores it in data/anymal_d_sim/. If your goal is to improve the sim-to-real gap, the meaningful dataset is the one measured on the robot, and the framework expects you to place it in data/ instead. That is a hardware dependency with scheduling attached: you need the robot, a safe excitation routine, and a place to keep the recordings. The chirp excitation is not trivial to run on a physical machine, since it deliberately drives the joints through a range of frequencies.

The second is the dependency on the simulator version, discussed above, and its consequence for friction specifically. A framework built around identifying friction and delay is only as good as the simulator's ability to represent those effects. The README is explicit that on Isaac Sim below 5.0 the joint viscous and dynamic friction coefficients are not supported, so the older simulator cannot be used to check whether the identified friction was right.

A third, quieter limitation is the coupling to Isaac Lab itself. Environments are registered on import, the configuration objects follow Isaac Lab conventions, and installation assumes an Isaac Lab installation exists with a matching interpreter. If you evaluate this framework, evaluate it inside Isaac Lab, because a port would be a port of the whole design.

None of this is a criticism of the approach. It is a description of the boundaries: a well-scoped identification framework, coupled to one simulator, requiring hardware data to be worth anything.

Licence, citation and the editor friction

The licence is Apache License 2.0, with the copyright line reading 2025 ETH Zurich, Robotic Systems Lab, Filip Bjelonic, and a NOTICE file alongside the LICENSE. Apache 2.0 permits use in commercial and research work and includes an explicit patent grant, which for a research framework that might end up in a product pipeline is a useful property. This is not legal advice, and the NOTICE file is worth reading for the attribution terms it carries.

The project asks that you cite the paper if you use it in research. The citation points at the International Journal of Robotics Research, with a DOI of 10.1177/02783649261459628, and an open-access version on arXiv at 2509.06342. The authors listed are Filip Bjelonic, Florian Tischhauser and Marco Hutter.

The maintainers are Filip Bjelonic, René Zurbrügg and Oliver Fischer, all from the Robotic Systems Lab at ETH Zurich, and they are described as responsible for reviewing contributions, managing issues and guiding the technical direction. The repository is not archived and the last push was on 2026-10-19, one day before the current release notes describe the project as actively maintained.

One practical note belongs to anyone using VS Code. The troubleshooting section explains that in some VS Code versions, indexing for Isaac Lab extensions may be incomplete, and the fix is to add the extension path to .vscode/settings.json:

{
  "python.analysis.extraPaths": [
    "<path-to-ext-repo>/source/pace_sim2real"
  ]
}

A second entry handles Pylance crashes caused by excessive indexing, by excluding unused Omniverse packages such as the omni.anim, omni.kit, omni.graph and omni.services paths under the Isaac Sim extscache directory. If your editor runs out of memory while you work on a robot project, that is the setting to change.

Editorial conclusion

Adopt PACE if your team already works in NVIDIA Isaac Lab, has real robot data or a way to collect it, and needs actuator and joint parameters rather than hand-tuned guesses to close the sim-to-real gap on a legged platform. Do not adopt it if you are looking for a standalone simulator or a general reinforcement learning framework, since the package is installed as an Isaac Lab extension and registers its own environments. Before you build a pipeline on it, run the data collection and fit steps for one platform and check the fitted parameters against the hardware you actually own, because the project states it is under active development and that APIs may evolve as the framework matures.

Frequently asked questions

Official sources

1. leggedrobotics/pace-sim2real on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases