SolidWorks  →  .urdf

SolidWorks to URDF

An assembly becomes a robot description through the ROS exporter add-in, which reads your mates and writes a package of meshes and a URDF. Then comes the part nobody tells you about: what it got wrong.

The export itself happens in SolidWorks

This site does not read SolidWorks files. The conversion is done by sw_urdf_exporter — BSD, maintained in the ROS ecosystem, at github.com/ros/solidworks_urdf_exporter. What follows is what the export needs from you, and then the half that is ours: what these exports get wrong, and how to find out which of it happened to yours.

Getting a description out

Give every joint an axis and a coordinate system

The exporter does not guess where a joint is. For each one you create a reference axis for it to turn about and a coordinate system for its origin, and name them so the pairing is obvious later. This is most of the work, and it is the part that decides whether the robot comes out sensible or scrambled.

Set materials, or the masses are fiction

Mass and inertia come from SolidWorks' own mass properties, which come from the material assigned to each part. A part left as the default gets the default density, and the URDF will state that mass as confidently as any other number in the file.

Export as a ROS package, not as a lone file

The output is a folder: a urdf/ directory, a meshes/ directory of STL, and the package files ROS expects. The URDF points at the meshes through package:// paths, which is why the folder has to travel with it.

Look at it before you simulate it

Open the result in the viewer here and turn on link frames and collision. Two minutes of looking catches the failures below, and every one of them is cheaper to fix in CAD than in a simulator that is behaving strangely for no visible reason.

What comes out wrong, and how you find out

A CAD export produces a file that opens, renders and looks like your robot. The failures below are the ones that survive that impression and show up later as a simulation behaving strangely for no visible reason. Each is a check this site runs on a model you open — not a warning to keep in mind, a line naming the link or the joint.

Mesh paths that only work on the machine that wrote them

Exports routinely contain absolute paths, or package:// references that resolve only inside a ROS workspace. The check flags both, and names the files: a colleague who opens your model outside ROS sees a robot with no geometry at all.

Collision geometry that is the display mesh

The exporter can write the same STL for visual and collision. It loads, it looks right, and every contact test in the simulator now runs against a hundred thousand triangles per part. The check says which links do this.

Inertia copied across links that are not alike

When mass properties are missing the exporter falls back, and identical inertia blocks turn up on parts of different shapes. Mirrored limbs sharing inertia is expected; two unrelated links sharing it to the last digit is a copied block, and it is called out separately from the mirrored case.

Parts overlapping in the exported pose

If the assembly was mated at an origin the exporter did not expect, links intersect in the pose the file declares — often by tens of millimetres. The check measures the overlap between parts that are not neighbours and reports it in millimetres, because a simulator will start by trying to push them apart.

Check the export

Whether the meshes travel. A SolidWorks export is a ROS package, and the paths inside it are written for a ROS workspace — which is where models from this route most often arrive as an empty scene on somebody else's machine.

Drop the URDF and its mesh folder into the viewer. Nothing is installed and nothing is published; the file is read to draw it and deleted after a day. For a model out of SolidWorks, in this order:

  1. The meshes. If the scene is empty or half empty, the paths did not survive the trip out of the workspace they were written in. The panel names the files it could not resolve.
  2. Collision against visual. The exporter will happily write your display STL as the collision shape. Simplified collision is normal and wanted; a hundred thousand triangles per part is a simulation that runs at a tenth of real time.
  3. Link frames. Every joint here came from a reference axis and a coordinate system you made by hand, so a frame built the wrong way round is the likeliest single mistake in the whole export.
  4. Inertia ellipsoids. They should follow the shape of each part. Identical ellipsoids on parts of different shapes mean a mass property that was never set and a fallback that was.

Then send it further: convert to MJCF and run it in the physics lab, where a robot that cannot hold itself up says so in the first second — or author a movement in motion and find out whether the motors your CAD material implies can actually perform it.

Other CAD packages