Robot and articulation configuration
A jointed robot is represented as an articulation in Isaac Lab. This guide covers reusing
an existing robot configuration and authoring a new ~assets.ArticulationCfg.
The ~assets.ArticulationCfg is a configuration object that defines the
properties of an ~assets.Articulation in Isaac Lab.
While we only cover the creation of an ~assets.ArticulationCfg in this guide,
the process is similar for creating any other asset configuration object.
Reusing a robot configuration
Maintained robot configurations live in source/isaaclab_assets/isaaclab_assets/robots.
Import a configuration from isaaclab_assets and copy it before changing its spawn
properties, initial state, or actuators. Keep project-specific configurations in a Python
module in your own project; they do not need to be added to Isaac Lab.
Import clone and replace from isaaclab.utils. For example,
robot_cfg = clone(CARTPOLE_CFG) creates an independent configuration.
Use replace(robot_cfg, prim_path="{ENV_REGEX_NS}/Robot") when adding it to an
~scene.InteractiveSceneCfg. The physics backend is selected separately from
this robot configuration, as explained below.
We will use the Cartpole example to demonstrate how to create an ~assets.ArticulationCfg.
The Cartpole is a simple robot that consists of a cart with a pole attached to it. The cart
is free to move along a rail, and the pole is free to rotate about the cart. The file for this configuration example is
source/isaaclab_assets/isaaclab_assets/robots/cartpole.py.
Choosing shared and backend-specific settings
Use the shared ~assets.ArticulationCfg for the robot’s initial state and actuators.
The simulation selects the physics backend separately.
For common USD properties, use classes from isaaclab.sim.schemas, such as
~sim.schemas.RigidBodyBaseCfg and ~sim.schemas.ArticulationRootBaseCfg.
Use isaaclab_physx.sim.schemas.Physx*Cfg for PhysX tuning and
isaaclab_newton.sim.schemas.Newton*Cfg / Mujoco*Cfg for Newton and MJWarp-specific
settings. The Schema Configuration Classes guide explains the available classes and their USD namespaces;
../concepts/schema_fragments shows how to author both backends’ attributes
in one spawn configuration.
The Cartpole below uses the compatibility names RigidBodyPropertiesCfg and
ArticulationRootPropertiesCfg. Its PhysX solver iterations and sleep thresholds do not
configure Newton’s solver. When adapting it to Newton, retain the shared initial-state and
actuator configuration and configure the Newton solver separately. For example, to override
Newton’s self-collision setting:
See solver_tuning_mjwarp for solver settings, prepare_asset_for_newton for asset tuning, and Multi-backend assets for converted USD variants.
Defining the spawn configuration
As explained in Spawning prims into the scene tutorials, the spawn configuration defines the properties of the assets to be spawned. This spawning may happen procedurally, or through an existing asset file (e.g. USD or URDF). In this example, we will spawn the Cartpole from a USD file.
When spawning an asset from a USD file, we define its ~sim.spawners.from_files.UsdFileCfg.
This configuration object takes in the following parameters:
~sim.spawners.from_files.UsdFileCfg.usd_path: The USD file path to spawn from~sim.spawners.from_files.UsdFileCfg.rigid_props: The properties of the articulation’s rigid-body links~sim.spawners.from_files.UsdFileCfg.articulation_props: The properties of the articulation root
The last two parameters are optional. If not specified, they are kept at their default values in the USD file.
To import articulation from a URDF file instead of a USD file, you can replace the
~sim.spawners.from_files.UsdFileCfg with a ~sim.spawners.from_files.UrdfFileCfg.
For more details, please check the API documentation.
Defining the initial state
Every asset requires defining their initial or default state in the simulation through its configuration. This configuration is stored into the asset’s default state buffers that can be accessed when the asset’s state needs to be reset.
The initial state of an asset is defined w.r.t. its local environment frame. This then needs to be transformed into the global simulation frame when resetting the asset’s state. For more details, please check the Interacting with an articulation tutorial.
For an articulation, the ~assets.ArticulationCfg.InitialStateCfg object defines the
initial state of the root of the articulation and the initial state of all its joints. In this
example, we will spawn the Cartpole at the origin of the XY plane at a Z height of 2.0 meters.
Meanwhile, the joint positions and velocities are set to 0.0.
Defining the actuator configuration
Actuators are a crucial component of an articulation. Through this configuration, it is possible to define the type of actuator model to use. We can use the internal actuator model provided by the physics engine (i.e. the implicit actuator model), or use a custom actuator model which is governed by a user-defined system of equations (i.e. the explicit actuator model). For more details on actuators, see Actuators.
The cartpole’s articulation has two actuators, one corresponding to its each joint:
cart_to_pole and slider_to_cart. We use two different actuator models for these actuators as
an example. However, since they are both using the same actuator model, it is possible
to combine them into a single actuator model.
Newton resolves the target mode of joints configured with
~isaaclab.actuators.ImplicitActuatorCfg before solver construction:
stiffness-only selects position mode, damping-only velocity mode, both gains
combined position/velocity mode, and zero gains effort mode. A gain of
None retains the imported USD value; explicit actuator configurations use
effort mode. Zero-gain USD drives therefore need no placeholder solely for a
configured actuator. See Importing a New Asset for when
isaaclab.sim.schemas.JointDrivePropertiesCfg.ensure_drives_exist
remains useful.
ActuatorCfg velocity/effort limits considerations
Use the following fields in an actuator configuration. They select joints and are resolved when the
articulation is constructed; the canonical runtime values live on
~isaaclab.assets.ArticulationData. See Joint and actuator property ownership for the
ownership model and runtime mutation paths.
Solver velocity enforcement is backend-dependent. joint_velocity_limit records the requested
joint state but is not a backend-independent safety clamp; see Validate actuators and limits.
USD vs. ActuatorCfg discrepancy resolution
USD having default value and the fact that ActuatorCfg can be specified with None, or a overriding value can sometime be confusing what exactly gets written into simulation. The resolution follows these simple rules,per joint and per property:
Digging into USD can sometime be unconvinent, to help clarify what exact value is written, we designed a flag
isaaclab.assets.ArticulationCfg.actuator_value_resolution_debug_print,
to help user figure out what exact value gets used in simulation.
Whenever an actuator parameter is overridden in the user’s ActuatorCfg (or left unspecified), we compare it to the value read from the USD definition and record any differences. For each joint and each property, if unmatching value is found, we log the resolution:
-
USD Value The default limit or gain parsed from the USD asset.
-
ActuatorCfg Value The user-provided override (or “Not Specified” if none was given).
-
Applied The final value actually used for simulation: if the user didn’t override it, this matches the USD value; otherwise it reflects the user’s setting.
This resolution info is emitted as a warning table only when discrepancies exist. Here’s an example of what you’ll see:
To keep the cleaniness of logging, isaaclab.assets.ArticulationCfg.actuator_value_resolution_debug_print
default to False, remember to turn it on when wishes.
Example: configure and run two robots
The runnable example scripts/tutorials/01_assets/add_new_robot.py contrasts a minimal
Jetbot configuration with a more detailed Dofbot configuration. Start with an imported USD
asset (see import_new_asset) and define its spawn properties and actuators. Jetbot
retains the joint gains authored in the USD by setting stiffness and damping to None.
Both fields must be specified, even when using these USD defaults:
Dofbot additionally sets initial joint positions, groups joints by name, and specifies
actuator gains and limits. Its solver iterations and maximum depenetration velocity are
PhysX-specific; use Choosing shared and backend-specific settings when adapting these properties to Newton.
The keys in init_state.joint_pos identify USD joints, not actuator groups. Joint names can
be matched with regular expressions; for example, .* selects all joints.
The example adds both configurations to an InteractiveSceneCfg, assigns each robot a
path under every environment, and constructs the scene. Its loop resets root and joint
states, sets joint targets, writes commands, steps physics, and updates the scene buffers.
See Using the Interactive Scene for scene construction and
Interacting with an articulation for the reset and control loop.
Run the example in the Isaac Sim viewport:
This example uses PhysX physics and requires Isaac Sim. The Dofbot gripper is not actuated
in this example, so a warning about unconfigured joints is expected. Stop the example with Ctrl+C.
