Closed reinzor closed 2 months ago
Could you elaborate on the purpose for this? ros_gz
is meant to be used with Gazebo, so I would think use_sim_time
would always be true, but maybe there are other use cases?
Sure, we have two reasons for this:
/clock
topic for each running node in our ros2 set-up, introduces a lot of CPU load, especially for the python processes. This is more related to the performance of ros2 but in some cases and on some platforms, we can only run proper simulations if we set use_sim_time
to false
. Any thoughts @azeey ?
Those seem like good reasons to me. My only concern is that we don't break any existing users since use_sim_time
is assumed to be true for ros_gz by default. Is there a way we can ensure that the parameter is true if not set explicitly by the user?
Thanks for your reply @azeey , I don't think we can and I don't think we should modify the default node behavior:
Here the parameter is set to false
by default.
This line:
will simply ask the node whether the simulation time is active.
Well, that would be a blocker then since it will likely break existing users. What about using additional parameter or environment variable to enable checking use_sim_time
?
What about adding indeed an additional parameter, e.g. use_wall_time
that defaults to false
and log a warning when it is conflicting with node->ros_time_is_active()
? In order to supress this warning, the user should align these two parameters, either:
use_wall_time=true
, use_sim_time=false
use_wall_time=false
, use_sim_time=true
And in the implementation, we use the value of the use_wall_time_parameter
. What do you think?
Or make this new behavior default as per ROS2 Jazzy. As breaking changes are typically allowed between distros.
ping @azeey
The job of the bridge is to convert messages from Gazebo to ROS. It shouldn't really have its own concept of time. The timestamps are provided by Gazebo. Overwriting this timestamp with some other value should be an opt-in, so I would not be in favor of changing the current behavior. I would support adding a use_wall_time
parameter, better yet, a override_timestamps_with_wall_time
parameter. But I don't think it should give a warning in the default case, but your suggestion seems like it would, i.e, the default is override_timestamps_with_wall_time=false
, use_sim_time=false
. Do we really need to align the parameters? Can we not simply check override_timestamps_with_wall_time
?
For me just adding the override_timestamps_with_wall_time
parameter is fine. Thanks for your elaborate reply. I will update my PR accordingly and publish it.
What are your thought about running the bridge with
use_sim_time
false
? Would you be open for a PR like this: https://github.com/gazebosim/ros_gz/pull/545Please give me your thoughts.
Thanks!