Feature: Support for "vendor part DBs"

[guru-florida]

As a beginner user (I am not), I would like a simpler way to construct robots (URDF files) without requiring CAD skills, knowledge of inertias, masses, XYZs, RPYs. Especially when, but not limited to, using parts from any vendor's "erector set".

I would like to get feedback on a proposed solution I am working on:

I propose we add a few extensions to the xacro tool that can simplify the <link> and <joint> blocks for robot kits. To distill it down to a minimum, these extensions are a way to load URDF xml fragments from remote repositories. I use vendor loosely. You can load parts remotely from any publisher on git-hub or http URI or design your own local parts.

We start with a fragment something like this in our xacro/URDF to define where our external resources are:

<repositories>
	<repository name="erector" src="http://robots-r-us.com/ros2/parts" />
	<repository name="lidar" src="git://<git-url>" />
	<repository name="mystuff" src="package://my_package/myparts" />
</repositories>

Each repo is a part DB. Each part has a name, STL/DAE url, inertia data and most importantly a list of named attachment points. Each attachment point has related transform and type info (fixed, rotational, linear, axis). Parts are URDF fragments so may also include other stuff like gazebo or ros2-controls fragments. Now we can build robots using simpler xml like this:

<part sku="erector:torso-1" link="base_link">
	-- loads torso-1 part# from 'erector' repo
	-- no attachment point specified here
	-- optionally add more xml that goes into the output URDF
	<more-xml-content ...>
</part>

<!-- these parts attach to a parent using a pre-defined attachment point by name
        (attachment points defined in vendor part description) -->
<part
    sku="erector:BA101"
    link="left-shoulder"
    parent="base_link"
    attachment="A" />
<part
    sku="erector:Servo_HT1"
    link="left-shoulder-servo"
    parent="left-shoulder"
    attachment="Horn1"
  <!-- arguments passed into part template just like xacro:macro -->
    min="-1.5"
    max="1.5"
    />
<part
    sku="erector:BA104B"
    link="humerus"
    parent="left-shoulder-servo"
    attachment="C" />
<part
    sku="erector:Servo_HT1"
    link="left-humerus-servo"
    parent="humerus"
    attachment="Horn1"
    min="-1.5"
    max="1.5"
    />
<part
    sku="erector:BA101"
    link="radius"
    parent="left-humerus-servo"
    attachment="B" />

The 'parent' and 'attachment' attributes translate into a <joint> and the rest into <link>. Attachment points are unique to each part and defined in the vendor part file. User can still define thier own or custom transform if a pre-defined attachment point doesnt exist.

I could make this a standalone tool but xacro already has a useful set of processing macros/functions and I think this feature really fits into the purpose of xacro.

I havent laid out the part format. I like yaml, but since a part is basically a templated URDF fragment it makes more sense to define the parts in an XML doc, but it could still use xacro's external yml support if the repo developer wants to keep their own parameters in a yml file.

As you can see no coordinates needed, no inertia, no physics or even STL/DAE required. Servos, erector set hardware, Lidars, IMUs and other predefined URDF blocks can be imported where the complicated stuff is pre-defined. I certainly had a high learning curve/barrier getting to know URDF, colcon, ros2-cli, launch files and a buggy Solidworks plugin (which I am still grateful to have). Fortunately, I got over the hump and love Ros2 and eventually rewrote my own URDF with xacro but I can see how new users can struggle. I and a few others would like to make the barrier a bit easier.

Any effect to current Xacro users?
No, this feature should be optional and cause no side effects to existing xacro files. Only if a <repositories> block exists in the URDF would external data and/or part DBs be downloaded and placed on the user's hard drive. I'm not sure where the local repo cache would go (suggestions?). The user would be responsible for vetting a vendor's part files. Perhaps at some point a part catalog web site might exist to help users discover parts.

Thoughts?

[rhaschke]

Thanks for this interesting suggestion. To discuss such general questions, you might want to go for https://discourse.ros.org though. For me, it just looks like you are shifting the "complex" stuff into a database, making it even harder to access for users. How can a user know, which attachment points or even which parts exist? In any case, all tags should be prefixed with a xacro namespace.

[guru-florida]

Posted to discourse:
https://discourse.ros.org/t/xacro-support-for-repository-based-building-blocks-like-vendor-part-dbs/20381

Yes, I am shifting it into a database but I wouldn't say it is harder for users to access. The database would be xacro xml itself, with the parts defined like existing xacro macros so they are still free to copy out and modify.

As for knowing the attachment points that's a good point and this is the sort of feedback and ideas I am looking for. Possibly documentation could be generated? The file has the STL and attachment transforms, so maybe something equivalent to how urdf_to_graphviz works could transform a repo into a PDF document with part info and visual diagrams.

[rhaschke]

Closing due to inactivity.

[guru-florida]

I have made progress on this. I added a few generic features to the code and using those I can implement the feature purely in xacro macros. I've just been preoccupied with another part of the project.

[rhaschke]

I'm happy to hear this. I'm looking forward to your PR 😉