Onshape  →  .urdf

Onshape to URDF

Onshape lives in a browser and so does its route out: a command-line tool reads the document through the API and writes the description, without exporting anything by hand.

The export itself happens in Onshape

This site does not read Onshape files. The conversion is done by onshape-to-robot — MIT, from the Rhoban robotics team, at github.com/Rhoban/onshape-to-robot. 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

Name the mates the tool is meant to read

Degrees of freedom are taken from mate connectors following a naming convention — a prefix marks which mates become joints. Assembly structure you did not name stays rigid, which is usually what you want and occasionally is not.

Give it API keys and the document

The tool authenticates against Onshape and pulls the assembly directly, so the source of truth stays the document rather than a file somebody exported last Tuesday. Re-running it after a design change is one command.

Choose what the collision geometry should be

It can emit the full mesh, a convex hull per part, or shapes you mark up in the document. This is the decision that determines whether your simulation runs at real time or at a tenth of it.

Check the result before it reaches a simulator

Open the URDF in the viewer here with its mesh folder. The kinematic tree in the panel is the fastest way to see whether the mates you named became the joints you meant.

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.

Mass that came from a material nobody set

Onshape computes mass from part materials. A part left without one is assigned a default, and the description states the result as fact. The check flags any link whose implied density falls outside what robot parts are made of, in kg/m³, so a plastic bracket claiming the density of lead is visible immediately.

A tree that came out as separate bodies

If a mate that should have become a joint was not named, the parts it holds together arrive unconnected. The check reports how many separate bodies the file describes rather than one robot, and names them.

Joint limits that were never stated

Mate limits do not always survive the trip. A revolute joint with no limit is not merely undocumented: the specification requires one, and every controller downstream invents its own. Each such joint is listed.

Centre of mass outside the part

A wrongly placed origin puts a link's centre of mass somewhere it cannot be. The check compares each centre of mass against the size of the link's own geometry and reports the distance in centimetres — the kind of error that makes a robot lean in simulation and look fine on screen.

Check the export

The masses. Onshape computes them from part materials, and a part nobody assigned one to still arrives with a mass and an inertia tensor stated as fact.

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 Onshape, in this order:

  1. Mass and density. Each link's implied density in kg/m³ is compared against what robot parts are actually made of. A bracket claiming the density of lead came from a default material, not from your design.
  2. The kinematic tree. Joints came from mates you named. The tree in the panel shows which mates became joints — and whether anything arrived as a separate body because its mate was not named.
  3. Joint limits. Mate limits do not always survive. A revolute joint with no limit is one every controller downstream will guess about differently.
  4. Centres of mass. Drawn against the geometry they belong to, because a centre of mass sitting outside its own part is a robot that will lean in simulation and look perfect on screen.

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