How to convert a SolidWorks assembly to URDF

SolidWorks can't export URDF on its own. Here's the manual add-in workflow, the mistakes that cost people an afternoon, and the faster automated route.

Guide · ~6 min read

URDF (Unified Robot Description Format) is the XML format ROS, Gazebo and MoveIt use to describe a robot's links, joints, inertia and collision. SolidWorks models the same robot as parts joined by mates — but there is no native "Save as URDF". You have two options: the manual exporter, or an automated converter.

Option 1 — the sw2urdf add-in (manual)

The community sw2urdf add-in is the classic path. In outline:

1. Install the SolidWorks-to-URDF exporter add-in and open your assembly.
2. For every link, assign a reference coordinate system and a reference axis at the joint location. This is the step that determines whether your joints end up correct.
3. Build the link tree in the exporter: choose the base link, then nest each child link and name its joint.
4. Pick a joint type per joint (revolute, prismatic, continuous, fixed) and set limits.
5. Export. The add-in writes the URDF, meshes (STL) and a ROS package layout.

Where it goes wrong

• Joint axes. If you don't place an explicit reference axis at a joint, the exporter guesses — and a revolute joint spins around the wrong axis. This is the single most common bug.
• Inertia. The exporter reads mass properties from SolidWorks, so your material assignment has to be right. For 3D-printed parts the solid-density assumption over-estimates mass (see our inertia guide).
• Frames at the part origin. Joint frames belong at the hinge, not at the part's modeling origin — otherwise links pivot around the wrong point.
• Collision meshes. The visual STL is reused as the collision mesh by default, which is slow in simulation. You usually want simplified convex collision shapes.

Option 2 — automated conversion

If you'd rather not hand-place a coordinate system on every link, an automated converter reads the geometry and mates for you. This is what Jointly does: it ingests the SolidWorks assembly (or a STEP export of it), infers the moving parts, joint types and axes, computes inertia and generates collision meshes, and lets you confirm the few things a static model can't reveal — joint travel and which joints are motorized.

What survives a STEP export (and what doesn't)

A common situation: a client sends you a STEP file, not the native SolidWorks assembly. STEP carries exact B-Rep geometry but drops the mates entirely. So joint relationships have to be re-inferred from the geometry. Manual exporters can't help here — there are no mates to read. Jointly is designed for this mate-less case and recovers joint axes directly from the boundary geometry.

Verifying the result

However you generate it, sanity-check the URDF before trusting it:

• check_urdf my_robot.urdf to validate the XML and tree.
• Load it in RViz or Gazebo and jog each joint — confirm every axis rotates/translates the way the real robot does.
• Check the total mass and center of mass against the real hardware.

Getting axes and inertia right is the whole game. A URDF that loads but spins the wrong way is worse than none.