Clarification on Goal-Reached Condition and Role of ego_speed

[Shailesh-Pawar-12]

• While exploring the XMobilityNavigator, I noticed that there doesn’t seem to be an explicit check to confirm if the robot has reached its goal.
• The model publishes velocity commands, but I couldn't find a condition that stops the robot upon reaching the target position.
• I also observed that ego_speed is updated from odometry, but it doesn’t appear to be used for verifying if the robot should stop.
• Is the goal-reached condition handled entirely by model inference, or is there a check I might have missed?
• Could you clarify the role of ego_speed in the stopping behavior?
• I’d really appreciate any insights on this. Thank you!

[nv-liuw]

@Shailesh-Pawar-12 Yes, goal reaching is handled implicitly by the model. When the robot arrives at the destination, the model naturally outputs zero speed to stop it. This behavior emerges because the model is trained using examples from a teacher policy, allowing it to learn and imitate when and how to stop based on those demonstrations.

[Shailesh-Pawar-12]

Hi @nv-liuw,

Thanks for your response!

I wanted to clarify my understanding of ego_speed. Currently, it is updated using odom_msg.twist.twist.linear.x, but the robot’s state also depends on angular.z, which doesn’t seem to be incorporated. Am I misunderstanding what ego_speed represents?

Additionally, if I have an omnidirectional robot, would it be possible to include the linear.y component as well?

• Would integrating linear.y affect the model’s performance or stopping behavior?

• What modifications would be needed to properly include it?

Looking forward to your insights. Thanks again!

[nv-liuw]

@Shailesh-Pawar-12 Great question, the arXiv paper needs update. We started experiments with 2-dimensional speeds including linear forward and angular z, but turns out encoding linear forward speed only produced better results according to the ablation studies, so we only kept the linear speed: odom_msg.twist.twist.linear.x.

To encode other robot velocity states, like linear.y, you can modify the dataset loader and the speed_encoder by updating the current input channel size from 1 to the new input dimension size. You might want to properly normalize each speed state also.