`get_world_poses()` and `set_world_poses()` getting/setting orientation OUTSIDE of the `base_link`

[dhajnes]

get_world_poses(), set_world_poses(), get_local_poses() and set_local_poses() all provide/set orientation of an arbitrary link on the robot instead of getting/setting the orientation in the middle of the prim (the base_link). Getting or setting, therefore, moves the robot around the knee on his left leg instead of around the middle of the base.

I believe this may be caused by a problem I described in another issue.

This is an unexpected behavior. My robot is a bit special because it contains loop closure and therefore a joint excluded from articulation - I don't know it that is relevant.

Please provide some suggestions on what could be the source of this problem.

[dhajnes]

When I remove the loop closure - the joint excluded from articulation, this problem seems to go away. Therefore I guess the order in which are the robot parts loaded is important.

Therefore the linked issue is also important, the robot's orientation shouldn't depend on the order of links loaded into simulation!!

With loop closure in place:

>>>> self._metadata.link_names:  ['rear_left_link_10', 'rear_left_link_2', ... ... ...]

Without loop closure:

>>>> self._metadata.link_names:  ['base_link', 'front_left_link_1', '... ... ...]

[Mayankm96]

This might be relevant here: https://github.com/NVIDIA-Omniverse/urdf-importer-extension/pull/1

[kellyguo11]

Hi there, yes this is because when adding in a loop closure, the parsed topology will be different as the loop link introduces a new node in the graph with a higher weight. To workaround this issue, make sure the ArticulationRootAPI schema is applied to the root body prim (the prim for the root with RigidBodyAPI applied), which should guarantee the root link and parsed topology.

[dhajnes]

Thank you both, I made a workaround to this problem by directly wrapping the prims named base_link in my robot into a RigidPrim() and then accessing its location directly without falling back to the default root assigned at import (idk which import, whether its the problem with the urdf importer or the USD importer from .usd file into the simulation environment... The thing is that when I open the USD in Isaac sim, the rotation is ok, but there is no Articulation in bare isaacsim.) Not using this workaround would make my life easier at spawn time.

When I check which part of the prim is understood as the root, when the ArticulationView is asking whether is_not_root_link at the base_link it says its not a root. Although it does say so on the "name of the robot". So do you suggest that I should put default_prim on the base_link in my topology in IsaacSim, rather than on the robot_name xform?

I provide as an example the anymal_instancable.usd. Do you mean that the anymal should not be the defaultPrim, but rather the base? (I have another robot with a loop closure) So this works only because the anymal doesn't have a loop closure?

[kellyguo11]

Yes, that's exactly correct. For floating-base robots, it is recommended that the ArticulationRootAPI be applied on the root link of the robot instead of the parent xform. Similarly, the paths provided for the View classes should also point to the root link, where the ArticulationRootAPI is. You can check out the Ant environment for an example of this.

[dhajnes]

Okay, I got the ArticulationView to point to the my_robot/base_link instead of only my_robot, but my problem still stands. In IsaacSim I wasn't able to put the defaultPrim to the base instead of anymal (see the picture I posted above), and I suppose that is what you meant by:

it is recommended that the ArticulationRootAPI be applied on the root link of the robot instead of the parent form.

Do you have any suggestion why I couldn't do that? Or is it only possible to do that by editing the .usda human-readable format of the .usd file? I am very wary of editing raw .usda files ...

NOTE for clarity: by floating-base robot, you meant a robot that is not fixed to the floor, in contrast to fixed robot such as Franka, right?

[kellyguo11]

Sorry, I think I misunderstood the defaultPrim in your previous comment with ArticulationRootAPI. The defaultPrim does not have to be modified as it does not affect the physics parsing, only the prim that contains the ArticulationRootAPI schema should be modified. You can update the ArticulationRootAPI from the UI by selecting the prim where the ArticulationRootAPI is currently defined at, and removing the ArticulationRootAPI from the properties window. Then, select the base link of the robot, and add the ArticulationRootAPI by right-click or also through the properties window. We also identified a bug in the physics parsing related to articulations with joints that are excluded from articulation and are working on a fix.

Yes, a floating-base robot is one that is not fixed to the world/floor.

[dhajnes]

Hi @kellyguo11 , any news on the bug fix? Any ETA?

[kellyguo11]

Hi there, your current workaround should be the correct solution to the issue. We will make the changes in the URDF importer available when the pull request is accepted.

[dhajnes]

We will make the changes in the URDF importer available when the pull request is accepted.

In the URDF importer? I would like to note that I am importing a USD model into OIGE, not a URDF. I suppose you are mentioning the URDF importer in the OIGE, not the utility extension in Isaac Sim, right?

Is the URDF importer logic similar/same to the USD importing? In other words, will this pull request resolve the physics importing problem for the USD as well? I am mostly asking because I couldn't close the articulation loop in the URDF as the URDF tree structure doesn't allow that, therefore I went with Isaac Sim's USD. If there was an option to somehow import the URDF with a closed-loop articulation I would have used the Isaac Gym Preview.

[dhajnes]

@kellyguo11 when I change the ArticulationRoot API from the uppermost prim (Anymal) to (base) the loop closure stops working. I don't know why that is, maybe it relates to the bug you mentioned.

When I put the articulation root on the base after removing it from the Anymal the legs that contain the loop closure refuse to go to a set place (drive goal). When I return the ArticulationRootAPI through the UI to the uppermost prim, the loop closure works again. Therefore your suggestion

You can update the ArticulationRootAPI from the UI by selecting the prim where the ArticulationRootAPI is currently defined at, and removing the ArticulationRootAPI from the properties window. Then, select the base link of the robot, and add the ArticulationRootAPI by right-click or also through the properties window.

doesn't seem to solve the issue. The workaround still partly works, but the spawning is incorrect, because the physics parsing in OIGE somehow thinks that some arbitrary joint (not Anymal, nor base) is the root and whenever I set this joint in the beginning it not only rotates the joint on the robot, but equally rotates the WHOLE robot.

[kellyguo11]

Hi there, the change in the URDF importer will correctly apply the ArticulationRootAPI to the base prim instead of the parent xform, but this change will only affect any new assets imported from URDF to USD. The placement of the ArticulationRootAPI will in turn affect the physics parsing in Isaac Sim. Is it possible to share the asset you are having issues with and we can follow up with the physics team?

[dhajnes]

SOLVED

Hi, just to follow up on the problem previously, when importing our URDF to USD in the newest IsaacSim 2023.1.1, the usd is imported differently than in 2022 version. The weird spawning problem that occured previously is now gone (we switched to ORBIT instead OIGE).

Therefore I call this issue closed, where the solution is to install the newest IsaacSim, import the original URDF into the USD again, do stuff you need (in our case closing an articulation loop via a RevoluteJoint excluded from articulation) and then replace the usd in your simulator with this new one. Thank you for all your input @kellyguo11.