Increase /clock frequency

[iluetkeb]

Description

The current default frequency for /clock is 10Hz, which gives 100ms clock resolution for the "now()" call. This is very coarse and represents a huge difference to most real-world robots, where the usable clock precision is in the microsecond range, and also to ROS1, where it used to be 1ms, IIRC. Since all nodes need the sim_time, increasing the frequency has a cost, of course, therefore a balance needs to be found between precision and message sending overhead.

There is a parameter for changing this, but I would say that the default should be reasonable, and in my considered opinion, 10Hz is not reasonable for the reasons outlined above.

Expected behavior

I would suggest to increase the default frequency to 1000, to mimick ROS1 behavior.

Environment (please complete the following information):

• gazebo_ros_pkgs: up to master

[iluetkeb]

btw, I should add that we couldn't figure out a way to actually use the parameter "update_rate". There doesn't seem to be a way to pass it to the plugin.

[ivanpauno]

The "update_rate" is being throttled, there's another parameter called "publish_rate":

gazebo_ros_pkgs/gazebo_ros/src/gazebo_ros_init.cpp

Lines 174 to 176 in 204abd4

	auto rate_param = impl_->ros_node_->declare_parameter(
	"publish_rate",
	rclcpp::ParameterValue(GazeboRosInitPrivate::DEFAULT_PUBLISH_FREQUENCY));

Did you try that one?

The default is 10Hz, modifying it sounds ok to me.

This sounds like a lack of docs problem to me, I'm not sure where to document this though...

[tim-fan]

Hello, just to add my comments because I am having similar issues (using ros foxy).

Regarding the use of the publish_rate param, I've tried setting that following this guide, without success. (i.e ros2 topic hz /clock shows 10 Hz, regardless of publish_rate setting.

BTW I'd say if clock rate is intended to be configurable, it would be nice to expose it as a launch arg in gazebo.launch.py and gzserver.launch.py.

The inability to set the clock rate is causing problems for me, because as far as I can tell, the clock publish rate limits the rate at which rclpy publishers can spin. For instance, when running examples_rclpy_minimal_publisher/publisher_local_function.py unmodified and with use_sim_time:=true, the publisher publishes at 2Hz. But if I set timer period to 0.05 for a 20Hz loop rate, the publisher only publishes at 10Hz (the gazebo clock publish rate).

I'm not sure if this limiting of spin rate is expected behavior, or an rclpy bug. In any case I have a node that I'd like to run at 50Hz, and because I can't figure out how to configure the gazebo clock publish rate, my only solution atm is to change the default clock rate in gazebo_ros source and recompile.

[iluetkeb]

[publish_rate]

Did you try that one?

We tried that one as well, but the issue is that we cannot pass ROS parameters on the Gazebo command line. For other plugins, their parameters are given in the SDF (when the plugin is used for some model part), but this doesn't work for initial parameters.

[ivanpauno]

But if I set timer period to 0.05 for a 20Hz loop rate, the publisher only publishes at 10Hz (the gazebo clock publish rate).

That doesn't seem related to gazebo, just rclpy not being able to track the timer period correctly.

[joshnewans]

@tim-fan Were you able to find any workaround?
I aslo have had no success setting the publish_rate as per that guide (i.e. creating a params file and executing gazebo -s libgazebo_ros_init.so __params:=/tmp/params.yaml).

I also agree that this is something that should be exposed by the launch files.

[tim-fan]

Hi @joshnewans, I was not able to set clock rate via params either (maybe this should be listed as a separate issue).

For now I'm building the #1214 branch from source, until that gets merged/released.

[jacobperron]

#1391 has made it more convenient to set ROS parameters (including publish_rate) from the launch file. The wiki has also been updated with the commands to set parameters from the command-line; the __params:= syntax is outdated.

[scpeters]

This appears to be resolved. Please reopen if the issue persists.