Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Unify LifecycleNode and Node

Abierto
  • ¿Algo no está bien?
#2,874 24 comentarios 5 reacciones 1 asignado Ver en GitHub

Los mantenedores suelen responder en 1 día

@mjcarroll ya está trabajando en esto.

Desde el 10/7/2025.

Evaluación

Este issue todavía no se ha evaluado.

Descripción

enhancement
Description

Currently rclcpp_lifecycle::LifecycleNode and rclcpp::Node are two distinct classes that both implement the common node interface, but LifecycleNode exposes the lifecycle management features. It would be nice to have a common interface that exposes flexible controls for using lifecycle capabilities or not.

I think that if we were to merge the interfaces together, it would be nice to have it be completely runtime configurable. It seems like there are 3 possible configurations. To expose all 3 of these behaviors, maybe we could expose the following ros arg or special ros parameter (similar to use_sim_time) with 3 different values. Let's call this argument/parameter lifecycle.

  1. lifecycle=manual: Current LifecycleNode behavior: expose publisher and services, and don’t auto transition.
  2. lifecycle=none: Current Node behavior, but with “auto-transition”: don’t expose publisher and services, and call any configure and activate methods as if they are part of the constructor, and deactivate and cleanup methods as if they are part of the destructor. If the configure or activate methods fail, just fail the constructor. Maybe we would want to consider that if the node transitions itself out of active killing the node, but that might be too implementation dependent.
  3. lifecycle=auto: Current LifecycleNode behavior, but with auto transition. You may want the convenience of having the configure and activate transitions on startup and deactivate and cleanup methods on shutdown, but you also want to be able to control the state transitions externally. This could be important because I have seen some LifecycleNodes be written to automatically deactivate themselves on errors, or to fail to configure or activate in the first place depending on conditions.
Motivation

Some people swear by ROS 2 lifecycle and encourage making everything use LifecycleNode. Others don't want the additional complexity and failure points introduced by LifecycleNode, and would rather manage lifecycle using different systems or abstractions. This puts library maintainers in the difficult position where they can either implement one, or implement two versions of their nodes: one lifecycle and one not. If they don't implement one, then lifecycle users may look to put that code in a wrapper or fork it to implement lifecycle, and non-lifecycle users are forced to add lifecycle management code to their project when they wouldn't otherwise (or fork and remove lifecycle). This creates additional friction between libraries and users. A unified, runtime-configurable API would give everyone what they want with no burden on library maintainers.

Design / Implementation Considerations

We may want to merge the rclcpp_lifecycle package into rclcpp. Although this change doesn't necessarily need to affect LifecyclePublisher for example, unless we take on merging all managed entities.

Additional Information

https://discourse.ros.org/t/all-nodes-as-lifecycle-nodes

Lenguaje dominante
C++
Estrellas
814
Forks
572
Merge medio
4 d 2 h
PR fusionados (30 d)
21

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de ros2/rclcpp

Todos los issues de ros2/rclcpp

Issues similares

Más issues de C++

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.