Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add timer on reset callback #995

Merged

Conversation

mauropasse
Copy link
Contributor

@wjwwood this PR is created after discussions originated from this PR: #966
Instead of adding an on_trigger callback to the rcl guard conditions, we add here an on_reset callback to the rcl timers.

The issue which originated this need, is wake up an events based executor when a timer is reset (which could also be caused by a time jump).

FYI @alsora

Signed-off-by: Mauro Passerino <mpasserino@irobot.com>
rcl/include/rcl/timer.h Show resolved Hide resolved
rcl/include/rcl/timer.h Show resolved Hide resolved
Signed-off-by: Mauro Passerino <mpasserino@irobot.com>
@timonegk
Copy link

@wjwwood @clalancette It would be very nice to merge this and #995 soon. We are trying to use https://github.com/irobot-ros/events-executor/, but it requires these pull requests, and manually rebuilding rcl and rclcpp with the pull requests merged is not sufficient because the rclcpp pull request includes ABI changes that require a rebuild of all packages using TimerBase. It also seems as if the comments on both pull requests have been addressed.

@Flova
Copy link

Flova commented Nov 24, 2022

Another ping on this one due to the breaking ABI changes and the need to build nearly everything from source as a consequence if the events executor is used in a single node.

Also I think you mean ros2/rclcpp#1979 @timonegk right?

@Flova
Copy link

Flova commented Nov 24, 2022

As the maintainers were updated recently also a frindly ping at @audrow and @ivanpauno

@ivanpauno
Copy link
Member

ivanpauno commented Nov 28, 2022

The issue which originated this need, is wake up an events based executor when a timer is reset (which could also be caused by a time jump).

Could you explain that in more detail?

@mauropasse
Copy link
Contributor Author

mauropasse commented Nov 28, 2022

Could you explain that in more detail?

There are two situations in which a wait-set based executor can be awaken when something changes related to the timer, by means of triggering its guard condition:

  1. Timer is reset:
    rcl_ret_t ret = rcl_trigger_guard_condition(&timer->impl->guard_condition);
  2. Timer detects a time jump:
    if (RCL_RET_OK != rcl_trigger_guard_condition(&timer->impl->guard_condition)) {

Before these same situations, the on_reset_callback is called.
Maybe a new on_time_jump_callback could be created, along the on_reset_callback.
In the current state, the on_reset_callback is used for both purposes.

@ivanpauno
Copy link
Member

Timer is reset:

I think we trigger the guard condition because the timeout used in rcl_wait() wasn't calculated considering that timer.
A callback isn't trigger immediately when a timer is reset.
Based on that, I'm not sure if you would need to trigger a callback in this case for the events executor.
But if it's needed I think it's fine to add it.

Maybe a new on_time_jump_callback could be created, along the on_reset_callback.

IMO, that sounds better.
It's weird to have a on_reset callback that's also triggered on jump.
Could the clock jump callbacks be used for that though?

Signed-off-by: Mauro Passerino <mpasserino@irobot.com>
@mauropasse
Copy link
Contributor Author

Could the clock jump callbacks be used for that though?

Yes, no need to add an extra callback for it.
I removed the callback call on _rcl_timer_time_jump. That function is actually used as a clock jump callback you mentioned.

Mauro Passerino added 2 commits December 6, 2022 18:59
Signed-off-by: Mauro Passerino <mpasserino@irobot.com>
Signed-off-by: Mauro Passerino <mpasserino@irobot.com>
Copy link
Member

@ivanpauno ivanpauno left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

It would be nice to have a review of another maintainer before merging, maybe @audrow or @wjwwood ?

Copy link
Member

@audrow audrow left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me with green CI!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants