Michel Hidalgo
Michel Hidalgo
One potential workaround would be to relax [the definition of a ready `rcl` timer](https://github.com/ros2/rcl/blob/7723308e7c7f7515590bd709525fd840b4aed254/rcl/src/rcl/timer.c#L300) using a platform specific time tolerance, and even make that configurable for a user to tune...
Alternatively, since it's quite likely not every possible timer period can be achieved due to time resolution constrains, the expectation on `rcl` timers' period could be relaxed to be just...
CC @ivanpauno @wjwwood @peterpena
That is true for a plain sleep, but arguable for a time deadline (and even more so if you want to sustain some periodicity, but that's unrelated to `rmw_wait()`). And...
> This is also a condition we could check for and at least log something about it. Or even we could go back to sleep if needed. That's fair for...
> Thus, I think the logic in rcl to decide the rmw_wait duration isn't valid, and can be problematic in all platforms. There's that too, yeah. And waking up earlier...
> To be fair, on a non-realtime OS, all timer periods are a rough lower bound. That is true. Not sure about embedded ROS though. > At least, that's not...
Oh well, I guess we agree to disagree. In any case, we have an `rmw_wait()` that may return too early and an `rcl_timer_t` that depends on it not doing that....
@neil-rti maybe you can weigh in here.
With https://github.com/ros2/rmw/pull/275, `rmw_wait()` API documentation now mentions this little timing detail. I still have to benchmark modified timers in #707 though.