Thanks for this REP, I think that this is very important! I have many questions though.
A canonical repository of open-source, compliant simulation assets is to be established as
ros-simulation/openusd-assets. These assets will have payloads hosted independently (e.g. in a dedicated repository such as Hugging Face) and must pass the Compliance Checker.
This is interesting to me. Are robot OEMs encouraged to upload assets there? Is the intention to have these assets distributed to places like the NVIDIA asset library directly from the repo? Or is this just another place to put the same assets? Which payloads would be hosted independently? Mesh data only? What is the reason for having payloads hosted independently?
I also wonder how closely this REP aligns with NVIDIA’s authoring guidelines (which are linked in the REP). I know that NVIDIA employees helped with this REP, but would something following this REP automatically be following guidelines for the NVIDIA asset library, you would just need to pick and choose which layers/payloads to use?
This question may not have a straight answer, but for robot OEMs, would the expectation be that we would run our URDFs through the asset importer and do it that way? Or would we export directly from whatever CAD software to USD and make tweaks afterwards?
Regarding asset importers (I am particularly interested in the URDF asset importer myself)
- Will the asset importers automatically create the ETL pipeline/different layers? Or will that mostly be done manually?
- Will asset importers do “extended physics” changes that aren’t natively supported by OpenUSD?
- Will asset importers automatically change from Euler angles to quaternion?
I guess my real questions is “where does the responsibility of the asset importers end”
My assumption is that a typical 6-axis robot is a “component”. But if a robot has sensors natively built in (cameras, force torque, etc) is that considered to be a “component” or an “assembly”?
Joints that close a kinematic loop (e.g., parallel linkages, four-bar mechanisms) must set physics:excludeFromArticulation = true.
In the case of say a 4 bar mechanism, would just one joint be excluded? How do we know which (passive) joint should be excluded? Or is it arbitrary?
glTF 2.0 is heavily referenced here, but as I mentioned in ROS2 URDF Mesh File Types , is still not standard for URDF (the asset importer doesn’t even support it right now). I like glTF 2.0, and I don’t think that this is a massive problem as it is supported in many ROS 2 workflows, but I just wanted to point it out
Is there a standard for link frames? Specifically, it seems that there are 2 common ways in the ROS 2 world of handling link frames/TF. One has all TFs aligned in the same orientation as the world frame. The other one has the TF based on the DH parameters. Are both of these acceptable?
@peci1 already mentioned this, but it would be good if there were some conforming models that we could look at as reference. Ideally some of these conforming models would include non-standard serial manipulator features, like backlinks, balancers, or mimic joints.
I realize that blender was already recommended, but is there a gold-standard USD editor that won’t have any sort of vendor-specific changes? I know about usdview, but would the typical workflow just be text editing + usdview or what?