I followed the tutorial to import the ClearPath jackal with a front laser. After I attached the TF tree publisher in an Action Graph, its tf tree turns out to be this:
Hi,
the documentation for USD articulation root states this:
Articulations
Earlier we mentioned that we support reduced coordinate joints, which require some additional specification. We decided to do this with a minimal extension of the above maximal joints. Any prim of the USD scene graph hierarchy may be marked with an UsdPhysicsArticulationRootAPI. This informs the simulation that any joints found in the subtree should preferentially be simulated using a reduced coordinate approach. For floating articulations (robotics jargon for something not bolted down, e.g. a wheeled robot or a quadcopter), this API should be used on the root body (typically the central mass the wheels or rotors are attached to), or a direct or indirect parent prim. For fixed articulations (robotics jargon for e.g. a robot arm for welding that is bolted to the floor), this API can be on a direct or indirect parent of the root joint which is connected to the world, or on the joint itself. If there are multiple qualifying bodies or joints under an UsdPhysicsArticulationRootAPI prim, each is made into a separate articulation root.
This should in general make it possible to uniquely identify a distinguished root body or root joint for the articulation. From this root, a tree of bodies and joints is identified that is not to contain loops (which may be closed by joint collections). If loops are found, they may be broken at an arbitrary location. Alternatively, a joint in the loop may use its excludeFromArticulation attribute flag to denote that it wishes to remain a maximal joint, and at this point the loop is then broken.
Now to translate this into how its parsed in Omniverse. If you apply the articulation root directly to a body or joint (based on the articulation floating/fixed), than that is directly saying where the articulation root is. However if the articulation root is applied to some top level prim, which is usually the case for IsaacSim robots, then the parsing gets the whole graph and finds the best candidate for the articulation root. For PhysX simulation we pick:
a) Fixed articulation – thats the base link connected with a fixed joint
b) Floating articulation – we pick the body with the most childs
So if you want to fully control where the articulation root should be, you would have to move the UsdPhysics.ArticulationRootAPI from the top level to the body itself.
Regards,
Ales
Thank you for answering me the question. I found that the articulation root is in the physics tab and changing the articulation root solved the problem. But another problem arised when I tried to control the velocity of jackal through the omni Graph with ROS geometry/Twist message, I’ll reproduce the this later.
Ok, here is the another question: When I configure the Omni Graph for my 4 wheeled Jackal AGV in Isaac Sim, the default Articulation Root is the root of the USD(the top level Prim in Isaac Sim, here is World/Jackal) model, but it is wrong in the tf tree. But under this configuration the Omni Graph can subscibe the geometry/Twist msg from ROS and successfully transform the msg to wheel speeds of 4 wheels. But when I set the Articulation Root to base_link(correctly in URDF), the Omni Graph failed to transform the Twist to wheel speeds. The simulator says
OmniGraph Warning “NoneTygpe” Object has no attribute “is_homogeneous”
here is my 4 wheel robot cmd_vel Graph:
Not sure how much I can help here, the missing attribute is_homogeneous does not come from physics schema. This looks like to be some custom attribute for some reason, no idea where that comes from.
Maybe the Articulation Controller node needs a path adjustment to the right articulation root of it was moved?
Sorry I might not be able to help here much.
Ales
is there a joint connecting your base_link to your chassis_link? It looks like all the joints are connected to the chassis_link. I suspect when you put an articulation root on the parent prim, it’ll go down the prim hierarchy and look for all the joints, but when you place it on a link that’s parallel in hierarchy to the link that has all the joint connections, it might not find the joints.
There has a connection between base_link and chassis_link, and you are right that all the joints (except front laser and some links mounted on mid_mount) has the same parent node: base_link, this is common in both robotic arm and UGV. I got a reply from another employee that Isaac Sim would automatically pick a node which with the most child nodes as the root of TF tree if you set the Articulation Root as the root Prim of the robot. So it’s a dead game now, if I set the Articulation Root to the “base_link” the TF would be correct, but I cannot control the motors as it cannot parse the geometry/Twist msg. Once I set the root Prim as the Articulation Root I can control it but the TF is incorrect.
We did have this problem before, but I thought we fixed it. Which version of Isaac Sim are you using? The latest version should be 2023.1.0. If it still in that one, we’ll file a bug report.
If setting chassis_link as the articulation root works, then it might be because your base_link doesn’t have any rigid body attached to it. If your base_link is just a frame and has no physical object attached, but you must use it for articulation root for TF reasons, then you can potentially get around this by adding a very small and light mesh to the frame, and add a physics->rigid body to that prim.
and also make sure the update the articulation root target for the articulation controller every time you change the link that articulation root is attached to.
Ok, I will test this configuration on Isaac Sim 2023 when I have spare time. I’ve been using Isaac Sim 2022 all the time, hope it is just a bug in version 2022.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.
