Isaac PoseTree Inconsistent worldTrobot - Carter Sim

Hi all,

This is an issue I had tacked on to the end of a previous issue of mine (see here for original context https://devtalk.nvidia.com/default/topic/1057359/simulation/issues-getting-accurate-odometry-from-isaac-sim/) that I felt deserved its own issue as I am still confused as to how this has happened.

My basic problem is as follows. I am trying to get the ground-truth position of the robot at any given time when it exists within the simulator. I have thought to do this through using worldTrobot as accessed via the PoseTree. From how I understood things, the PoseTree was supposed to be the “final say” in the relative poses for robots, their sensor arrays and the world therefore I would be able to get my ground-truth locations.

First off am I incorrect in my understanding of things as stated above?

Secondly, through testing my system and printing the output of worldTrobot, I am seeing minute but constant changes in the pose over time when the robot is kept completely stationary (using the joystick for movement and not touching the joystick at all). Is this to be expected and if so why? I thought that the simulator would be able to give absolute ground-truth accuracy.

It is also worth noting that things like robotTleft_camera are completely stable.

I would be really appreciative of any help that can be provided.

Details of setup used above

Testing in Hospital Map with personalized code that should not move the robot at all (entirely dependent on joystick controls).

Code for getting robot pose (print pose is simplistic code written to visualize pose):

std::optional<Pose3d> temp_robot_pose = node()->pose().tryGet("world", "robot", node()->clock()->timestamp());
      if (temp_robot_pose){
        std::cout << "--------------------------------------------------------------" << std::endl;
        print_pose(*temp_robot_pose);
        std::cout << "==============================================================-" << std::endl;
      }

worldTRobot at 0:
Translation: {X: 48.3276, Y: 5.37442, Z: 0}
RPY: {Roll: -0, Pitch: 0, Yaw: -0.131987}
Quaternion: {W: 0.997823, X: -0, Y: -0, Z: -0.0659456}

worldTRobot at approx:

Translation: {X: 48.2667, Y: 5.37686, Z: 0}
RPY: {Roll: -0, Pitch: 0, Yaw: -0.114357}
Quaternion: {W: 0.998366, X: -0, Y: -0, Z: -0.0571474}

Trends seen above (e.g. translation X decreasing) continued as time went on.

OK after examination myself I am splitting this into two parts.

The first is continued over on this issue [url]Carter Sim Joystick Drifts Without Input Commands - Omniverse Isaac Sim - NVIDIA Developer Forums and talks about the random drifting that happens with carter when using the joystick.

My principle concern in this issue now is how much jittering there is in the signal.

The motion of the robot appears quite smooth when left to its own devices, however, the poses I get fluctuate continuously around the main trend of the motion like some level of random noise is being applied.

Is this to be expected or is there some parameter which is generating noise that I have missed somewhere?

  1. PoseTree is a collection of poses, but any codelet can write to it or read from it.

  2. The frame names are user-defined, but by default world_T_robot is not the ground truth. It is typically the localization result written by, for example, ParticleFilterLocalization. Thus, minor fluctuations are expected.

If it exists (you can see the poses in the PoseTree window of Sight), robot_gt frame would give your the ground truth. So, what you are looking for would be world_T_robot_gt. I believe this pose is written with flatsim and Unity based simulation, but not with Unreal based simulation, which you are using for the Hospital scene. However, you can extract the ground truth from the RigidBody3GroupProto message Unreal simulator is supplying. Please check the definition of RigidBody3GroupProto in messages/ directory to see how to parse this message.

  1. robot_T_left_camera would be typically constant determined by user depending on the robot. It would not change.