Roadmap to add a custom robot

[Birkenhain]

Hey everybody,

I’m trying to bring the open-source robot arm SO-101 into the Visose Robots plugin.
To give this post more long-term value, I’ll phrase my questions in a more general way so that others can benefit later too.

Easy scenario

Manufacturer already supported by the plugin
→ see existing RobotSystems

Exact model not present in the plugin

To do:
Follow Install local library
to create a local template.

Get a .step of your robot and convert it to .3dm (one mesh per segment, naming consistent with template).

Extract Denavit–Hartenberg values (d and h in the .xml). Manufacturers often provide them, otherwise measure in CAD (example explanation: YouTube
).

Add axis ranges and max speeds to the .xml. Names must match the .3dm.

Hard scenario

Manufacturer not yet supported by the plugin
→ see existing RobotSystems

Exact model not present

Assumption 1:
You still need .3dm and .xml, but not all DH parameters are represented there. Some (α, θ) live in the manufacturer files. If the robot doesn’t fit an existing manufacturer file, you’ll need to create your own.

Assumption 2:
With Assumption 1, you can simulate the robot, but you can’t yet generate usable code. You also need a fitting postprocessor
. If none exists, you’ll have to write one.

Assumption 3:
If you achieve Assumption 1 + 2, then you can use your custom robot like any other in the plugin.

My question

@visose – could you please verify whether Assumptions 1–3 are correct?

And to everyone: would anyone be interested in tackling these tasks with me? I think quite a few users would enjoy having a 3D-printed, open-source robot that is fully compatible with Grasshopper!

My own coding skills are limited, but there is extensive documentation for the SO-101 here
. Someone more experienced might be able to judge whether it’s worth pursuing and possibly collaborate.

Thanks a lot for any guidance or interest!

Best regards,
Julian

[visose]

Hi, almost but not exactly:

You still need .3dm and .xml, but not all DH parameters are represented there. Some (α, θ) live in the manufacturer files.

Each manufacturer provides default values for α, θ (and signs), but you can override them in the XML. Defaults are only used if they are omitted from the XML.

The key point is the kinematics solver used. Each solver is tied to certain robot families, and some might not even use all DH parameters. For example, ABB and KUKA share the same solver, while UR uses a different one. You cannot use the ABB solver on UR robots.

you can simulate the robot, but you can’t yet generate usable code.

You can simulate unsupported robots only if their kinematics match an existing solver. For instance, if KUKA wasn’t supported, you could simulate it by configuring it as ABB in the XML, but it would still generate RAPID code as you say.

Regarding postprocessors: you can now write your own directly in a Grasshopper scripting component, without recompiling the plugin. Just create a class that implements IPostProcessor, output an instance from the scripting component, and connect it to the Load RobotSystem postprocessor input. Easiest way is to copy an existing one from GitHub and adapt it.

[MassimoVisona]

Hi,
I am trying to add a custom robot model similar to a Doosan robot. Could you please share an example of how the XML file should be structured to define the α, θ, and sign parameters?

Thank you very much for your support.

[visose]

Hi, you can find example XML with Doosan robots here: https://github.com/visose/robots/tree/libraries
α, θ, and sign parameters are optional and can be added to each joint Revolute xml element. If not specified it uses the default's robot manufacturers values, usually you don't need to speficy them.