diff --git a/content/learning-paths/laptops-and-desktops/dgx_spark_isaac_robotics2/1_7dof_robot_arm.md b/content/learning-paths/laptops-and-desktops/dgx_spark_isaac_robotics2/1_7dof_robot_arm.md new file mode 100644 index 0000000000..72305cb0b1 --- /dev/null +++ b/content/learning-paths/laptops-and-desktops/dgx_spark_isaac_robotics2/1_7dof_robot_arm.md @@ -0,0 +1,279 @@ +--- +title: Manipulate Objects with a 7-DOF Robot Arm +weight: 2 + +### FIXED, DO NOT MODIFY +layout: learningpathall +--- + +## From locomotion to interaction + +Use the installation instructions in the previous [Learning Path](https://learn.arm.com/learning-paths/laptops-and-desktops/dgx_spark_isaac_robotics/)to installed and run [Isaac Sim](https://developer.nvidia.com/isaac/sim) and [Isaac Lab](https://developer.nvidia.com/isaac/lab) on an Arm-based [DGX Spark](https://www.nvidia.com/en-gb/products/workstations/dgx-spark/) system. + +{{% notice IsaacLab API versions %}} + +As of July 2026, support for **IsaacSim 6.0.0 and later** through IsaacLab is still in beta. For the most stable experience with this learning path, use **IsaacLab 2.3.2** with **IsaacSim 5.1.0**. + +Before installing, verify that your chosen **IsaacLab** version is compatible with **IsaacSim** using the version compatibility table in the IsaacLab [README.md](https://github.com/isaac-sim/IsaacLab/blob/main/README.md). If you choose different versions, follow the compatibility table rather than assuming that the latest IsaacLab and IsaacSim releases work together. + +The command examples provide tabs for both the **IsaacLab 2.3 API** and the **IsaacLab 3.0 API**. The IsaacLab 3.0 commands are included for future-proofing as support for IsaacSim 6.0.0 and later matures. They use the use the unified `train` and `play` entry points described in the [IsaacLab 3.0 Migration Guide](https://isaac-sim.github.io/IsaacLab/develop/source/migration/migrating_to_isaaclab_3-0.html). + +Additionally, IsaacLab 3.0.0 and newer require **Python 3.12 or later** to build and install all required Python packages. You may need to upgrade your system Python version before continuing. + +{{% /notice %}} + + +In this section, you move from locomotion to manipulation. You will train a simulation model of the [Franka 3](https://franka.de/franka-research-3) robotic arm with 7 Degrees-of-freedom (DOF) on two tasks: + +* **Reach** - to build spatial control of the arm's end effector, the part that interacts with the environment. +* **Lift** - to further add contact, grasping, and stable object motion. + +This workflow also shows how DGX Spark maps work across CPU and GPU resources. DGX Spark provides 128 GB of coherent unified LPDDR5X memory shared by the Arm CPUs (10 Cortex-X925 and 10 Cortex-A725 cores) and the Blackwell GPU, so CPU and GPU can work on the same data without separate host-to-device copies. That can reduce startup overhead, and the unified memory pool can scale to whichever side of the workload needs more memory at a given point. + + +## Task 1: Reach — Building Spatial Awareness + +The Reach task trains the Franka arm to move its end-effector to a randomly sampled target pose. This is your first manipulation baseline because it teaches position control before adding grasping. + +### Run + +Use your existing Isaac Lab setup from the previous Learning Path, then run: + +{{< tabpane code=true >}} +{{< tab header="IsaacLab 2.3 API" >}} +cd ~/IsaacLab + +# Improve runtime compatibility on aarch64 systems +export LD_PRELOAD="$LD_PRELOAD:/lib/aarch64-linux-gnu/libgomp.so.1" + +./isaaclab.sh -p scripts/reinforcement_learning/rsl_rl/train.py \ + --task=Isaac-Reach-Franka-v0 \ + --headless \ + --num_envs=2048 +{{< /tab >}} +{{< tab header="IsaacLab 3.0 API" >}} +cd ~/IsaacLab + +# Improve runtime compatibility on aarch64 systems +export LD_PRELOAD="$LD_PRELOAD:/lib/aarch64-linux-gnu/libgomp.so.1" + +./isaaclab.sh train \ + --rl_library rsl_rl \ + --task=Isaac-Reach-Franka-v0 \ + --viz none \ + --num_envs=2048 +{{< /tab >}} +{{< /tabpane >}} + + + +This training flow uses the **RSL-RL PPO** algorithm. The PPO hyperparameters and actor/critic network sizes are defined in the task config file at `source/isaaclab_tasks/isaaclab_tasks/manager_based/manipulation//config/franka/agents/rsl_rl_ppo_cfg.py`. + +In these config files, the example PPO model sizes are: + +* Reach actor and critic: `[64, 64]` +* Lift actor and critic: `[256, 128, 64]` + +The default training iterations are: + +* Reach: `1000` iterations +* Lift: `1500` iterations + +Training the simple reach task on the DGX Spark will take approximately 10 minutes. + + +### What this script controls + +This command does more than start training. The Python entry point controls: + +* which task configuration is loaded +* which RL training entry point is used +* runtime behavior such as headless execution and the number of environments + +In Isaac Lab, an **environment** is one simulated instance of the task. For example, one environment includes one Franka arm, one target, and one physics rollout. When you set `--num_envs=2048`, Isaac Lab runs 2048 instances in parallel to scale to the GPU capacity available. Proximal policy optimization (PPO) then uses trajectories from all environments to update the actor and critic networks each iteration converging quicker to an optimal solution compared to a single environment. + + +### Task structure + +* **Goal**: Move the end-effector of the Franka 7-DOF arm to a randomly sampled target pose. +* **Observation space**: Joint positions, joint velocities, and target position. +* **Action space**: Joint position targets. + +### Verify + +After training, run the following command to observe the learned policy in simulation, replace the `--checkpoint` with the PyTorch model file for your desired iteration. We are limiting the number of environments to 2 simply to allow the simulation to load faster but you can increase to observe multiple instances: + +{{< tabpane code=true >}} +{{< tab header="IsaacLab 2.3 API" >}} +./isaaclab.sh -p scripts/reinforcement_learning/rsl_rl/play.py \ + --task=Isaac-Reach-Franka-Play-v0 \ + --num_envs=2 \ + --checkpoint=logs/rsl_rl/franka_reach//model_.pt +{{< /tab >}} +{{< tab header="IsaacLab 3.0 API" >}} +./isaaclab.sh play \ + --rl_library rsl_rl \ + --task=Isaac-Reach-Franka-Play-v0 \ + --num_envs=2 \ + --checkpoint=logs/rsl_rl/franka_reach//model_.pt +{{< /tab >}} +{{< /tabpane >}} + +{{% notice Tip %}} + +To inspect the Franka arm, right-click in the viewport and use `W`, `A`, `S`, and `D` to fly the camera. These are standard industry viewport navigation controls used in many 3D tools. + +{{% /notice %}} + +![Franka Reach training comparison that shows early and late policy behavior. The left side shows less stable motion around iteration 100, and the right side shows improved target tracking near iteration 999.#center](./reach.gif "Franka reach training comparison that shows early and late policy behavior. The left side shows less stable motion around iteration 100, and the right side shows improved target tracking near iteration 999") + +You should observe the following: + +* The robotic arm can consistently move its end-effector to the target position. +* Multiple environments execute the reaching behavior in parallel. +* The policy no longer shows obvious random oscillation or unstable motion. + +### Why it matters on Arm + +The coherent unified memory lets you quickly start and stop training with little data transfer overhead and flexibly scale memory for large environments. The Arm CPU orchestrates training, enabling rapid experimentation and iteration. + + +## Task 2: Lift — balancing force and precision + +Once the robot can reach reliably, the next step is physical interaction. In the Lift task, you train the arm to grasp a cube on the table and lift it to a target height. The policy must coordinate approach, alignment, gripper closure, and stable lifting under contact and gravity. Run the following command to train the `Isaac-Lift-Cube-Franka-v0` task with the PPO algorithm from the `rsl_rl` library. + +{{< tabpane code=true >}} +{{< tab header="IsaacLab 2.3 API" >}} +./isaaclab.sh -p scripts/reinforcement_learning/rsl_rl/train.py \ + --task=Isaac-Lift-Cube-Franka-v0 \ + --headless \ + --num_envs=2048 +{{< /tab >}} +{{< tab header="IsaacLab 3.0 API" >}} +./isaaclab.sh train \ + --rl_library rsl_rl \ + --task=Isaac-Lift-Cube-Franka-v0 \ + --viz none \ + --num_envs=2048 +{{< /tab >}} +{{< /tabpane >}} + +{{% notice Please Note %}} + +After an initial run, the end-effector might still fail to lift consistently. To continue training from a checkpoint rerun with the additional arguments shown below: + +{{< tabpane code=true >}} +{{< tab header="IsaacLab 2.3 API" >}} +./isaaclab.sh -p scripts/reinforcement_learning/rsl_rl/train.py \ + --task=Isaac-Lift-Cube-Franka-v0 \ + --headless \ + --num_envs=2048 \ + --resume \ + --experiment_name=franka_lift \ + --load_run= \ + --checkpoint=model_.pt \ + --max_iterations= +{{< /tab >}} +{{< tab header="IsaacLab 3.0 API" >}} +./isaaclab.sh train \ + --rl_library rsl_rl \ + --task=Isaac-Lift-Cube-Franka-v0 \ + --viz none \ + --num_envs=2048 \ + --resume \ + --experiment_name=franka_lift \ + --load_run= \ + --checkpoint=model_.pt \ + --max_iterations= +{{< /tab >}} +{{< /tabpane >}} + +Use the run folder format `YYYY-MM-DD_HH-MM-SS` for `--load_run` (note the underscore between date and time), for example `2026-05-15_09-24-13`. + +{{% /notice %}} + +The training log prints a **learning-iteration summary** each cycle. Watch `Episode_Reward/lifting_object` to assess whether the policy is learning to lift the cube without the needing to explicitly run a visual simulation of the model. You can see jumps and plateaus during PPO training, so short flat periods are normal. Use the broader trend across many iterations, together with ETA, to decide whether to keep training. + +```output +################################################################################ + Learning iteration 902/2650 + + Total steps: 37011456 + Steps per second: 68548 + Collection time: 0.600s + Learning time: 0.117s + Mean value loss: 2.1550 + Mean surrogate loss: -0.0023 + Mean entropy loss: 7.1831 + Mean reward: 79.76 + Mean episode length: 246.64 + Mean action std: 0.64 + Episode_Reward/reaching_object: 0.7022 + Episode_Reward/lifting_object: 11.2984 + Episode_Reward/object_goal_tracking: 5.6466 +Episode_Reward/object_goal_tracking_fine_grained: 0.0891 + Episode_Reward/action_rate: -0.7642 + Episode_Reward/joint_vel: -1.4792 + Curriculum/action_rate: -0.1000 + Curriculum/joint_vel: -0.1000 + Metrics/object_pose/position_error: 0.2638 + Metrics/object_pose/orientation_error: 0.8218 + Episode_Termination/time_out: 0.9782 + Episode_Termination/object_dropping: 0.0218 +-------------------------------------------------------------------------------- + Iteration time: 0.72s + Time elapsed: 00:09:59 + ETA: 00:23:11 +``` + + +### What changes in the workflow + +Compared with Reach, you do not rebuild the project or switch platforms. You keep the same training entry point and environment, and only change `--task`. That lets you move quickly between manipulation scenarios while keeping the same workflow. + +### Verify + +After training, confirm the following: + +* The robotic arm can approach the cube and adjust its gripper position. +* The gripper closes at an appropriate time. +* The cube is lifted off the table rather than slipping away or bouncing after collision. + + +You can use the command below to verify the result. + +{{< tabpane code=true >}} +{{< tab header="IsaacLab 2.3 API" >}} +./isaaclab.sh -p scripts/reinforcement_learning/rsl_rl/play.py \ + --task=Isaac-Lift-Cube-Franka-v0 \ + --num_envs=2 \ + --checkpoint= +{{< /tab >}} +{{< tab header="IsaacLab 3.0 API" >}} +./isaaclab.sh play \ + --rl_library rsl_rl \ + --task=Isaac-Lift-Cube-Franka-v0 \ + --num_envs=2 \ + --checkpoint= +{{< /tab >}} +{{< /tabpane >}} + +![Franka 7-DOF arm progressing through Reach and Lift. The left panel shows iteration 150, where grasp stability is still developing. The right panel shows around iteration 900, where the policy keeps the end-effector inverted to reduce cube drops during lifting.#center](./reach_and_lift.gif "Franka 7-DOF arm progressing through Reach and Lift. The left panel shows iteration 150, where grasp stability is still developing. The right panel shows around iteration 900, where the policy keeps the end-effector inverted to reduce cube drops during lifting") + + +## Extended exploration: comparing different locomotion robots + +Isaac Lab also includes locomotion environments you can switch to with the same script pattern. If you want a quick comparison, run one quadruped task and one biped task to observe convergence differences. + +| Environment | Robot | Type | Terrain | Training difficulty | +|---|---|---|---|---| +| Isaac-Velocity-Flat-Unitree-Go2-v0 | Unitree Go2 | Quadruped | Flat | Easy | +| Isaac-Velocity-Rough-H1-v0 | Unitree H1 | Biped humanoid | Rough | Hard | + +Quadrupeds often converge faster because they are more statically stable. Bipeds usually need longer training because balance is harder to learn. + +## Next up + +The Franka robotic arm now has basic grasping ability. However, objects in the real world often introduce more complex mechanical constraints. + +In the next section, you will explore how a robot can interact with joint-constrained objects such as drawers, and move one step closer to high-precision industrial manipulation tasks. diff --git a/content/learning-paths/laptops-and-desktops/dgx_spark_isaac_robotics2/2_contact_rich_obj.md b/content/learning-paths/laptops-and-desktops/dgx_spark_isaac_robotics2/2_contact_rich_obj.md new file mode 100644 index 0000000000..60c3a4e67f --- /dev/null +++ b/content/learning-paths/laptops-and-desktops/dgx_spark_isaac_robotics2/2_contact_rich_obj.md @@ -0,0 +1,209 @@ +--- +title: Fine Manipulation and Contact-Rich Interaction +weight: 3 + +### FIXED, DO NOT MODIFY +layout: learningpathall +--- + +## Fine Manipulation and Contact-Rich Interaction + +In the previous section, you trained the Franka arm on the basic Reach and Lift tasks. This section continues the same Arm-based Isaac Sim / Isaac Lab workflow and moves into contact-rich manipulation: interacting with objects that include mechanical constraints, contact forces, and high precision requirements. + +In real industrial environments, a robot does more than pick up free objects. Drawers move along rails, pegs must be inserted into tight sockets, and nuts must align with bolts before threading can begin. These tasks require a policy to understand contact, constrained motion, and failure modes caused by small errors. + +This section starts with the Open-Drawer task to introduce interaction with articulated objects, and then moves into Isaac Lab's Factory environments, where you explore higher-precision industrial assembly workflows. + +## Task 1: Open-Drawer + +In this task, you train the same Franka arm to reach the drawer handle, grasp it, and pull the drawer open along its rail. Unlike the Lift task from the previous section, a drawer is an articulated object: it is made of linked parts connected by a joint, so it can move only along a defined path (the rail) instead of moving freely in any direction. The policy must handle stable contact, constrained motion, and contact forces throughout the interaction. + +### Run + +Run the training script using the `rsl_rl` library with the following command. Again this uses the proximal policy optimization (PPO) algorithm. + +{{< tabpane code=true >}} +{{< tab header="IsaacLab 2.3 API" >}} +./isaaclab.sh -p scripts/reinforcement_learning/rsl_rl/train.py \ + --task=Isaac-Open-Drawer-Franka-v0 \ + --headless \ + --num_envs=2048 +{{< /tab >}} +{{< tab header="IsaacLab 3.0 API" >}} +./isaaclab.sh train \ + --rl_library rsl_rl \ + --task=Isaac-Open-Drawer-Franka-v0 \ + --viz none \ + --num_envs=2048 +{{< /tab >}} +{{< /tabpane >}} + +{{% notice Note %}} + +Training takes longer than Reach and Lift because the drawer is an articulated object with joint constraints and contact forces. The PPO config uses a larger network (`[256, 128, 64]`), collects 96 steps per environment per iteration versus 24 for Reach. + +Training will take approximately 25 minutes on a DGX Spark. + +{{% /notice %}} + +### What makes this task harder + +The Open-Drawer task is more complex than Reach and Lift because the policy must handle multiple challenges simultaneously: stable contact between the gripper and the handle, constrained motion imposed by the drawer rail, and friction or collision errors during pulling. Unlike pure reaching, the robot must establish contact and then maintain correct interaction throughout the motion. This requires the policy to understand both position control and force feedback. + +### Verify + +After training, confirm the following: + +* The robotic arm approaches and aligns with the handle instead of stopping in front of the drawer. +* Once contact is established, the drawer moves along the rail direction. +* The opening motion remains stable without slipping, shaking, or applying force in the wrong direction. + +To view the trained policy, replace the checkpoint path with your model `.pt` file in the log directory: + +{{< tabpane code=true >}} +{{< tab header="IsaacLab 2.3 API" >}} +./isaaclab.sh -p scripts/reinforcement_learning/rsl_rl/play.py \ + --task=Isaac-Open-Drawer-Franka-v0 \ + --num_envs=1 \ + --checkpoint= +{{< /tab >}} +{{< tab header="IsaacLab 3.0 API" >}} +./isaaclab.sh play \ + --rl_library rsl_rl \ + --task=Isaac-Open-Drawer-Franka-v0 \ + --num_envs=1 \ + --checkpoint= +{{< /tab >}} +{{< /tabpane >}} + +![Drawer-opening policy progression shown side by side. The left panel shows early training (iteration 50) with slow and unstable drawer motion. The right panel shows converged policy (iteration 399) with reliable contact and smooth opening along the rail.#center](./open_drawer.gif "Drawer-opening policy progression shown side by side. The left panel shows early training (iteration 50) with slow and unstable drawer motion. The right panel shows converged policy (iteration 399) with reliable contact and smooth opening along the rail") + + +## Task 2: Factory environments — moving toward sub-millimeter precision + +To support industrial automation scenarios, Isaac Lab provides the **Factory** family of environments. In this task, you will explore high-precision assembly tasks such as peg insertion, which require sub-millimeter contact control and careful force feedback. These tasks emphasize high-fidelity contact simulation and show how precision assembly differs from general manipulation. The Factory environments use the same PPO algorithm as earlier tasks, but with hyperparameters tuned for precision control in the `rl_games` training library instead of `rsl_rl`. + +### Run + +Factory tasks use the `rl_games` training library instead of `rsl_rl`. Select the API version installed on your system: + +{{< tabpane code=true >}} +{{< tab header="IsaacLab 2.3 API" >}} +./isaaclab.sh -p scripts/reinforcement_learning/rl_games/train.py \ + --task=Isaac-Factory-PegInsert-Direct-v0 \ + --headless +{{< /tab >}} +{{< tab header="IsaacLab 3.0 API" >}} +./isaaclab.sh train \ + --rl_library rl_games \ + --task=Isaac-Factory-PegInsert-Direct-v0 \ + --viz none +{{< /tab >}} +{{< /tabpane >}} + +Training runs for the default number of epochs specified in `/source/isaaclab_tasks/isaaclab_tasks/direct/factory/agents/rl_games_ppo_cfg.yaml` under `max_epochs`. During training, you'll see output like: + +```output +fps step: 416 fps step and policy inference: 409 fps total: 337 epoch: 32/200 frames: 507904 +fps step: 408 fps step and policy inference: 401 fps total: 332 epoch: 33/200 frames: 524288 +saving next best rewards: [300.05377] +=> saving checkpoint '/home/kieran/IsaacLab/logs/rl_games/Factory/test/nn/Factory.pth' +``` + +In this output: + +* **fps step**: Simulation speed (steps per second) without inference. +* **fps step and policy inference**: Speed including policy execution overhead. +* **fps total**: Overall throughput including collection and learning. +* **epoch**: One full pass over the collected rollout batch to update the policy. +* **frames**: Cumulative transitions (state, action, reward tuples) experienced across all parallel environments. A frame represents one timestep in one environment instance, so higher frame counts mean more data for learning. + + + +{{% notice Please Note %}} + +Training this task can take up to **1 hour** on a DGX Spark. + +To skip training and use a pre-trained checkpoint from NVIDIA Omniverse, replace `--checkpoint=` with `--use_pretrained_checkpoint` in the playback command. + +A pre-trained model may not be available for every task and `IsaacLab` version tag. + +{{% /notice %}} + +## Verify + +To view a trained policy in simulation, replace the checkpoint path with your log directory or pass the `--use_pretrained_checkpoint` argument. We are also adding environment parameters to minimize the time it takes to observe the peg insertion. + + +{{< tabpane code=true >}} +{{< tab header="IsaacLab 2.3 API" >}} +./isaaclab.sh -p scripts/reinforcement_learning/rl_games/play.py \ + --task=Isaac-Factory-PegInsert-Direct-v0 \ + --checkpoint= \ + --num_envs=1 \ + --real-time \ + --seed=-1 \ + env.episode_length_s=4.0 \ + env.task.fixed_asset_init_pos_noise=[0.08,0.08,0.02] \ + env.task.hand_init_pos_noise=[0.03,0.03,0.02] +{{< /tab >}} +{{< tab header="IsaacLab 3.0 API" >}} +./isaaclab.sh play \ + --rl_library rl_games \ + --task=Isaac-Factory-PegInsert-Direct-v0 \ + --checkpoint= \ + --num_envs=1 \ + --real-time \ + --seed=-1 \ + env.episode_length_s=4.0 \ + env.task.fixed_asset_init_pos_noise=[0.08,0.08,0.02] \ + env.task.hand_init_pos_noise=[0.03,0.03,0.02] +{{< /tab >}} +{{< /tabpane >}} + +![Peg insertion simulation with sub-millimeter contact control#center](./peg.gif "Simulation of sub-millimeter control of arm to insert peg into a hole. PPO model trained to 50 epochs") + + +### What changes in the workflow + +You switched both the task and the training library quickly using the open source IsaacLab framework. This rapid iteration capability is valuable on any platform, but especially on Arm-based systems where the CPU handles orchestration while the GPU runs simulation. + +{{% notice Please Note %}} + +You can override the default behavior and run the physics engine on the CPU with `--device=cpu`. This is useful when the GPU is already heavily used or temporarily unavailable, for example when training is still running and you want to run `play.py` at the same time. GPU execution is typically faster when it is available. + +{{% /notice %}} + + +### Why these tasks matter + +Factory tasks are common in industrial automation and assembly scenarios. They are challenging because: + +* alignment tolerances are very small +* physical feedback after contact is highly sensitive +* position, orientation, and force control become tightly coupled + +For example, peg insertion requires stable alignment before insertion, while nut threading adds even more demanding pose control and rotational behavior. These tasks are usually much more sensitive to small errors than Reach, Lift, or drawer interaction. + +{{% notice Note %}} +For Factory tasks, high-fidelity contact-force simulation is essential. Whether the agent can respond to sub-millimeter physical feedback directly affects the success rate of insertion, threading, and assembly tasks. +{{% /notice %}} + +## Comparing manipulation task depth + +As tasks evolve from simple reaching to precision assembly, the technical demands increase significantly. + +| Environment | Task | Difficulty to train | Key challenge | +|---|---|---|---| +| Isaac-Reach-Franka-v0 | Reach a target pose | Easy | Learn basic inverse control through RL | +| Isaac-Open-Drawer-Franka-v0 | Open a drawer | Medium | Contact-rich manipulation with mechanical constraints | +| Isaac-Factory-NutThread-Direct-v0 | Thread a nut onto a bolt | Hard | Precise torque and pose control | + +This comparison also helps show that not all manipulation tasks are simple object relocation problems. Once a workflow includes articulated object interaction and industrial assembly, the importance of contact stability, precision, and experiment control rises quickly. + + +## Next up + +A single robotic arm can already complete more precise interactions, but more complex automation scenarios often require multiple agents working together. + +In the next section, you will move beyond single-robot operation and explore how multiple robotic agents can cooperate to complete a task. diff --git a/content/learning-paths/laptops-and-desktops/dgx_spark_isaac_robotics2/3_multiagent_policies.md b/content/learning-paths/laptops-and-desktops/dgx_spark_isaac_robotics2/3_multiagent_policies.md new file mode 100644 index 0000000000..56c9bcd1b0 --- /dev/null +++ b/content/learning-paths/laptops-and-desktops/dgx_spark_isaac_robotics2/3_multiagent_policies.md @@ -0,0 +1,149 @@ +--- +title: Multi-Agent Training +weight: 4 + +### FIXED, DO NOT MODIFY +layout: learningpathall +--- + +## From working alone to working together with MAPPO + +In the previous section, you used an Arm-based Isaac Sim / Isaac Lab environment to run single-arm manipulation and contact-rich tasks. This section continues on the same development platform and moves into **multi-agent reinforcement learning (MARL)**, where multiple agents learn to cooperate inside the same simulation. + +In real logistics centers, automated production lines, and dual-arm robotics systems, a single agent is often not enough. A task may require two hands to transfer an object, multiple controllers to stabilize a system, or several agents to coordinate under partial observation. The challenge is no longer only about controlling one robot correctly. It is about **coordination, role allocation, and shared task success**. + +In this section, you will use the **skrl** library with **MAPPO** (Multi-Agent Proximal Policy Optimization). MAPPO trains agents using a shared critic that incorporates global state information during training, while each agent still executes independently using only its own local observations at deployment. + +Isaac Lab also supports **IPPO** (Independent PPO), where each agent treats all other agents as part of the environment and learns entirely independently. IPPO works well when agents have clearly separated roles, limited interaction, or when you want to avoid the added complexity of centralized training. If you want to experiment with IPPO or explore other multi-agent environments, the [comprehensive list of Isaac Lab environments](https://isaac-sim.github.io/IsaacLab/main/source/overview/environments.html#comprehensive-list-of-environments) shows which tasks support which algorithms. + +As in the earlier section, this section also highlights how Arm-based systems enable **workflow control**. You can use Python scripts, task flags, and algorithm options to control multi-agent training flows, switch configurations, and continue running GPU-backed simulation on the same platform. + +## Shadow Hand Over — coordinated transfer between hands + +In this task, the policy must solve a classic cooperation scenario. One Shadow Hand holds an object and transfers it to the other hand. Each agent controls only its own motion but must learn to anticipate the other agent's behavior and timing from partial local observations. MAPPO is well suited for this task because the shared critic can encourage coordinated behavior during training, even though each hand uses only local observations during execution. + +### Run + +You'll now use the **skrl** library for multi-agent training. Pass the `--algorithm` flag to select MAPPO for this task: + +{{< tabpane code=true >}} +{{< tab header="IsaacLab 2.3 API" >}} +./isaaclab.sh -p scripts/reinforcement_learning/skrl/train.py \ + --task=Isaac-Shadow-Hand-Over-Direct-v0 \ + --headless \ + --algorithm MAPPO +{{< /tab >}} +{{< tab header="IsaacLab 3.0 API" >}} +./isaaclab.sh train \ + --rl_library skrl \ + --task=Isaac-Shadow-Hand-Over-Direct-v0 \ + --viz none \ + --algorithm MAPPO +{{< /tab >}} +{{< /tabpane >}} + +This command loads the task, selects the MAPPO training algorithm, and runs the simulation headless. Like earlier tasks, the Python entry point controls task and algorithm selection, letting you switch workflows without any recompilation. + +{{% notice Please Note %}} + +Training this task can take up to **30 minutes** on a DGX Spark. + +If you want to run the model from a pre-trained checkpoint available from NVIDIA Omniverse. You can optionally skip this training part and move to the verify section. When running the `play.py` script you will need to replace the + +```bash +--checkpoint= +``` + +with + +```bash +--use_pretrained_checkpoint +``` + +Please note that there may not be a model available from NVIDIAs Omniverse for your specific task and `IsaacLab` version tag. +{{% /notice %}} + + +### Verify + +After training, look for the following behaviors: + +* The two hands coordinate rather than moving independently. +* The hand holding the object adjusts its pose to create a feasible transfer path. +* Drops, collisions, and action conflicts decrease as training progresses. + +To view the trained policy, replace the checkpoint path with your trained model directory and run: + +{{< tabpane code=true >}} +{{< tab header="IsaacLab 2.3 API" >}} +./isaaclab.sh -p scripts/reinforcement_learning/skrl/play.py \ + --task=Isaac-Shadow-Hand-Over-Direct-v0 \ + --num_envs=1 \ + --algorithm=MAPPO \ + --real-time \ + --checkpoint= +{{< /tab >}} +{{< tab header="IsaacLab 3.0 API" >}} +./isaaclab.sh play \ + --rl_library skrl \ + --task=Isaac-Shadow-Hand-Over-Direct-v0 \ + --num_envs=1 \ + --algorithm=MAPPO \ + --real-time \ + --checkpoint= +{{< /tab >}} +{{< /tabpane >}} + +![Shadow Hand Over training progress showing two dexterous hands coordinating an object transfer. The left panel shows early training (iteration 3600) where motion is uncoordinated and the object is still held. The right panel shows the policy at convergence using the best_agent.pt checkpoint identified by skrl, where the hands smoothly coordinate the handover.#center](./multi_agent_hand.gif "Shadow Hand Over training progression. Left: iteration 3600. Right: best_agent.pt.") + +### Optional: Try IPPO and experiment with model size + +You can also try training an example using the IPPO (Independent Proximal Policy Optimization) algorithm. To do this, change the `--algorithm` flag to `IPPO` in your training command: + +{{< tabpane code=true >}} +{{< tab header="IsaacLab 2.3 API" >}} +./isaaclab.sh -p scripts/reinforcement_learning/skrl/train.py \ + --task=Isaac-Shadow-Hand-Over-Direct-v0 \ + --headless \ + --algorithm IPPO +{{< /tab >}} +{{< tab header="IsaacLab 3.0 API" >}} +./isaaclab.sh train \ + --rl_library skrl \ + --task=Isaac-Shadow-Hand-Over-Direct-v0 \ + --viz none \ + --algorithm IPPO +{{< /tab >}} +{{< /tabpane >}} + +IPPO treats each agent as independent, which can be useful for tasks where agents have separate roles or limited interaction. For further exploration, try altering the model size or network architecture in your training configuration. Experimenting with different model sizes can help you understand the trade-offs between training speed, memory usage, and policy performance. + +For more environments and supported algorithms, see the [comprehensive list of Isaac Lab environments](https://isaac-sim.github.io/IsaacLab/main/source/overview/environments.html#comprehensive-list-of-environments). + +## Core comparison: single-agent vs multi-agent training + +When you move from single-agent tasks to multi-agent training, the change is not just about adding more controllers. The problem definition itself becomes different. + +| Feature | Single-agent | Multi-agent (MAPPO / IPPO) | +| --- | --- | --- | +| Policy | One policy controls the whole robot | Each agent has its own policy, or partially shared policies | +| Observations | Often one observation vector | Each agent receives its own local observations | +| Actions | One action vector | Each agent outputs its own actions | +| Training paradigm | Standard PPO or other single-agent RL | Centralized training with decentralized execution, or independent learning | +| Algorithm flag | Usually not required | Selected with `--algorithm MAPPO` or optionally `--algorithm IPPO` | + +{{% notice Note %}} +In Isaac Lab, multi-agent training is currently driven mainly by the **skrl** library. If you try to run a multi-agent environment with another library such as **rsl_rl**, the task may fall back to a single-agent mode or lack full multi-agent support. +{{% /notice %}} + +## Wrap-up + +This section showed the main shift from single-agent control to multi-agent cooperation in Isaac Lab. Instead of focusing only on whether one robot moves correctly, you now have to think about how multiple agents form a coordinated strategy under partial information. + +On an Arm-based system, the key value in this section is not raw CPU performance. It is the ability of the **Arm CPU to control the overall simulation workflow**. Through Python scripts, task options, and algorithm flags, you can switch multi-agent scenarios quickly and continue developing, training, and comparing workflows on the same platform. + +## Next up + +Your robots can now perform precise actions and even cooperate, but the resulting motion may still look rigid. For humanoid robots that must coexist with people, moving in a more natural way is another important challenge. + +In the next section, you will explore **AMP (Adversarial Motion Priors)** and learn how robots can use reference motion data to produce more natural and fluent behavior. diff --git a/content/learning-paths/laptops-and-desktops/dgx_spark_isaac_robotics2/4_amp.md b/content/learning-paths/laptops-and-desktops/dgx_spark_isaac_robotics2/4_amp.md new file mode 100644 index 0000000000..075e16c5ba --- /dev/null +++ b/content/learning-paths/laptops-and-desktops/dgx_spark_isaac_robotics2/4_amp.md @@ -0,0 +1,214 @@ +--- +title: Reproducing Natural Motion with Adversarial Motion Priors (AMP) +weight: 5 + +### FIXED, DO NOT MODIFY +layout: learningpathall +--- + + +## From completing tasks to moving naturally + +In the previous section, you used an Arm-based Isaac Sim / Isaac Lab environment to run manipulation, contact-rich interaction, and multi-agent training tasks. This section continues on the same platform and introduces **Adversarial Motion Priors (AMP)**, a workflow that helps reinforcement learning policies produce motion that looks more natural and human-like. + +Traditional reinforcement learning can teach a robot to walk, run, or satisfy control objectives, but the resulting motion is often effective rather than natural. For robots that must coexist with people, interact in human environments, or demonstrate expressive behavior, that is usually not enough. Isaac Lab therefore supports **AMP**, which uses reference **motion-capture data** to guide policy learning toward smoother and more realistic movement. + +AMP comes from the SIGGRAPH 2021 paper by researchers at UC Berkeley and collaborators: [Adversarial Motion Priors for Stylized Physics-Based Character Control](https://arxiv.org/abs/2104.02180). At a high level, AMP works like a generative adversarial setup. A policy generates simulated motion, while a discriminator compares that motion against an unlabeled set of natural movement clips, often from motion capture. The policy then learns not only to complete the task reward, but also to produce trajectories that look statistically closer to the reference motion. + +In this section, you will use the **skrl** library with the `--algorithm AMP` flag to run humanoid walking, running, and dancing tasks. + +As in the previous section, the Arm value in this workflow is mainly about **workflow control**. Developers can use Python scripts, task flags, and algorithm options to switch tasks, control training flow, and iterate on experiments, while the GPU continues to support the heavy simulation and training workload. + + +## Task 1: Humanoid Walk — learning a natural gait + +### Scenario goal + +Use human walking reference data to train a humanoid robot to produce stable and natural walking behavior. + +### Run + +Use the **skrl** library together with `--algorithm AMP` to launch training: + +{{< tabpane code=true >}} +{{< tab header="IsaacLab 2.3 API" >}} +./isaaclab.sh -p scripts/reinforcement_learning/skrl/train.py \ + --task=Isaac-Humanoid-AMP-Walk-Direct-v0 \ + --headless \ + --algorithm AMP \ + --max_iterations=1000 +{{< /tab >}} +{{< tab header="IsaacLab 3.0 API" >}} +./isaaclab.sh train \ + --rl_library skrl \ + --task=Isaac-Humanoid-AMP-Walk-Direct-v0 \ + --viz none \ + --algorithm AMP \ + --max_iterations=1000 +{{< /tab >}} +{{< /tabpane >}} + +### Verify + +After training, look for the following behaviors: + +* The humanoid moves forward stably instead of losing balance frequently. +* The gait shows smoother center-of-mass transfer instead of stiff hopping-like motion. +* The left and right leg timing resembles a more natural walking pattern. + +{{< tabpane code=true >}} +{{< tab header="IsaacLab 2.3 API" >}} +./isaaclab.sh -p scripts/reinforcement_learning/skrl/play.py \ + --task=Isaac-Humanoid-AMP-Walk-Direct-v0 \ + --algorithm=AMP \ + --num_envs=16 \ + --checkpoint=logs/skrl/humanoid_amp_walk//checkpoints/best_agent.pt \ + --real-time +{{< /tab >}} +{{< tab header="IsaacLab 3.0 API" >}} +./isaaclab.sh play \ + --rl_library skrl \ + --task=Isaac-Humanoid-AMP-Walk-Direct-v0 \ + --algorithm=AMP \ + --num_envs=16 \ + --checkpoint=logs/skrl/humanoid_amp_walk//checkpoints/best_agent.pt \ + --real-time +{{< /tab >}} +{{< /tabpane >}} + +![Humanoid AMP walk training comparison. The left panel at iteration 3200 shows less stable gait timing and more rigid motion. The right panel at iteration 11600 shows smoother center-of-mass transfer, better leg coordination, and more natural walking behavior.#center](./walking_humanoid.gif "Humanoid AMP walk progression. Left: iteration 3200. Right: iteration 11600.") + + +## Task 2: Humanoid Run — adding speed and coordination + +If walking is mainly about stability and rhythm, running introduces a higher level of dynamic coordination. The robot must generate propulsion in a shorter contact window, keep the body balanced, and avoid losing control as motion amplitude increases. + +### Scenario goal + +Use human running reference data to train a humanoid robot to maintain a natural and controllable running pattern at higher speed. + +### Run + +{{< tabpane code=true >}} +{{< tab header="IsaacLab 2.3 API" >}} +./isaaclab.sh -p scripts/reinforcement_learning/skrl/train.py \ + --task=Isaac-Humanoid-AMP-Run-Direct-v0 \ + --headless \ + --algorithm AMP \ + --max_iterations=1000 +{{< /tab >}} +{{< tab header="IsaacLab 3.0 API" >}} +./isaaclab.sh train \ + --rl_library skrl \ + --task=Isaac-Humanoid-AMP-Run-Direct-v0 \ + --viz none \ + --algorithm AMP \ + --max_iterations=1000 +{{< /tab >}} +{{< /tabpane >}} + +### What changes in the workflow + +Compared with the walking task, you do not need to change platforms or rebuild the project. You only switch the task to enter another motion-prior-driven scenario. This is a clear example of workflow control: the same Python entry point, toolchain, and development environment can be reused while exploring different natural-motion tasks. + +### Verify + +After training, confirm the following: + +* As forward speed increases, the robot remains stable rather than falling immediately. +* Arm swing, leg lift, and landing timing become more coordinated. +* The motion looks like a recognizable running pattern rather than just aggressive forward movement. + +{{< tabpane code=true >}} +{{< tab header="IsaacLab 2.3 API" >}} +./isaaclab.sh -p scripts/reinforcement_learning/skrl/play.py \ + --task=Isaac-Humanoid-AMP-Run-Direct-v0 \ + --algorithm=AMP \ + --num_envs=16 \ + --checkpoint=logs/skrl/humanoid_amp_run//checkpoints/best_agent.pt \ + --real-time +{{< /tab >}} +{{< tab header="IsaacLab 3.0 API" >}} +./isaaclab.sh play \ + --rl_library skrl \ + --task=Isaac-Humanoid-AMP-Run-Direct-v0 \ + --algorithm=AMP \ + --num_envs=16 \ + --checkpoint=logs/skrl/humanoid_amp_run//checkpoints/best_agent.pt \ + --real-time +{{< /tab >}} +{{< /tabpane >}} + +{{% notice Tip %}} + +If the performance is not enough, run the following command to to resume from a specific checkpoint. + +{{< tabpane code=true >}} +{{< tab header="IsaacLab 2.3 API" >}} +./isaaclab.sh -p scripts/reinforcement_learning/skrl/train.py \ + --task=Isaac-Humanoid-AMP-Run-Direct-v0 \ + --headless \ + --algorithm AMP \ + --max_iterations= \ + --checkpoint= +{{< /tab >}} +{{< tab header="IsaacLab 3.0 API" >}} +./isaaclab.sh train \ + --rl_library skrl \ + --task=Isaac-Humanoid-AMP-Run-Direct-v0 \ + --viz none \ + --algorithm AMP \ + --max_iterations= \ + --checkpoint= +{{< /tab >}} +{{< /tabpane >}} + +{{% /notice %}} + +![img8 alt-text#center](./amp_running.gif "Humanoid trained with AMP with 3000 epochs (left) and 26000 epochs (right). Left shows humanoid immediately stumbling where as at only 26,000 iterations the humanoid begins a skipping like gate to try and match the target velocity of running") + +Try training the model further to see if the skipping-like motion evolves into a run. + +## Optional task 3: Humanoid Dance + +To optionally test style-heavy motion generation, run this AMP dance task: + +{{< tabpane code=true >}} +{{< tab header="IsaacLab 2.3 API" >}} +./isaaclab.sh -p scripts/reinforcement_learning/skrl/train.py \ + --task=Isaac-Humanoid-AMP-Dance-Direct-v0 \ + --headless \ + --algorithm AMP +{{< /tab >}} +{{< tab header="IsaacLab 3.0 API" >}} +./isaaclab.sh train \ + --rl_library skrl \ + --task=Isaac-Humanoid-AMP-Dance-Direct-v0 \ + --viz none \ + --algorithm AMP +{{< /tab >}} +{{< /tabpane >}} + +{{% notice Please note %}} + +As of May 2026, training this model with the default number of iterations typically takes several hours on a DGX Spark. A pre-trained checkpoint for this task is not available at this time, so you will need to train the model from scratch. + +{{% /notice %}} + + +## AMP task overview + +| Task | Reference motion data | Expected outcome | +|---|---|---| +| Isaac-Humanoid-AMP-Walk-Direct-v0 | Human walking capture data | Natural and stable walking gait | +| Isaac-Humanoid-AMP-Run-Direct-v0 | Human running capture data | Smoother high-speed running behavior | +| Isaac-Humanoid-AMP-Dance-Direct-v0 | Human dance capture data | Rhythmic and expressive dance motion | + +For humanoid robots that must coexist with people, the value of AMP is not only that the motion looks more human. It can also improve center-of-mass transfer and dynamic stability, which may improve behavior quality in more complex environments. + + +## Next up + +You have now worked through the main workflows in this series, from basic manipulation to high-precision assembly, multi-agent cooperation, and natural-motion imitation. + +In the next section, you will summarize the full tutorial and compare the main RL libraries supported by Isaac Lab. diff --git a/content/learning-paths/laptops-and-desktops/dgx_spark_isaac_robotics2/5_compare_rl_lib.md b/content/learning-paths/laptops-and-desktops/dgx_spark_isaac_robotics2/5_compare_rl_lib.md new file mode 100644 index 0000000000..fc7ad5fa14 --- /dev/null +++ b/content/learning-paths/laptops-and-desktops/dgx_spark_isaac_robotics2/5_compare_rl_lib.md @@ -0,0 +1,99 @@ +--- +title: Choosing RL Libraries +weight: 6 + +### FIXED, DO NOT MODIFY +layout: learningpathall +--- + +## From task runner to workflow architect + +In the previous sections, you used an Arm-based Isaac Sim / Isaac Lab environment for manipulation, contact-rich interaction, multi-agent training, and AMP-based motion. Now move from running tasks to designing the workflow. + +**Given your task characteristics, which RL library should you choose, and how should you scale the workflow from one platform?** + + +## Choosing your technical toolkit + +One of Isaac Lab's main strengths is that it is not tied to a single RL framework. Instead, it provides an open and extensible ecosystem, allowing you to choose different RL libraries and training entry points depending on the problem you want to solve. + +For an architect, this choice is mostly about tradeoffs. Different tasks impose different requirements for throughput, observation complexity, algorithm features, debugging convenience, and extensibility. It directly affects how fast you can iterate and how well the workflow scales for your specific use case. Choose an RL library for an Isaac Lab workflow based on task type and development goals. + + +## Library tradeoffs and decision guidance + +The following table summarizes four commonly used RL libraries in Isaac Lab, with links to their repositories and the task profiles they fit best. + +| Library | Core strength | Best fit | +|---|---|---| +| [**RSL-RL**](https://github.com/leggedrobotics/rsl_rl) | Lightweight, fast, memory-efficient | Locomotion, fast iteration, large parallel training | +| [**rl_games**](https://github.com/Denys88/rl_games) | Supports LSTM and visual encoders | Complex observation spaces, contact-rich manipulation, Factory tasks | +| [**skrl**](https://github.com/Toni-SM/skrl) | Modular design with MARL and AMP support | Multi-agent training, natural-motion imitation, flexible workflow extension | +| [**Stable Baselines3**](https://github.com/DLR-RM/stable-baselines3) | Strong documentation and standardized API | Teaching, prototyping, baseline comparison | + +### Choose based on task and workflow needs + +Use a first-pass mapping from task needs to library behavior: + +* For maximum training speed and throughput, start with **RSL-RL**. +* For complex observations or recurrent policies, use **rl_games**. +* For multi-agent workflows or AMP-style training, use **skrl**. +* For educational baselines and standardized comparisons, use **Stable Baselines3**. + +In Isaac Lab, this choice also affects scripts, configuration style, and experiment structure. On Arm-based systems, this workflow is practical because you can switch stacks through script entry points and CLI flags. Unified memory also helps startup because simulation and learning can avoid host-to-device transfers. Because CPU and GPU share one memory pool, each side can use more or less memory as needed for better throughput, instead of hitting bottlenecks from fixed per-device limits. Environment count can then scale to use much of the available 128 GB memory. + + +## Mapping libraries to task types + +To make the decision more concrete, the following table maps the task categories from the earlier sections to common library choices. + +| Task type | Suggested library | Why | +|---|---|---| +| Franka Reach / Lift and other basic manipulation tasks | **RSL-RL** | Simple setup and good for fast baselines with large parallel rollout | +| Drawer / Factory and other contact-rich tasks | **rl_games** | Better suited for more complex observation and policy structures | +| Multi-agent object handover | **skrl** | A more natural fit for MARL workflows | +| Humanoid AMP Walk / Run / Dance | **skrl** | Direct fit for AMP-style algorithms and natural-motion tasks | +| Educational examples and standard RL baselines | **Stable Baselines3** | Standardized API and easy comparison workflow | + +{{% notice Tip %}} +No single library is the best choice for every task. A practical strategy is to start with the tool that helps you establish a baseline quickly, then move to a more specialized training stack when the task requires it. +{{% /notice %}} + + +## Scaling up: multi-GPU distributed training + +Most readers in this Learning Path use one GPU, and that setup is already enough for many manipulation and locomotion tasks. If you later move to multi-GPU systems, distributed training can improve throughput for very large workloads. + +### Run + +`torch.distributed.run` is PyTorch's distributed launcher. It creates one process per GPU and coordinates rank-to-rank communication so all workers train synchronously. The following example is for one node with two GPUs: + +If your setup includes multiple networked systems, the same pattern extends to clusters, for example Grace Hopper servers or DGX Spark systems connected over a high-speed network. In those cases, `--nnodes` and rank settings are expanded to span the full cluster. + +{{< tabpane code=true >}} +{{< tab header="IsaacLab 2.3 API" >}} +python -m torch.distributed.run --nnodes=1 --nproc_per_node=2 \ + scripts/reinforcement_learning/rsl_rl/train.py \ + --task= \ + --headless \ + --distributed +{{< /tab >}} +{{< tab header="IsaacLab 3.0 API" >}} +python -m torch.distributed.run --nnodes=1 --nproc_per_node=2 \ + scripts/reinforcement_learning/train.py \ + --rl_library rsl_rl \ + --task= \ + --viz none \ + --distributed +{{< /tab >}} +{{< /tabpane >}} + +This command defines the training entry point, worker-process count, distributed mode, and task selection in one place. In this workflow, the CPU side handles launch and orchestration while GPUs handle simulation and learning throughput. + + + +## What you've learned and what's next + +You progressed from basic manipulation to workflow-level decisions for Isaac Lab on Arm. You practiced task selection, library tradeoffs, MARL and AMP workflows, and when distributed training is worth considering. + +Next, adapt these scripts as reference implementations for your own USD assets, robot models, scenes, and task constraints. Start with a single-GPU baseline, then expand only when workload scale requires it. diff --git a/content/learning-paths/laptops-and-desktops/dgx_spark_isaac_robotics2/_index.md b/content/learning-paths/laptops-and-desktops/dgx_spark_isaac_robotics2/_index.md new file mode 100644 index 0000000000..e00248a3cf --- /dev/null +++ b/content/learning-paths/laptops-and-desktops/dgx_spark_isaac_robotics2/_index.md @@ -0,0 +1,67 @@ +--- +title: Advance Robotics Reinforcement Learning Workflows to Manipulation and Multi-Agent Tasks with IsaacLab + +draft: true +cascade: + draft: true + +minutes_to_complete: 120 + +who_is_this_for: This advanced topic is intended for robotics software architects, simulation engineers, and AI researchers who want to orchestrate high-fidelity robotic simulations and reinforcement learning (RL) pipelines. It specifically targets those leveraging Isaac Sim and Isaac Lab on Arm-based NVIDIA DGX Spark systems powered by the Grace–Blackwell (GB10) architecture. + +learning_objectives: + - Describe the roles of Isaac Sim and Isaac Lab. + - Train a reinforcement learning policy for simulations of the Franka robotic arm and Unitree H1 humanoid robot using the RSL-RL and skrl interface. + - Train reinforcement learning policies in multi-agent environments for cooperative robotic systems. + - Use Adversarial Motion Priors (AMP) to enable natural humanoid locomotion. + +prerequisites: + - Access to an NVIDIA DGX Spark system with at least 50 GB of free disk space + - Completion of the previous Isaac Sim / Isaac Lab setup on Arm-based systems + - Experience with Python scripting + - Basic understanding of reinforcement learning concepts (rewards, policies, etc.) + +author: + - Johnny Nunez + - Kieran Hejmadi + - Odin Shen + + +### Tags +skilllevels: Advanced +subjects: ML +armips: + - Cortex-X + - Cortex-A +tools_software_languages: + - Python + - Bash + - IsaacSim + - IsaacLab +operatingsystems: + - Linux + +further_reading: + - resource: + title: Isaac Sim Documentation + link: https://docs.isaacsim.omniverse.nvidia.com/latest/index.html + type: documentation + - resource: + title: Isaac Lab Documentation + link: https://isaac-sim.github.io/IsaacLab/main/index.html + type: documentation + - resource: + title: Isaac Sim and Isaac Lab learning path + link: https://learn.arm.com/learning-paths/laptops-and-desktops/dgx_spark_isaac_robotics/ + type: website + - resource: + title: DGX Spark Isaac Sim and Isaac Lab Playbook + link: https://build.nvidia.com/spark/isaac/overview + type: website + +### FIXED, DO NOT MODIFY +# ================================================================================ +weight: 1 # _index.md always has weight of 1 to order correctly +layout: "learningpathall" # All files under learning paths have this same wrapper +learning_path_main_page: "yes" # This should be surfaced when looking for related content. Only set for _index.md of learning path content. +--- diff --git a/content/learning-paths/laptops-and-desktops/dgx_spark_isaac_robotics2/_next-steps.md b/content/learning-paths/laptops-and-desktops/dgx_spark_isaac_robotics2/_next-steps.md new file mode 100644 index 0000000000..c3db0de5a2 --- /dev/null +++ b/content/learning-paths/laptops-and-desktops/dgx_spark_isaac_robotics2/_next-steps.md @@ -0,0 +1,8 @@ +--- +# ================================================================================ +# FIXED, DO NOT MODIFY THIS FILE +# ================================================================================ +weight: 21 # Set to always be larger than the content in this path to be at the end of the navigation. +title: "Next Steps" # Always the same, html page title. +layout: "learningpathall" # All files under learning paths have this same wrapper for Hugo processing. +--- diff --git a/content/learning-paths/laptops-and-desktops/dgx_spark_isaac_robotics2/amp_running.gif b/content/learning-paths/laptops-and-desktops/dgx_spark_isaac_robotics2/amp_running.gif new file mode 100644 index 0000000000..566a0fa674 Binary files /dev/null and b/content/learning-paths/laptops-and-desktops/dgx_spark_isaac_robotics2/amp_running.gif differ diff --git a/content/learning-paths/laptops-and-desktops/dgx_spark_isaac_robotics2/multi_agent_hand.gif b/content/learning-paths/laptops-and-desktops/dgx_spark_isaac_robotics2/multi_agent_hand.gif new file mode 100644 index 0000000000..ed47b29325 Binary files /dev/null and b/content/learning-paths/laptops-and-desktops/dgx_spark_isaac_robotics2/multi_agent_hand.gif differ diff --git a/content/learning-paths/laptops-and-desktops/dgx_spark_isaac_robotics2/open_drawer.gif b/content/learning-paths/laptops-and-desktops/dgx_spark_isaac_robotics2/open_drawer.gif new file mode 100644 index 0000000000..ecd40fcb96 Binary files /dev/null and b/content/learning-paths/laptops-and-desktops/dgx_spark_isaac_robotics2/open_drawer.gif differ diff --git a/content/learning-paths/laptops-and-desktops/dgx_spark_isaac_robotics2/peg.gif b/content/learning-paths/laptops-and-desktops/dgx_spark_isaac_robotics2/peg.gif new file mode 100644 index 0000000000..6a2208bad5 Binary files /dev/null and b/content/learning-paths/laptops-and-desktops/dgx_spark_isaac_robotics2/peg.gif differ diff --git a/content/learning-paths/laptops-and-desktops/dgx_spark_isaac_robotics2/reach.gif b/content/learning-paths/laptops-and-desktops/dgx_spark_isaac_robotics2/reach.gif new file mode 100644 index 0000000000..8dfeb3436b Binary files /dev/null and b/content/learning-paths/laptops-and-desktops/dgx_spark_isaac_robotics2/reach.gif differ diff --git a/content/learning-paths/laptops-and-desktops/dgx_spark_isaac_robotics2/reach_and_lift.gif b/content/learning-paths/laptops-and-desktops/dgx_spark_isaac_robotics2/reach_and_lift.gif new file mode 100644 index 0000000000..47543a5a9a Binary files /dev/null and b/content/learning-paths/laptops-and-desktops/dgx_spark_isaac_robotics2/reach_and_lift.gif differ diff --git a/content/learning-paths/laptops-and-desktops/dgx_spark_isaac_robotics2/walking_humanoid.gif b/content/learning-paths/laptops-and-desktops/dgx_spark_isaac_robotics2/walking_humanoid.gif new file mode 100644 index 0000000000..7b7bfb82f9 Binary files /dev/null and b/content/learning-paths/laptops-and-desktops/dgx_spark_isaac_robotics2/walking_humanoid.gif differ