Micro Duck’s Walking Policy Trains in the Cloud, Then Returns to Local Simulation
The workflow uses NVIDIA RTX Spark for scene creation and policy evaluation, while cloud compute handles parallel training in Isaac Lab; the trained policy then returns to the local system before deployment to Micro Duck. The operator says Astra uses tools including FreeCAD, Blender and Isaac Sim to build the course and robot model, and that Isaac Lab trains thousands of Micro Ducks in parallel. The account shows the robot walking after deployment but reports no separate measurement of its real-world performance.
Local tools build the loop; cloud compute scales the training
The central design choice is to keep environment creation, scene configuration and evaluation on RTX Spark, while sending parallel policy training to the cloud. After training, the policy returns to RTX Spark for evaluation in Isaac Sim, then is deployed to the physical Micro Duck. The workflow is presented as a way to use a local machine for the agent’s tools and simulation while shifting a larger workload elsewhere.
The operator says they run everything on RTX Spark except when they need to “burst larger workloads to cloud.” They use Hermes as the agent harness, with Nemotron and GPT-4o as models, and name FreeCAD, Blender, Isaac Sim, Newton and Isaac Lab among the tools. In the workflow diagram, Hermes and Nemotron handle planning and orchestration; GPT-4o is assigned to Astra’s tool use. Asset creation and scene setup are marked local, training is marked cloud, and evaluation is local.
That division matters because the training workload is not the only part of the system. The local stage must produce a scene and robot that can be simulated; the cloud stage trains a walking policy against that setup; and the policy must then be brought back and evaluated before deployment. The operator describes that return step as downloading the policy to RTX Spark and using Nemotron and Isaac Sim to evaluate it with multi-robot orchestration. A prompt shown during evaluation instructs the robots: “Now walk over the north ramp in a single file.” The operator says the validated policy is then deployed to the real duck.
Training depends on a physical scene, not just a course image
For the loop to work, the obstacle course has to become a simulation environment with usable objects, physical properties and a robot whose movement can be modeled. The operator begins by describing the course and what Micro Duck needs to learn. Hermes and Nemotron plan the workflow and list the objects required; the displayed prompt also asks for a concept image and its analysis. In that analysis, bounding boxes identify course props including a flight case and a light stand.
Astra then uses FreeCAD to model objects and Blender to apply materials. Omniverse SimReady libraries supply physical properties. Astra composes the scene in Isaac Sim, then rigs Micro Duck’s joints, actuators and links. Newton is used to simulate how the robot moves. These are distinct pieces of the training setup: modeled objects and materials give the environment form, physical properties and Newton support simulation, and the rig makes the robot’s movement part of that simulated scene.
This assembled environment is what makes the cloud training stage possible. Isaac Lab runs thousands of Micro Ducks in parallel, practicing on ramps and obstacles. The operator describes the iteration as “Every fall, a lesson. Improving the policy every time.” The account does not specify the policy’s update mechanics, but it presents repeated simulated attempts as the basis for improving the walking behavior before it is returned to the local machine.
Camera feeds show the perception inputs; navigation is the operator’s claim
The simulation also includes Micro Duck’s cameras. Omniverse libraries simulate them, and the displayed view pairs the robot navigating obstacles with camera panels labeled RGB, depth and segmentation. Those feeds make the perception inputs visible alongside the simulated movement.
The operator says that “with perception and physics working together,” Micro Duck can avoid obstacles, navigate tight spaces and adapt to its surroundings. That is the stated capability; the camera panels show the kinds of simulated views included in the setup, rather than independently establishing each navigation claim. The distinction matters to the workflow: movement is trained in a physics simulation, while camera simulation is presented as teaching the robot to see.
Once the policy has been trained in the cloud, the operator downloads it to RTX Spark and evaluates it in Isaac Sim. Multi-robot orchestration provides a further test in the simulated course, including the single-file instruction over the north ramp. The final demonstration is the physical Micro Duck walking beside a laptop displaying the simulation. The sequence ends with deployment, but the operator’s account does not describe a separate measurement of the robot’s real-world performance.