Resolution of ros::Duration::sleep() limited by implicit sleep in nanoseconds about roscpp_core HOT 6 CLOSED

What you mention makes sense 👍. I hope that this issue's info can be useful for future travelers of the ROS1 code, or authors of ROS2.

Thank you for the feedback @MatthijsBurgh 💪

from roscpp_core.

When running at such a high frequency of 400Hz, I would think WallDuration/WallTime is better.

from roscpp_core.

Hi @MatthijsBurgh,

I have tried your suggestion. However, running in WallTime means that any high-rate module will not listen to the updates of ROS Time. Thus, if you slow down, speed up, or pause

• Replaying of a ROS bag,
• Simulation,

The nodes' notion of time will be different from that of the sensor and actuator clocks, leading to ambiguous results (e.g. if simulation is running slower, should a filter propagate as usual, or wait for the next clock tick?). Furthermore, if you have Time-based events, they will be triggered at the wrong instant. Thu, Breaking away into a different time domain can increase the number of issues, but not solve the problem at the root.

Practical example
Imagine that you have a swarm-drone system that relies on accurate, time-sensitive motion planning. If you want to test this system in simulation, with WallTime, you need to ensure that your simulator will run at exactly the same rate as your host PC Clock (1.0x, uniform, constant), otherwise your whole motion planning algorithm will have to 'fight' uncertain timing (which is a problem that you can solve in the real world with a GPS)

(Image source: https://gfycat.com/handmadecolossaldrongo-hotcoffee9520)

Hence, that's why my suggestion goes into the direction of making the minimum wait time an optional argument.

WDYT?

Best,
Yoshua

from roscpp_core.

I agree with you. The WallTime doesn't slow down. I expected your process to be time critical, because of the high frequency.

I think your case with such a high frequency, but want to sync with the ROS time, is very rare. And as ROS1 is going to the end of its life, I don't expect the maintainers to change it.

from roscpp_core.

I can imagine a PR along these lines could get merged: compare the intended sleep duration with the 1 ms sleep, and if one tenth of the intended duration is shorter than the 1 ms, shorten the wallsleep to this one tenth. This should not affect most normal use-cases, but should help your cause.

from roscpp_core.

@YoshuaNava #137 should help with this. Could you verify?

from roscpp_core.