CAD to ROS Project

[Edwards, Shaun M.]

All,

 

The ROS-Industrial Consortium is proposing a project that I think is of great interest to the broader ROS Community: Conversion of CAD data to ROS-interpretable file types (e.g. URDF, SRDF).  This is a very common problem for many ROS users, without an automated solution that I am aware of.  For more details, see http://rosindustrial.org/news/2015/7/20/proposed-cad-to-ros-focused-technical-project

 

If you are interested to learn more about the project goals or participating, please reach out to myself.

 

Shaun Edwards

Senior Research Engineer

Manufacturing System Department

 

 

http://robotics.swri.org

http://rosindustrial.swri.org/

http://ros.swri.org

Join the ROS-Industrial Developers List

Southwest Research Institute

210-522-3277

 

[jelle feringa]

Interesting project.

I've written a URDF exporter, converting a Rhino scene -> URDF package ;)
( which took a day, not three years btw ;)

I read the proposal, and the STEP oriented approach is the right idea IMHO.
In vendor neutral CAD files, only STEP has strong topology support, which is pretty essential.

Converting the CAD data -> convex mesh is also pretty straightfwd.

The main question for me is, how do you deduce a kinematic chain from geometry?
Mathematically its not difficult, but conventions here are important.

Image that you have a few axis systems in your CAD file, describing the kinematic chain of the robot.
How do you relay the chain, since you can't deduce the axis system from the geometry.

What's pretty tricky in terms of convention, is how to relay what these lines denominate in terms of kinematics.
The way I sidestepped this issue in the Rhino -> URDF exporter is simple by conventions of layers.
Simple by layer name, I would deduce the kinematic significance of a line describing an axis system ( the problem here is that a line along the Z-axis might by the X-axis of a frame in the kinematic chain... )

Rhino for example has excellent STEP output support and the meta data stored in the layer names containing the geometry works across STEP files too.
However, that convention might not work out, when exporting from say, SolidWorks.
So, exporting kinematic meta data from CAD is the culprint IMHO.

For the past ~7 years I've been involved developing pythonocc, which offers high-level functionality on top of the OpenCASCADE CAD kernel.
A stronghold of the project is excellent support for IGES and STEP files.
AFAIK, only OpenCASCADE ( OCC ) provides this functionality in open source ( lgpl ) code.

Best,

-jelle

[Bas de Bruijn]

On 7/28/2015 6:36 PM, jelle feringa wrote:

Interesting project.

I've written a URDF exporter, converting a Rhino scene -> URDF package ;)
( which took a day, not three years btw ;)

I read the proposal, and the STEP oriented approach is the right idea IMHO.
In vendor neutral CAD files, only STEP has strong topology support, which is pretty essential.

Converting the CAD data -> convex mesh is also pretty straightfwd.

The main question for me is, how do you deduce a kinematic chain from geometry?
Mathematically its not difficult, but conventions here are important.

I was wondering the same thing. I'm pretty clueless how vendor CAD geometry translates into the STEP format. But I think it would be a real pain to work with different models from different engineers who each have their own way of working. Engineers can be the most stubborn people around (I'm one, I know, every engineer is convinced their way is the right way). And then multiply the possibilities with the different CAD solutions. That's a huge effort getting everybody talking the same language.

I work with Solidworks exclusively for the past 15 years, so it was good to see Dassault mentioned in the paper.
Something to follow for sure.

Bas

Image that you have a few axis systems in your CAD file, describing the kinematic chain of the robot.
How do you relay the chain, since you can't deduce the axis system from the geometry.

What's pretty tricky in terms of convention, is how to relay what these lines denominate in terms of kinematics.
The way I sidestepped this issue in the Rhino -> URDF exporter is simple by conventions of layers.
Simple by layer name, I would deduce the kinematic significance of a line describing an axis system ( the problem here is that a line along the Z-axis might by the X-axis of a frame in the kinematic chain... )

Rhino for example has excellent STEP output support and the meta data stored in the layer names containing the geometry works across STEP files too.
However, that convention might not work out, when exporting from say, SolidWorks.
So, exporting kinematic meta data from CAD is the culprint IMHO.

For the past ~7 years I've been involved developing pythonocc, which offers high-level functionality on top of the OpenCASCADE CAD kernel.
A stronghold of the project is excellent support for IGES and STEP files.
AFAIK, only OpenCASCADE ( OCC ) provides this functionality in open source ( lgpl ) code.

Best,

-jelle

--
You received this message because you are subscribed to the Google Groups "swri-ros-pkg-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to swri-ros-pkg-d...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[G.A. vd. Hoorn - 3ME]

On 28-7-2015 19:10, Bas de Bruijn wrote:
> On 7/28/2015 6:36 PM, jelle feringa wrote:
>> Interesting project.
>>
>> I've written a URDF exporter, converting a Rhino scene -> URDF package ;)
>> ( which took a day, not three years btw ;)
>>
>> I read the proposal, and the STEP oriented approach is the right idea
>> IMHO.
>> In vendor neutral CAD files, only STEP has strong topology support,
>> which is pretty essential.
>>
>> Converting the CAD data -> convex mesh is also pretty straightfwd.
>>
>> The main question for me is, how do you deduce a kinematic chain from
>> geometry?
>> Mathematically its not difficult, but conventions here are important.
>
> I was wondering the same thing. I'm pretty clueless how vendor CAD
> geometry translates into the STEP format. But I think it would be a real
> pain to work with different models from different engineers who each
> have their own way of working. Engineers can be the most stubborn people
> around (I'm one, I know, every engineer is convinced their way is the
> right way). And then multiply the possibilities with the different CAD
> solutions. That's a huge effort getting everybody talking the same
> language.
>
> I work with Solidworks exclusively for the past 15 years, so it was good
> to see Dassault mentioned in the paper.
> Something to follow for sure.

I'm actually another one of those stubborn engineers (:)) who's going to
be involved in this project. So thanks for your feedback, and I thought
I'd add a few comments.

The reason we've opted to make this a bit longer than a few months is
exactly because of the point both Bas and Jelle bring up: how do you
automate something that has to work with data that is non-standardised
and is coming from multiple software packages that each have their own
issues wrt representation and storage of that data? I appreciate the
fact that a relatively straightforward converter wouldn't take 4 months
to implement (milestone 1 - part 1 is actually only 4 months, not 3
years :)), but that is only (a small) part of the project.

As the goal here is to create something that works for more than a
single CAD vendor's tools, we figured we'd include some time to first
properly research the current state of the art and support for various
features in existing tools. Based on that we'll map out how to approach
the kinematics issue, which could include adding additional metadata to
facilitate the conversion process.

Milestone 3 is actually optional right now: depending on the state of
the art at the time of conclusion of milestone 2, this may be something
that would still be a valuable thing to develop, or it would be better
to make use of some existing system.

>> Image that you have a few axis systems in your CAD file, describing
>> the kinematic chain of the robot.
>> How do you relay the chain, since you can't deduce the axis system
>> from the geometry.
>>
>> What's pretty tricky in terms of convention, is how to relay what
>> these lines denominate in terms of kinematics.
>> The way I sidestepped this issue in the Rhino -> URDF exporter is
>> simple by conventions of layers.
>> Simple by layer name, I would deduce the kinematic significance of a
>> line describing an axis system ( the problem here is that a line along
>> the Z-axis might by the X-axis of a frame in the kinematic chain... )
>>
>> Rhino for example has excellent STEP output support and the meta data
>> stored in the layer names containing the geometry works across STEP
>> files too.
>> However, that convention might not work out, when exporting from say,
>> SolidWorks.
>> So, exporting kinematic meta data from CAD is the culprint IMHO.
>>
>> For the past ~7 years I've been involved developing pythonocc

>> <https://github.com/tpaviot/pythonocc-core/>, which offers high-level

>> functionality on top of the OpenCASCADE CAD kernel

>> <http://opencascade.org/>.

>> A stronghold of the project is excellent support for IGES and STEP files.

>> AFAIK, only OpenCASCADE ( OCC ) <http://opencascade.org/>provides this

>> functionality in open source ( lgpl ) code.

I've been scoping out (and playing with) some libraries and I've found
PythonOCC and OCC to be very nice Jelle. STEP support is indeed impressive.


