Can we simulate a real robot?

Simulating a real quadruped robot is less about flashy graphics and more about getting physics, joint control, and data flow to behave consistently—then building a small “action loop” that can be repeated and later learned. The core breakthrough here is a working pipeline: import a Bittle URDF into NVIDIA Omniverse Isaac Sim, ensure gravity and contact physics actually apply, and drive the robot’s joints from Python so motions like standing and jumping can be tested without manual clicking.

The process starts with Omniverse Isaac Sim and the Bittle robot model. Because there’s no ready-made URDF for the specific quadruped used, the workflow relies on a URDF repository for Bittle and a matching mesh directory structure so the simulator can find geometry. After importing the URDF, the robot initially drops into the scene abyss—until a ground plane is added and joint targets are manipulated. Manual joint driving proves the model is wired correctly, but the goal quickly shifts to code-driven control.

That code path runs through “joint monkey,” a Python-based example environment tied to Isaac Gym-style assets. The first major physics win comes when the URDF used by the ball-based physics examples is swapped from a ball model to the Bittle URDF, producing a “Biddle bomb” where legs bend and collisions behave under gravity. A key fix is changing a “fix base link” setting: leaving the base fixed prevents the robot from behaving like a physically simulated body. With that corrected, gravity works—but a new problem appears in Isaac Gym: the robot slides unnaturally even when no commands are issued. Adjusting friction helps only partially and introduces tradeoffs that could destabilize later dynamics.

Switching to Isaac Sim resolves the sliding mismatch. After saving the scene as a USD and manually placing the robot into a standing posture (instead of the URDF’s kneeling default), the robot no longer drifts. The remaining challenge becomes documentation and discoverability: clear examples exist, but they’re easy to miss. Once the right Python sample directory is found, the workflow becomes practical—load the scene, locate joint prim paths, and articulate joints programmatically.

From there, the project builds a minimal control system: one script writes a joint-position vector to a NumPy file, and another script runs continuously, reading that file and setting each joint’s target position in a loop. This “live file” approach is acknowledged as jitter-prone and likely not ideal for real-time control, but it enables fast iteration. With joint control working, the project defines simple poses (stand, crouch, tall) and a jump routine that interpolates joint targets using an increment-per-step scheme to avoid overshooting and flipping.

The result is a repeatable jump that works in simulation—sometimes even better than the hand-tuned attempt due to initial conditions. The next step is to replace manual pose scripting with machine learning for walking or other complex behaviors, with the long-term aim of transferring the learned policy to the physical Bittle robot, despite the inevitable hurdles in sim-to-real transfer.