Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

Support lifecycle-managed timers in rclcpp_lifecycle::LifecycleNode

Đang mở
  • Có gì không ổn?
#3,255 7 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

@armaho đang làm issue này rồi.

Từ ngày 10/9/2026.

  • #3263 của @armaho — đang mở

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
30/100
Loại issue
Tính năng
Độ rõ ràng
Cần làm rõ
Mức độ hoạt động
Sôi nổi
Công nghệ
cpp
Lĩnh vực
api

Hướng nghiên cứu

Bắt đầu với LifecycleNode::create_timer() và create_wall_timer(), sau đó xem xét hành vi chuyển trạng thái vòng đời được mô tả ở đây và thảo luận về thiết kế trong PR #2261. Giải quyết các câu hỏi còn bỏ ngỏ về API và trạng thái chuyển tiếp với các maintainer; được xem là hoàn thành khi có một API timer được quản lý bởi vòng đời đã được thống nhất và các bài kiểm thử bao phủ trạng thái không hoạt động, trạng thái hoạt động, các chuyển tiếp lặp lại, việc tạo khi đang hoạt động và các chuyển tiếp thất bại.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

enhancement
Description

rclcpp_lifecycle::LifecycleNode does not provide an API for managing timer callback execution based on lifecycle state.

Currently, LifecycleNode::create_timer() and create_wall_timer() create regular rclcpp timers whose callback execution is not managed by lifecycle transitions.
As a result, if an executor is spinning, timer callbacks may run even when the node is Unconfigured or Inactive.

This is not a claim that the existing timer APIs are incorrect.
The issue is that LifecycleNode does not provide an API for opting into lifecycle-managed timer behavior.

This issue proposes the following behavior for lifecycle-managed timers:

Lifecycle state or transition Proposed timer behavior
Unconfigured Do not start executing new timer callbacks
Inactive Do not start executing new timer callbacks
Successful transition to Active Start or resume callback execution for timers that have already been created
Active Allow lifecycle-managed timer callbacks to execute
Successful deactivation cancel() the timer; callbacks already in flight may complete
Successful cleanup / shutdown Prevent new timer callbacks from starting and clean up the timer

The start behavior for a timer created while the node is already Active, and the behavior when a lifecycle transition fails, are left as open questions below.

Motivation

Applications may need to control periodic timer-based work according to lifecycle state.
However, because LifecycleNode does not provide a lifecycle-managed timer option, each application must implement this control separately.

The ROS 2 Managed Nodes design describes Inactive as a state in which the node is not performing any processing.
The lifecycle_talker demo also uses a regular timer and includes a comment that a future version will add a timer following the same lifecycle management as a lifecycle publisher. This comment provides historical context that lifecycle-managed timers have been considered before.

Inspection of the LifecycleNode implementations in Rolling and Jazzy found that neither branch provides a separate lifecycle-managed timer API.
On Jazzy, I confirmed that callbacks from a regular create_wall_timer() execute while the node is both Unconfigured and Inactive.
This result demonstrates the current behavior of regular timers; it does not imply that the existing API violates an explicitly documented lifecycle contract.

Design / Implementation Considerations

There are three possible API directions to consider.

Add a new API

  1. Add separate APIs for creating lifecycle-managed timers.

Change the existing APIs

  1. Change the default behavior of LifecycleNode::create_timer() and create_wall_timer() so that they create lifecycle-managed timers.
  2. Add an option to the existing APIs for selecting managed or unmanaged behavior.

For now, I propose adding separate APIs.
Changing the default behavior of the existing APIs could alter timer behavior in Inactive without a compile error for existing applications that use auto or rclcpp::TimerBase::SharedPtr.
Adding an option would preserve existing calls, but the same function would provide different lifecycle behavior, requiring readers to inspect the option at each call site to determine whether a timer is lifecycle-managed.
Separate APIs would preserve existing application behavior while making the distinction between regular and lifecycle-managed timers explicit at each call site.

For example, the following APIs could be considered:

create_lifecycle_timer(...)
create_lifecycle_wall_timer(...)

To assess the feasibility of the proposed behavior, I tested a downstream implementation that calls cancel() and reset() on timers in response to lifecycle transitions.
The Jazzy-based tests confirmed that new callbacks did not start while the node was Inactive, callbacks executed while it was Active, and timer callback execution resumed across repeated activate/deactivate cycles.

This validation only establishes the feasibility of the proposed lifecycle behavior.
The actual upstream API names, signatures, return types, and internal management approach remain open for discussion with the maintainers.

PR #2261 proposed separate APIs for lifecycle-managed timers and integration with lifecycle transitions, but it was closed without being merged.
The review raised design questions about whether callbacks should execute before activation under different autostart settings and how a timer created while the node is already Active should behave.

This issue does not request adopting the implementation from #2261 as-is.
Its purpose is to clarify behavior based on lifecycle state and timer creation timing, and to revisit the API design for lifecycle-managed timers.

I would appreciate maintainer guidance on the following:

  1. Is lifecycle-managed timer support still desired for Rolling?
  2. Which direction would be preferable: adding separate APIs, changing the default behavior of the existing APIs, or adding an option to the existing APIs?
  3. If a lifecycle-managed timer is created while the node is already Active, should it start immediately?
  4. How should a managed timer behave when a lifecycle transition fails?
Additional Information

Lifecycle-managed timer support for rclcpp_lifecycle::LifecycleNode in Rolling

Ngôn ngữ chính
C++
Star
815
Fork
572
Merge trung bình
6 ngày 8 giờ
Pull request đã merge (30 ngày)
20

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của ros2/rclcpp

Tất cả issue của ros2/rclcpp

Issue tương tự

Thêm issue về C++

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.