NVIDIA demonstrates AI agents training Microduck robots across 4,096 parallel simulations
NVIDIA has presented a robotics development workflow in which AI agents help design a simulated obstacle course, generate its three-dimensional assets and prepare a reinforcement-learning environment for Microduck, a small open-source bipedal robot.
Published on October 23, 2026, the technical walkthrough connects Hermes, NVIDIA Nemotron 3.5 Bolt, Astra, Isaac Sim, Isaac Lab and the Newton physics engine, with different components responsible for planning, scene construction, physical simulation, policy training and validation.
The most computationally intensive stage uses 4,096 parallel environments on an NVIDIA RTX PRO 6000 Blackwell Workstation Edition GPU, allowing a pretrained locomotion policy to receive additional training for navigating ramps and obstacles using depth-camera and robot-state observations.
This is not an example of a language model directly learning to control a robot through conversation. Language-model-based agents organize the development process, while a separate reinforcement-learning system improves the policy responsible for movement.
NVIDIA also distinguishes simulation validation from physical deployment. The complete AI-generated obstacle-course workflow is not reported as independently validated on physical hardware.
··········
THE MICRODUCK PROJECT CONNECTS AGENTIC AI WITH PHYSICAL AI.
Robotics development requires an accurate physical model, a representation of the surroundings, a control interface and a training procedure that rewards useful behavior without encouraging unstable movements.
For a small bipedal robot, minor differences in foot contact, motor response or friction can substantially change the movements required to maintain balance.
Microduck comes from the open-source robotics ecosystem associated with Pollen Robotics and Hugging Face. Public documentation describes a compact robot approximately 25 centimeters tall and weighing around 800 grams.
NVIDIA builds on this existing platform and concentrates on constructing a more complex simulated environment for obstacle navigation.
The architecture is heterogeneous: agents coordinate specialized applications rather than replacing the physics engine or the reinforcement-learning algorithm.
........
Component | Function |
Microduck | Bipedal robot reference |
Hermes | Agent coordination |
Nemotron 3.5 Bolt | Planning and reasoning |
Astra | Asset and scene preparation |
FreeCAD and Blender | Editable geometry and materials |
Isaac Sim | Scene and sensor simulation |
Newton | Physics and contact dynamics |
Isaac Lab | Policy training |
RTX Spark | Local development |
RTX PRO 6000 Blackwell | 4,096-environment training |
........
··········
HERMES AND NEMOTRON TURN A ROBOTICS OBJECTIVE INTO A DEVELOPMENT PLAN.
The workflow begins with a natural-language description of a robot navigating an obstacle course while maintaining balance and responding to its surroundings.
On NVIDIA RTX Spark, Hermes and Nemotron 3.5 Bolt translate the objective into a structured project plan, reviewing Microduck documentation and identifying the resources and dependencies required for subsequent stages.
The agents describe the proposed course, including dimensions, clearances, obstacles and physical challenges. A visually plausible ramp can still be too steep for a robot, so documented capabilities must be distinguished from assumptions.
A local image-generation model creates a concept image. Hermes and Nemotron identify reusable objects such as ramps, platforms, mats and barriers, then produce an asset inventory with descriptions and reference crops.
Incomplete or obscured details are recorded so that later modeling stages can distinguish observed features from invented geometry.
The project plan, documentation, concept image and asset inventory are handed to Astra, turning the initial request into structured inputs for further software-tool orchestration.
··········
ASTRA GENERATES EDITABLE 3D ASSETS RATHER THAN ONLY VISUAL CONCEPTS.
A concept image is insufficient for robotics simulation because a physics engine requires geometry, dimensions, materials and collision-relevant surfaces.
Astra examines the prepared image references, improves the visibility of small or incomplete crops with image-editing tools and compares enhanced results against original references.
It orchestrates FreeCAD to construct editable geometry and Blender to add materials and detail, then exports the assets as USD representations for the simulation environment.
Editable formats matter because developers may need to adjust dimensions, collision shapes or surface properties after testing. A visually convincing but unmodifiable object is less useful during engineering iteration.
NVIDIA also points to the SimReady Central Library, which contains more than 2,000 accessible OpenUSD assets that can reduce the need for custom modeling.
Generated geometry still requires validation: matching the reference image does not automatically establish correct mass, friction or collision properties.
........
Stage | Output | Purpose |
Concept | Course image | Design reference |
Inventory | Object crops | Asset requirements |
FreeCAD | Editable geometry | Physical shapes |
Blender | Details and materials | Scene preparation |
USD export | Simulation assets | Isaac Sim import |
Verification | Asset checks | Detect missing elements |
........
··········
ISAAC SIM ASSEMBLES THE COURSE WHILE NEWTON MODELS PHYSICAL BEHAVIOR.
After asset generation, Astra assembles the course in NVIDIA Isaac Sim, arranging platforms, ramps and obstacles according to the project plan.
Isaac Sim provides the scene and access to rendering and sensor simulation, while Newton calculates physical behavior such as rigid-body dynamics and contacts.
Microduck's articulated body is represented through rigid links, joints and actuators. Their motion interacts with surface friction, inclines and contact forces.
The simulated depth camera determines what the robot can observe, while physics determines how its body responds when joints move or feet contact the ground.
The policy receives observations, produces actions and receives updated observations after the physics simulation advances, forming the closed loop required for reinforcement learning.
··········
REINFORCEMENT LEARNING TRAINS THE CONTROL POLICY, NOT THE PLANNING AGENTS.
Hermes, Nemotron and Astra prepare the development environment. The locomotion policy is trained separately through reinforcement learning in Isaac Lab.
The policy receives observations of robot state and surroundings and produces actions that influence joint movement. The simulator evaluates consequences such as forward progress, balance, collision or falling.
Reward feedback is used by the reinforcement-learning algorithm to update the policy, balancing movement objectives against stability and other constraints.
NVIDIA does not describe language-model agents directly updating the locomotion network's parameters. Agentic orchestration and embodied control operate at different levels of the system.
........
System | Input | Output |
Hermes and Nemotron | Task and documentation | Project plan |
Astra | References and plan | Assets and scene |
Locomotion policy | State and sensors | Joint actions |
Newton | State and actions | Physical response |
RL algorithm | Experience and reward | Updated policy |
........
··········
THE 4,096 PARALLEL ENVIRONMENTS ACCELERATE POLICY ADAPTATION.
NVIDIA reports using 4,096 parallel Isaac Lab environments on an RTX PRO 6000 Blackwell Workstation Edition GPU.
Instead of running one robot through sequential attempts, the system simulates thousands of instances concurrently, collecting experience from many interactions and failures.
The obstacle-course experiment begins with a pretrained Microduck locomotion policy and performs additional training for ramps and obstacles, rather than learning to walk from scratch.
Observations include head-mounted depth-camera data and internal robot state, allowing the policy to relate terrain ahead to its current posture and motion.
The number 4,096 denotes simultaneous simulated environments, not physical robots, AI agents or independently trained foundation models. It is also not a success rate.
The publication does not provide complete training curves, convergence times, final rewards or obstacle-completion percentages for the adaptation experiment.
........
Parameter | Verified information |
Robot | Microduck |
Framework | Isaac Lab |
Physics | Newton |
Parallel environments | 4,096 |
Training GPU | RTX PRO 6000 Blackwell Workstation Edition |
Starting point | Pretrained locomotion policy |
Adaptation | Ramps and obstacles |
Observations | Depth and robot state |
Completion rate | Not reported |
Training duration | Not reported |
........
··········
DEPTH OBSERVATIONS ALLOW MICRODUCK TO RESPOND TO TERRAIN AHEAD.
Obstacle navigation requires more than a stable walking pattern on level ground. A depth camera supplies information about distances to nearby surfaces, while robot-state observations describe its current movement and configuration.
A ramp visible in a depth image does not alone determine the right action: the policy must account for orientation, joint positions and whether the robot is moving or recovering from an unstable step.
The simulator repeatedly updates these observations as Microduck moves, enabling state-dependent control rather than a fixed sequence of joint movements.
Synthetic depth data do not guarantee equivalent performance from a physical camera, where noise, latency and incomplete measurements can differ.
··········
RTX SPARK SUPPORTS LOCAL DEVELOPMENT AND POLICY VALIDATION.
RTX Spark serves as the local development environment for agent preparation and later Isaac Sim evaluation of the selected policy.
The computationally intensive 4,096-environment training experiment uses an RTX PRO 6000 Blackwell Workstation Edition GPU; RTX Spark is not described as running all these environments.
After training, the selected policy is evaluated locally to observe obstacle detection, movement adjustments, collisions, falls and incomplete traversals.
Rollout videos and failure records help identify when environmental adjustments or further training may be necessary.
This distinction also illustrates why training hardware requirements should not be conflated with the resources needed to run a trained policy.
··········
SIMULATION VALIDATION DOES NOT ESTABLISH PHYSICAL DEPLOYMENT SUCCESS.
The October 23 walkthrough covers asset generation, simulation assembly, policy adaptation and local evaluation. It does not report completion of the entire generated obstacle course on physical hardware.
NVIDIA also illustrates a locomotion policy operating on a physical Microduck and provides a separate hardware tutorial, but those demonstrations should not be conflated with this particular obstacle-course experiment.
A physical robot introduces servo imperfections, ground-friction variation, imperfect mass estimates, sensor noise and control latency that may not be fully represented in simulation.
For a small biped, these differences can destabilize walking. NVIDIA addresses them through actuator modeling and domain randomization, but real-world validation remains necessary.
··········
BETTER ACTUATOR MODELS HELP NARROW THE SIM-TO-REAL GAP.
Isaac Lab supports Better Actuator Models, or BAM, to represent aspects of physical servo behavior overlooked by simpler simulations.
These include command delays, mechanical backlash and variations in motor performance associated with battery voltage under load.
Backlash can delay joint response after a motor reverses direction, while battery behavior changes available actuation when several motors draw power simultaneously.
A policy trained under idealized motor behavior may become unstable when these effects occur on hardware.
More realistic models improve preparation for transfer, but their parameters should be calibrated against measurements from the actual robot.
··········
DOMAIN RANDOMIZATION TRAINS AGAINST PHYSICAL UNCERTAINTY.
Even a calibrated simulator cannot perfectly reproduce every condition a robot may encounter. Domain randomization varies selected physical parameters and observations during training to reduce dependence on one idealized setup.
The related Microduck tutorial discusses variation in mass distribution, friction, joint inertia, encoder offsets, battery behavior, command latency, backlash, terrain and external disturbances.
Randomization ranges require engineering judgment. Narrow ranges may fail to cover real conditions, while excessively broad or implausible ranges can make training inefficient.
Domain randomization supports robustness but does not substitute for physical testing.
........
Uncertainty | Modeling consideration |
Friction | Foot contact and slipping |
Mass | Balance |
Servo delay | Response timing |
Backlash | Direction changes |
Battery voltage | Actuator performance |
Encoder offsets | Joint observations |
Sensor noise | Measurement reliability |
Terrain | Surface variation |
........
··········
THE RELATED ISAAC LAB TUTORIAL DOCUMENTS A HARDWARE DEPLOYMENT PATH.
NVIDIA's related October 21, 2026 Microduck tutorial describes training environments, policy evaluation, ONNX export and deployment to the physical robot.
Its documented locomotion-policy interface uses 61 observation values and produces 14 joint-position outputs. These figures refer to that locomotion configuration, not automatically to every depth-based obstacle policy.
The tutorial provides a training command using 4,096 environments and a backlash-aware configuration. It also describes a 16-GPU distributed training setup reaching up to 1.25 million simulation steps per second with rough terrain and backlash enabled.
That 16-GPU throughput is a separate result and must not be attributed to the single-GPU RTX PRO 6000 obstacle-course adaptation reported on October 23.
Exported ONNX policies require consistent observation ordering, normalization and action scaling before use on the robot.
uv run isaaclab train --rl_library rsl_rl --task IsaacContrib-Velocity-Rough-MicroDuck --num_envs 4096 presets=backlash··········
OPEN-SOURCE COMPONENTS MAKE THE WORKFLOW MORE ACCESSIBLE.
Microduck's public hardware and software ecosystem supplies a robot model and control interface, while Isaac Lab provides configurable training environments.
Newton offers an open-source physics component and OpenUSD supports exchange of assets between modeling tools and the simulator.
The SimReady Central Library reduces custom asset work, and the related tutorial documents export and deployment steps.
Public software does not eliminate the need for compatible GPUs, correctly configured software, calibrated physics parameters and robotics expertise.
The October 23 publication does not provide an independently reproduced performance benchmark for every stage of the agentic pipeline.
··········
THE EXPERIMENT DOES NOT PROVIDE A COMPLETE ROBOTICS BENCHMARK.
NVIDIA specifies the 4,096 parallel environments, training GPU and principal components, but does not publish complete final obstacle-navigation success rates, training durations, energy use or hardware outcomes for the full task.
The article also does not quantify how much engineering time the agents saved relative to manual scene construction.
Evaluating such a workflow in production would require asset correctness checks, measures of human intervention, repeatable policy trials and recovery-cost analysis for failed agent operations.
The supported conclusion is that NVIDIA demonstrates an integrated workflow for preparing and training a robot in simulation, not a universal advantage over other robotics-development methods.
........
Evaluation | Evidence |
Agentic scene preparation | Demonstrated |
4,096 environments | Reported |
GPU | RTX PRO 6000 Blackwell |
Pretrained policy | Yes |
Training time | Not specified |
Final success rate | Not specified |
Full-course physical deployment | Not established |
Development time savings | Not quantified |
........
··········
WHAT AGENTIC ROBOTICS CHANGES IN THE DEVELOPMENT PROCESS.
The distinctive contribution is the orchestration of work spanning planning, image interpretation, CAD modeling, asset conversion, scene assembly and reinforcement-learning preparation.
This may make prototyping more accessible and allow changes to an obstacle course to propagate through the workflow before retraining.
However, automated asset creation does not remove the need to check geometry, collision behavior and physical realism. Nor does a successful simulation eliminate deployment validation.
The strongest pattern is one in which language-model agents coordinate specialized engineering systems while those systems retain responsibility for physically meaningful computation.
··········
WHY NVIDIA'S MICRODUCK WORKFLOW MATTERS FOR PHYSICAL AI.
NVIDIA's Microduck demonstration connects generative AI, agentic orchestration, GPU-accelerated physics simulation and reinforcement learning in a coherent robotics-development workflow.
The 4,096 parallel environments illustrate how an existing locomotion policy can be adapted to more complex terrain, while Isaac Sim, Isaac Lab and Newton provide the environment, training and physical simulation infrastructure.
The agentic layer addresses a different bottleneck: preparing project plans, editable assets and structured handoffs between development applications.
The result does not establish general robotic intelligence or successful autonomous physical deployment of the entire obstacle-course task, but it shows how AI-assisted engineering and numerical robot learning can operate together with simulation as the validation environment.
··········
FOLLOW US FOR MORE.
·····
DATA STUDIOS
·····
datastudios.org
