Currently the ROS publisher for CarMaker publishes at a rate with respect to wall-clock time, I was wondering if it would be possible to publish at the rate the simulation is running at. Say the simulation is running at 2x real-time and the sensor updates at 200 Hz, would it be possible to automatically have the ROS publisher publish at 400 Hz, or is the sensor running at real-time and not simulation time? Furthermore, I was also wondering what nCycleOffset means in the CM ROS node.
Hello Onish,
I’ve tested this in the ROS1 and ROS2 interface that was released last week. In ROS1 the wall-clock time is used for publishing, but in ROS2 the simulation time is used. I will speak to the developers of the CMRosIF today to understand whether something in ROS1 has limited the implementation in this way. It’s quite possible considering there are significant differences in ROS2 to enable async services and real-time support.
The nCycleOffset should govern the offset of publishing the data (in ms) of a specific topic. If a CM sensor publishes information at 30ms, 60ms, 90ms,… an nCycleOffset of 5 would hopefully cause the ROS messages to actually go out at 35ms, 65ms, 95ms, …
Hi Onish,
I got a reply on this.
In the CMRosIF parameters file, there are two relevant parameters here, Node.UseSimTime and Node.nCyclesClock
Node.UseSimTime is TRUE by default. This not only publishes the clock from CarMaker, but also means that message frequency is actually measured against the simulation time as well. Therefore, having a sensor publish at 30Hz means that you should always see a message frequency of 30Hz no matter what the sim speed is.
Node.nCyclesClock is the timestep for publishing the clock. If your publisher is triggered by listening to the clock topic, this should naturally be shorter than the cycle time of your publisher. We ship the project with a time of 100ms, but you can actually bring that down to 1ms which is the CM execution step time.
I’ve tested everything here by setting UseSimTime to 0 and manually publishing a clock topic from elsewhere. Then changing the sim speed also changes the publishing rate because this is now measured against an independent “wall clock” that is completely external to the sim.
In this process, however, we did find a bug in the ROS2 implementation. With UseSimTime=1, ROS2 publisher rate should not change no matter what the sim speed is, but currently it does. We will investigate why this is happening, but it should not affect the ROS1 implementation.
One final note. The behaviour in ROS2 is not a bug, it’s actually based on the fact that global parameters are no longer a thing. Therefore, setting the use_sim_time node parameter in the CMNode does not set this in RQT (or any other node for that matter). This makes it an “error” in reporting, not in publishing. If RQT receives the correct use_sim_time parameter that matches the CMNode one, it will report correctly.