again thanks for your comments,


Gijs vd. Hoorn
DBL, DRI, 3mE, TU Delft
the Netherlands

[Bas de Bruijn]

Hi Gijs

Yes, I thought so, "TU Delft" triggered that :)

>
> The reason we've opted to make this a bit longer than a few months is
> exactly because of the point both Bas and Jelle bring up: how do you
> automate something that has to work with data that is non-standardised
> and is coming from multiple software packages that each have their own
> issues wrt representation and storage of that data? I appreciate the
> fact that a relatively straightforward converter wouldn't take 4 months
> to implement (milestone 1 - part 1 is actually only 4 months, not 3
> years :)), but that is only (a small) part of the project.
>
> As the goal here is to create something that works for more than a
> single CAD vendor's tools, we figured we'd include some time to first
> properly research the current state of the art and support for various
> features in existing tools. Based on that we'll map out how to approach
> the kinematics issue, which could include adding additional metadata to
> facilitate the conversion process.

I'm fairly fresh wrt. ROS in general, so please excuse my ignorance. I
might make some wrong assumptions wrt what's needed in the toolchain
from CAD to ROS.

I've done some SolidWorks API programming in the past (haven't touched
it recently though) and I think that if the an engineer can determine
where to put an coordinate system (which should definitely withing
his/her skills) and put it in the proper alignment, it's fairly easy to
have a macro/program traverse the feature manager tree and look for a
specific named Reference Geometry (like a named coordinate system). Then
save that SW assembly from that named coordinate system as a STEP file.
So the engineer should place an appropriate coordinate system, run the
program, and you're already "aligned" with one of the joints on a
prescribed origin.

If SolidWorks can do that, I can imagine NX, Catia, ProE, SolidEdge,
Inventor and whatnot self respecting CAD software can also do that.

If all else fails you could look into the STEP data with a STEP viewer
(PytonOCC ;) ) Select points / cylinders / planes / axes and use those
to further generate output from that STEP file.

But now we're too far ahead :)
Interesting times!

Cheers,
Bas

[Simon Schmeißer]

OpenRave is using Collada for everything, is this a viable approach for ROS as well? Collada 1.5 [1] added kinematics so most of the information in urdf/srdf should be covered. Also there are extensions for more robot specific stuff at openrave [2].

Is there a somewhat short/concise overview somewhere what features STEP supports etc? (The wiki page makes it sound like years of study would be needed to grasp all ISO documents?)

(Also hierarchical/modular srdf, like what XACRO is to URDF, would be really convenient. Ie composing a robot cell out of a robot srdf, a gripper srdf, (a belt srdf?) and one containing mostly the ACM for the whole setup)

[1] https://www.khronos.org/collada/
[2] http://openrave.org/docs/latest_stable/collada_robot_extensions/

[Maarten de Vries]

Hey,

On 29 July 2015 at 10:05, Simon Schmeißer <s.schm...@gmx.net> wrote:

(Also hierarchical/modular srdf, like what XACRO is to URDF, would be really convenient. Ie composing a robot cell out of a robot srdf, a gripper srdf, (a belt srdf?) and one containing mostly the ACM for the whole setup)

​Is there a reason you can't use xacro for srdf now? As far as I know it should work with all xml files, regardless of actual file contents.​ A quick test with an srdf file showed no problems.

Regards,

Maarten

[G.A. vd. Hoorn - 3ME]

On 29-7-2015 14:55, Maarten de Vries wrote:
> Hey,
>
> On 29 July 2015 at 10:05, Simon Schmeißer <s.schm...@gmx.net> wrote:
>> (Also hierarchical/modular srdf, like what XACRO is to URDF, would be
>> really convenient. Ie composing a robot cell out of a robot srdf, a gripper
>> srdf, (a belt srdf?) and one containing mostly the ACM for the whole setup)

>> <http://openrave.org/docs/latest_stable/collada_robot_extensions/>

>>
>>
> ​Is there a reason you can't use xacro for srdf now? As far as I know it
> should work with all xml files, regardless of actual file contents.​ A
> quick test with an srdf file showed no problems.

I'll respond later to the other mails, but a quick note: it's actually
SDF (Simulation Description Format), not SRDF (Semantic Robot
Description Format). See [1] and [2] respectively.

And yes: xacro will be happy to spit out anything you can express with
an XML file, so I don't see why SDF (or even SRDF, if you'd like) would
be a problem.


Gijs

[1] http://sdformat.org
[2] http://moveit.ros.org/wiki/SRDF

[jelle feringa]

Hi Guys,

Cool to see this thread evolving into an interesting discussion.

Thrilled to hear Gijs and Bas known about (python)occ, what a boost ;)

> how do you 

> automate something that has to work with data that is non-standardised 

> and is coming from multiple software packages that each have their own 

> issues wrt representation and storage of that data?

So Gijs framed the problem precisely.

Rather than to rely on metadata ( different for every other CAD platform ), I think it makes a _lot_ of sense to find a way to encode the kinematic definition in a geometric manner.

This as far as I can see, is the only way to relay such a definition, that will work from any CAD platform that supports STEP.

Perhaps the following might work:

1) create a polyline that who's points are the origins of the joints

2) at these joint origins, place a single line to define the Z-axis of the joints

3) single lines that dont overlap with the point in the polyline, are considered errors.

4) question: consider a point on the polyline. is the vector from the current -> previous point and the current -> next point geometrically meaningful, in terms of defining the axis system for the joint at that point? 

if either one is ( the current point -> next point vector is meaningful I think ), than we're basically there.

Then its very simple to filter the single lines in the STEP files, and correlate these to the points of the polyline describing the chain.

IIRC scipy.spatial has bindings to qhull, so once loaded in (python)occ, that would be a way to get the convex hull of the mesh ( I didnt bother, FCL can handle non-convex input / creates the convex hull from your triangle soup ) 

I think Simon has a point: Collada is IM(pedantic, rarely solicited)O a better choice to describe robots in. 

Than again I'm an ISO fanboi when it comes to 3d data, and Collada is the ISO standard for Industrial automation systems and integration, where STEP is the ISO standard for CAD. 

Anyway, once you have the right STEP file, its pretty trivial creating collada file from there ( courtesy of pycollada ), so why not be inclusive.

Best,

-jelle

[G.A. vd. Hoorn - 3ME]

These sort of things is exactly why we feel a bit of time at the start
of the project is needed: using STEP as an 'intermediary format' seems
like a good idea, but it is not clear whether the current generation CAD
tools have good enough exporters for the format. SolidWorks fi has had
STEP support for quite some time, but kinematics and especially metadata
such as GD&T are big unknowns.

We'd like to avoid creating separate plugins / macros for all the
targeted CAD packages. Maintenance would be a nightmare, as we'd have to
track API changes in 6 to 7 different platforms at the same time.

What you describe above is essentially part of what the current
SolidWorks to URDF exporter does. Perhaps we'll end up with forcing
users to adhere to some conventions, or require them to setup specific
coordinate origins. This is all doable, but will still ultimately depend
on how well this is then exported to STEP.

> If SolidWorks can do that, I can imagine NX, Catia, ProE, SolidEdge,
> Inventor and whatnot self respecting CAD software can also do that.
>
> If all else fails you could look into the STEP data with a STEP viewer
> (PytonOCC ;) ) Select points / cylinders / planes / axes and use those
> to further generate output from that STEP file.
>
> But now we're too far ahead :)
> Interesting times!

certainly.

Thanks again for your comments,


Gijs

[G.A. vd. Hoorn - 3ME]

On 29-7-2015 10:05, Simon Schmeißer wrote:
> OpenRave is using Collada for everything, is this a viable approach for ROS
> as well? Collada 1.5 [1] added kinematics so most of the information in
> urdf/srdf should be covered. Also there are extensions for more robot
> specific stuff at openrave [2].

Hi Simon,

as you can find in the proposal pdf, we'll also consider Collada. It's
already used in ROS in some places (mostly for simple mesh storage
though) and converters to urdf have been part of ROS ever since I can
remember (collada_to_urdf, etc).

Especially since version 1.5 with the addition of kinematics it seems
like a good format to use, and its native support for custom data using
the 'extra' tag is also a good feature.

However, Collada support in many of the CAD packages is far from
ubiquitous, making it less ideal for use as an intermediary format.
Using it to replace URDF is an enticing idea, but would require quite
some changes to core ROS components.

> Is there a somewhat short/concise overview somewhere what features STEP
> supports etc? (The wiki page makes it sound like years of study would be
> needed to grasp all ISO documents?)

There are numerous sites that provide overviews of STEP and its many
Application Protocols (see [3] for a site describing AP242 fi).

If you really want to know what is going on, I'm afraid reading the
actual documents is the only way.

> (Also hierarchical/modular srdf, like what XACRO is to URDF, would be
> really convenient. Ie composing a robot cell out of a robot srdf, a gripper
> srdf, (a belt srdf?) and one containing mostly the ACM for the whole setup)

As we're mostly going to be dealing with automated conversion, I imagine
we'll be leaving the decision on how to modularise a particular model to
the user. After conversion it'd be up to you to decide how and where to
instantiate any models, but that is no different from how things are
done now.


Gijs

PS: I've already mentioned this, but just to be clear: SRDF is for
MoveIt (and is not meant for describing geometry nor kinematic
structure). I think you meant to write SDF, the format Gazebo uses.

> [1] https://www.khronos.org/collada/
> [2] http://openrave.org/docs/latest_stable/collada_robot_extensions/

[3] http://ap242.org

> Am Dienstag, 28. Juli 2015 15:42:04 UTC+2 schrieb Edwards, Shaun M.:
>> All,
>>
>>
>>
>> The ROS-Industrial Consortium is proposing a project that I think is of
>> great interest to the broader ROS Community: Conversion of CAD data to
>> ROS-interpretable file types (e.g. URDF, SRDF). This is a very common
>> problem for many ROS users, without an automated solution that I am aware
>> of. For more details, see
>> http://rosindustrial.org/news/2015/7/20/proposed-cad-to-ros-focused-technical-project
>>
>>
>>
>> If you are interested to learn more about the project goals or
>> participating, please reach out to myself.
>>
>>
>>
>> Shaun Edwards
>> Senior Research Engineer
>> Manufacturing System Department
>>
>> http://robotics.swri.org
>> http://rosindustrial.swri.org/
>> http://ros.swri.org
>>
>> Join the ROS-Industrial Developers List

>> <https://groups.google.com/group/swri-ros-pkg-dev/boxsubscribe>
>>
>> Southwest Research Institute
>> 210-522-3277

[G.A. vd. Hoorn - 3ME]

On 29-7-2015 16:34, jelle feringa wrote:
> Hi Guys,

Hi Jelle,

I like your imaginative geometric approach. You have to keep in mind
though that many consortium members have an existing library of models
describing their parts, cells and machines that they'd like to use with
any tool we may come up with. It is a bit impractical to require them to
go in and change things around just so our converter can nicely deduce
the kinematic structure from the geometry :).

As I wrote before, we purposefully included time to research possible
alternatives and we'll certainly try to keep an open mind. We could also
reach out to the community whenever we feel there is an opportunity for
improving things wih more input.

> I think Simon has a point: Collada is IM(pedantic, rarely solicited)O a
> better choice to describe robots in.
> Than again I'm an ISO fanboi when it comes to 3d data, and Collada is the
> ISO standard for Industrial automation systems and integration

> <http://www.iso.org/iso/catalogue_detail.htm?csnumber=59902>, where STEP is
> the ISO standard for CAD <https://en.wikipedia.org/wiki/ISO_10303>.

> Anyway, once you have the right STEP file, its pretty trivial creating
> collada file from there ( courtesy of pycollada

> <https://github.com/pycollada/pycollada> ), so why not be inclusive.

As I wrote in my reply to Simon, Collada is definitely interesting. And
as you mention, there is good support for Collada as well as STEP in
various existing libraries. It is certainly something we'll keep in mind.


Thanks,

Gijs

[pierino...@gmail.com]

Dear all,
 do you have any news on this topic?

Thank you,
Best regards

[Victor L]

What is the status of this project?
What can we do with it now?

A screenshot, video overview would be nice :)