Exported STLs are in incorrect (Global?) Coordinate System

[BenArtes]

Solidworks 2019 SP3:

Note: I'm a software developer who is working with Mechanical Engineers to get our models out of SW and into ROS so I don't have much experience with Solidworks, I'll summarize what I believe about Solidworks so that you know my thought process

Description

We're trying to export a robot model with multiple sub-assemblies and sub-sub-assemblies etc. The model is quite complex and due to some mating issues the automatic coordinate system / axis generation has been having trouble determining the correct coordinate systems / axes. In general we'd rather specify them manually anyway so that we have full control over placement etc, so we've decided to manually create coordinate systems / axes for control and to get around the automatic detection issues we've been having.

The robot has multiple repeated parts so to simplify the creation of coordinate systems / axes we've added them to the sub-assemblies. This worked well and the URDF Tree Export Configuration window allowed us to select the specific sub-assembly coordinate system / axis we wanted to use for each link / joint.

Unfortunately when exported and viewed in RViz / Gazebo the model is not being assembled correctly. Importing all of the exported STLs into MeshLab the model is assembled correctly, so it appears that all of the STLs are being exported in the same (assumed global) coordinate system.

Things I've tried:

• First looked at previous issues Exporting mesh with wrong origin #73 and Bug with function CreatePoint
• Noticed that Solidworks 2019 API SaveAs was Obsoleted so updated to SaveAs2
• Noticed swFileSaveAsCoordinateSystem has been obsoleted since Solidworks 2017 API; not sure what to change
• Noticed that SaveSTL sets coordinate system from none unique geo name so duplicated all coordinate systems so that each was uniquely named (but still specified in sub-assembly).

When reference geometry is created in the top-level its name is name, but when created in a sub-assembly the sub-assembly must be referenced in the name to specify it: name<sub-assembly>.

The SaveSTL function takes the coordinate system name and breaks it into the geo and component portions, then calls SetLinkSpecificSTLPreferences so it can set the STLExport Coordinate System (via swFileSaveAsCoordinateSystem), but it only passes the geo portion of the coordinate system name.

• Tried calling SetLinkSpecificSTLPreferences with the full (geo+<component>) name.

None of the above resolved the issues.

Unfortunately, I can't share the Model; we could potentially try to recreate the issue with a test model, but I wanted to check if we were running into known behavior.

For now we're going to test a version of the model with all geometry specified in the Top Assembly.

[brawner]

Please let me know if specifying top level geometry fixes the issue. I haven't been aware of any issues related to the sub-assembly geometry feature, so it would be good to know they exist.

Also, I can't really help debug or try to find the issue unless I have access to a model that reproduces the issue. My email address is [email protected] if you'd like to communicate privately.

[BenArtes]

We recreated all of the Coordinate Systems and Axes in the Top-Level assembly, converted the URDF tree to use those instead, and everything exported fine.

Two Notes:

1. Using Top-Level Coordinate Systems make a bit more sense for us as many of the assemblies were rotated which made the coordinate systems confusing. Creating them all in the Top-Level avoids these issues, so it seems to be a better fit for us currently anyway.
2. If these was a function that allowed me to pass a coordinate system name string and returned the selected coordinate system (with the same selection rules as swFileSaveAsCoordinateSystem) then I'd be happy to poke at this a bit to see exactly what was getting tripped up. If you happen to know of a function like that I'll give it a go, unfortunately I haven't found it in my search of the Solidworks API and don't have much time to dig deeper.

[brawner]

Excellent! I'm glad it worked for you, but might mean there is something strange going on.

When the STL is saved, you just have to set the preference with the coordinate system name.
https://github.com/ros/solidworks_urdf_exporter/blob/master/SW2URDF/URDFExport/ExportHelper.cs#L494

That coordinate system name is constructed from its display name here:
https://github.com/ros/solidworks_urdf_exporter/blob/master/SW2URDF/URDFExport/ExportHelperExtension.cs#L1201

Its display name is constructed from the feature name and component name here:
https://github.com/ros/solidworks_urdf_exporter/blob/master/SW2URDF/URDFExport/ExportHelperExtension.cs#L1207

[brawner]

Oh and importantly, here is the method for taking that display name and getting the one in the SW model:

https://github.com/ros/solidworks_urdf_exporter/blob/master/SW2URDF/URDFExport/ExportHelperExtension.cs#L928

[BenArtes]

Just to be clear:

• SaveSTL is called with Link and link.Joint.CoordinateSystemName = coord_sys<subassembly1>
• This coordinate system name is then turned in a dictionary called names by GetComponentRefGeoNames which is different from the FindRefGeoNames that you linked to above.
  • The names dict has two entries names["geo"] = coord_sys and names["component"] = subassembly1
• The swFileSaveAsCoordinateSystem preference is then set to names["geo"] which is equal to coord_sys without the component.
  • Effectively, SetLinkSpecificSTLPreferences('coord_sys', link.STLQualityFine, ActiveDoc);

So the STL has been set to save as coord_sys using a preference string, how does this get resolved to the coord_sys<subassembly1> reference geometry?

[brawner]

In short, I'm not entirely sure. I would have to look at this in VS and dig into SW's API a bit more, but this definitely looks worthwhile a fresh investigation. It's been awhile since I looked at this bit of code.

It might be a quirk of SW's API or it may be a bug in my code.

[BenArtes]

Okay 😃

As I said, We're gotten everything up and running now so my issue has been resolved. If you do take a look at this again, re-read my first post as I've summarized some of the things that have changed in the Solidworks API.

And I'll keep subscribed to this issue (or feel free to reach out) if there's anything I can do to help.

[brawner]

Closing issue. Let me know if you have any related issues.