Physical AI is no longer science fiction.

We already had a digital version of our robot: a detailed model built in Fusion 360. But to bring this twin to life in a simulation, especially in PyBullet, we needed something more: a URDF version of the robot.

fusion2urdf

I loaded a script called fusion2urdf. This is a Fusion add-in meant to export your model directly into URDF format, which is what simulation environments like PyBullet or Gazebo expect.

Fusion 360 scripts are written in Python and hook into Fusion’s API. Here’s a basic example:

def run(context):
    ui = None
    try:
        app = adsk.core.Application.get()
        ui = app.userInterface
        ui.messageBox('Hello from Fusion script!')
    except:
        if ui:
            ui.messageBox('Failed')

You can use this to automate CAD operations, create geometries, or export files. 

When I encountered errors with fusion2urdf, I opened up the script’s source code and added a bunch of ui.messageBox() calls to quickly debug what was going on. Sometimes the simplest tools can be the most effective way to track down issues.

Some of its limitations

Nested components weren’t supported, so I had to destroy my component hierarchy just to get the export working. It renamed components that were connected by joints — every single one was renamed to new_component, which completely broke the logical naming scheme. 

For my next project, I’ll either modify the script to fit my needs, or write my own fusion2urdf exporter from scratch.

xacro2urdf 

After the chaos, I ended up with a Xacro file from the fusion2urdf script — a common intermediate format in the ROS ecosystem for robot modeling. 

Xacro stands for XML Macros. It’s essentially a smarter version of URDF. A way to write more modular robot descriptions. It was developed as part of the ROS (Robot Operating System) toolchain to make maintaining complex robots easier.

In ROS workflows, you typically write your robot model as a .xacro file and then convert it to .urdf using a simple command like:

xacro robot.xacro > robot.urdf

Biped robot suffers

As you can see, it is missing servos. They were rigid joints in Fusion, but I couldn’t see them in the xacro file I moved on so I wouldn’t fall behind schedule.

Why it was a bad idea for sim2real

1. Impulsive Design

This robot was a rush job. I just wanted to see it move. But like in a great movie, where every frame should serve the story; in robotics, every design choice should serve a function. I want to test reinforcement learning with robots that have a well-thought-out mechanical design next time, not just whatever looks cool in Fusion.

2. No Feedback from Servos

This wasn’t even a typical sim2real problem. because I wasn’t even getting servo feedback. The robot had no way to know the actual joint positions during motion. That means whatever gait it learns is basically “manual”. It assumes the servos always end up exactly where they’re told to go, with no delays or mechanical errors.

That said, if I were to continue developing this design for sim2real reinforcement learning, the IMU would likely become the star of the policy — adjusting the walking trajectory in real time based on the robot’s orientation and balance.

But still… at least it can do reverse side splits: