Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Add lifecycle timers - #2261

Closed
carmiac wants to merge 6 commits into
ros2:rollingfrom
carmiac:lifecycle_timer
Closed

carmiac wants to merge 6 commits into
ros2:rollingfrom
carmiac:lifecycle_timer

Conversation

@carmiac

@carmiac carmiac commented Aug 2, 2023

Copy link
Copy Markdown

This adds lifecycle timers which start when the node activates and cancel when the node deactivates. There is a demo available at https://github.com/carmiac/demos/blob/lifecycle_timer/lifecycle/src/lifecycle_timer.cpp

@ros-discourse

Copy link
Copy Markdown

This pull request has been mentioned on ROS Discourse. There might be relevant details there:

https://discourse.ros.org/t/lifecycle-node-improvements/32706/1

@clalancette clalancette left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

This generally looks good to me, but can you please add some unit tests as well?

@clalancette clalancette self-assigned this Aug 10, 2023
Adam Milner added 2 commits August 14, 2023 16:19
Signed-off-by: Adam Milner <[email protected]>
Signed-off-by: Adam Milner <[email protected]>
CallbackT callback,
rclcpp::CallbackGroup::SharedPtr group = nullptr);

/// Create a lifecycle timer that uses the node clock to drive the callback.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

we should also have an API to create a timer with a custom clock

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

I'm not sure whether that makes sense. Sure, the underlying https://github.com/ros2/rclcpp/blob/rolling/rclcpp/include/rclcpp/create_timer.hpp has support for that, but the rclcpp::Node already has a Clock that is accessed via get_clock. Giving the ability to create a timer based off another clock means that this particular timer will (possibly) run at a different rate from the rest of the Node. While I can imagine some uses for that, it is kind of strange.

Further, it doesn't look like we expose that kind of functionality from https://github.com/ros2/rclcpp/blob/rolling/rclcpp/include/rclcpp/node.hpp . And I don't really want LifecycleNode to "get ahead" of Node (we already have the opposite problem).

To me, adding that in is an orthogonal discussion, and if we are going to do it we should do it for both Node and LifecycleNode.

std::chrono::nanoseconds period,
FunctorT && callback,
rclcpp::Context::SharedPtr context,
bool autostart = true)

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

by default, autostart true means time starts immediately. that means timer callback will be called after creation w/o activating the lifecycle node? i was thinking that timer should not be called until node becomes to active status.

void on_activate() override
{
SimpleManagedEntity::on_activate();
if (autostart_) {

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

what is user application creates the LifecycleTimer with autostart false after on_activate? timer will not be activated even the node is active status. i think that would not be what user expects.

Comment on lines +112 to +113
EXPECT_TRUE(timer_->is_activated());
EXPECT_TRUE(wall_timer_->is_activated());

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

not only checking with is_activated, but also needs to check timer_called_ and wall_timer_called_.

EXPECT_EQ(State::PRIMARY_STATE_UNCONFIGURED, node_->get_current_state().id());
node_->trigger_transition(
rclcpp_lifecycle::Transition(Transition::TRANSITION_CONFIGURE), ret);
ASSERT_EQ(success, ret);

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

i think we need to check if timer_called_ and wall_timer_called_ are false here.

Comment on lines +131 to +132
EXPECT_EQ(timer_called_, false);
EXPECT_EQ(wall_timer_called_, false);

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

i think there probably are failing since the timer will autostart w/o state checking.

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.

5 participants