-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Timed Behaviors do not adhere to Sim Time #3303
Comments
Good question, I don't see any reason why we couldn't do that. Yes, chrono is C++ system time independent of ROS / simulation times. You'd probably need to update not only the behaviors themselves, but the TimedBehavior header class which also uses chrono to dish out behaviors. You should get the clock object from the root node so that it can use real/ros time as the node is set appropriately. We used steady time because the ROS clock isn't guaranteed to move forward or be regular. There are certain things in the stack (e.g. server timeouts, BT node rate controllers) which should probably use wall time instead. I think there can be an argument for the behaviors to be moved to ROS time, that seems sensible. I think it would just be important as you're changing code in the behavior server to ask yourself "how could this go wrong?" and make sure to handle any edge cases that could be introduced if the clock either stopped or moved backwards (so B-A could be negative). @jwallace42 any objection? @bobbleballs would you be open to contributing this? |
Nope, this sounds like a good change to me! |
Great, thanks for your input. I'll have a look into this with your recommendations. |
Any updates 😄 |
@bobbleballs what do you think? |
Sorry I've been swamped with other work and this hasn't been as blocking as I expected. |
More general, by grepping where we are using
|
Update: The usage of
|
Hi there, I have just faced with this issue too during using the MPPI. I have a simulation environment which 2-3 times slower that real time, so when the MPPI controller shifts the control sequence by 1 step it means that 50 ms passed, however, it passed only 15-20 ms in sim time. And it produce a bad performance of the controller. Are there any plans to align the Nav2 with simulation time? |
I'm experiencing the same as above except in my case my simulation is a lot slower than real time (about 20% of real time), which means that behaviours time out too quickly. My initial thought was to change the time-outs so that the controller (using the dwb planner) has enough time to actually see the change. But I can't find any time outs to change. |
@AlexeyMerzlyakov similar question here; are these points all addressable now? I'm not asking you to do it, but rather that all of the necessary changes in rclcpp are now in so I can do it / ask a community contributor to help on this one |
In ROS2 new
|
Bug report
Operating System:
Ubuntu 22.04
ROS2 Version:
Humble
Version or commit hash:
0d86469
DDS implementation:
Steps to reproduce issue
I have an issue where I am running a simulation at greater than real time speed. My simulation platform (Flatland2D) is publishing sim time on /clock and use_sim_time is set on the Nav2 launch procedure. My issue is that my behaviour tree contains some waits, and backups however these behaviours occur at real time not sim time.
Expected behavior
Timed behaviours will work to sim time not real time. e.g. in a simulation running at 2x speed with a wait of 10 seconds I would expect this to take 5 Seconds.
Actual behavior
Waits take the real length of time.
Additional information
I've had a look at nav2_behaviors/plugins/wait and back_up and it looks like wait uses a steady_time from chrono which calls now(). I don't know much about chrono but I'm guessing this gets an accurate system time?
nav2_behaviors/include/timed_behaviors.hpp also uses
rclcpp::Clock steady_clock_{RCL_STEADY_TIME};
which I presume does something similar?For the behaviours to adhere to use_sim_time these behaviours should be using
RCL_ROS_TIME
I think? Would this have any negative effects. I'm not sure if steady_time was used for a reason? Ideally I am trying to make the behaviour of the navigation stack at high sim rates as accurate as real time so this is a blocker to me.The text was updated successfully, but these errors were encountered: