ROS 2 Lifecycle Node는 노드를 켜고 끄는 단순 스위치가 아니라 configure·activate·deactivate·cleanup·shutdown 전이를 통해 자원 준비와 실제 동작을 분리하는 상태 기계입니다. 의존 노드의 시작 순서와 오류 복구 정책을 명시하면 부분 장애를 전체 재부팅 없이 다룰 수 있습니다.
아래에서는 용어의 차이를 실제 시스템 경계, 실패 조건과 검증 순서로 나눠 살펴봅니다.
Lifecycle Node는 프로세스 생존과 기능 사용 가능 상태를 구분한다
일반 ROS 2 노드는 프로세스가 시작되면 곧바로 구독·서비스·출력을 수행하기 쉽습니다. 피지컬 AI 안전 계층처럼 여러 조건이 갖춰져야 움직일 수 있는 로봇에서는 프로세스가 살아 있다는 사실과 기능을 활성화해도 된다는 판단을 분리해야 합니다.
Lifecycle Node는 표준 상태와 전이 인터페이스를 제공해 감독 노드가 준비·활성·비활성·정리 상태를 조회하고 변경할 수 있게 합니다. 덕분에 센서가 준비되기 전 제어기가 명령을 내거나, 일부 설정 실패가 조용히 지나가는 문제를 줄일 수 있습니다.
기본 상태는 Unconfigured·Inactive·Active·Finalized 네 가지다
ROS 2 Managed Nodes 설계 문서는 네 기본 상태와 configuring·activating·deactivating·cleaning up·shutting down·error processing 전이 상태를 정의합니다. 외부 감독자가 명시적인 전이를 요청하는 구조가 중심입니다.
Unconfigured는 아직 운영 자원이 준비되지 않은 상태, Inactive는 설정됐지만 실제 동작을 멈춘 상태, Active는 지정 기능을 수행하는 상태, Finalized는 종료 뒤 조사와 파괴를 기다리는 상태로 이해하면 운영 설계가 쉬워집니다.
configure에서는 자원을 준비하되 로봇을 움직이지 않는다
configure 단계에서는 파라미터 검증, 장치 연결, 메모리와 버퍼 준비, 모델 로드처럼 활성 전에 필요한 작업을 수행합니다. 성공하면 Inactive로 이동하고 실패하면 준비되지 않은 상태로 돌아가 원인을 수정할 수 있어야 합니다.
중요한 원칙은 configure가 성공했다는 이유로 위험한 출력을 시작하지 않는 것입니다. 모터 enable, 경로 실행, 외부 장치 가동처럼 물리 동작을 만드는 행위는 활성 조건을 통과한 뒤로 미뤄야 준비 시험과 실제 운전을 구분할 수 있습니다.
| 상태·전이 | 허용 작업 | 금지·주의 |
|---|---|---|
| configure | 파라미터·자원 준비 | 물리 출력 시작 금지 |
| Inactive | 상태 조회·재설정 | 운영 명령 차단 |
| activate | 콜백·출력 시작 | 의존 노드 미준비 금지 |
| cleanup | 자원 해제·초기화 | 잔류 명령·핸들 확인 |
Inactive는 준비 완료이면서 출력이 멈춘 운영 대기 상태다
Inactive에서는 설정된 자원을 유지해 빠르게 재활성화할 수 있지만 운영 데이터 처리와 출력은 제한해야 합니다. 어떤 구독과 서비스가 계속 동작하는지는 노드 구현에 달려 있으므로 팀의 공통 규칙을 문서로 고정해야 합니다.
예를 들어 카메라 노드는 장치 연결을 유지하되 프레임 발행을 멈출 수 있고, 제어 노드는 상태를 보존하되 actuator command를 안전값으로 고정할 수 있습니다. Inactive에서 무엇이 멈추는지 불명확하면 감독자는 상태 이름만 보고 안전을 오판합니다.
activate는 의존 노드와 안전 조건을 확인한 뒤 요청한다
ROS 2 Managed Nodes 데모는 명령줄에서 상태를 조회하고 전이를 요청하는 기본 흐름을 보여줍니다. 실제 로봇에서는 감독기가 센서 건강, 시간 동기, 안전 입력과 하위 노드 상태를 조건으로 묶어야 합니다.
활성화 순서는 보통 장치·센서, 상태 추정, 계획, 제어, 물리 출력처럼 데이터 의존 방향을 따릅니다. 비활성화는 위험 출력을 먼저 끄고 상위 기능을 내리는 역순이 안전하지만, 시스템별 안전 분석으로 최종 순서를 정해야 합니다.
deactivate와 cleanup은 목적이 다르다
deactivate는 자원을 유지한 채 운영 동작을 멈춰 재활성화 가능 상태로 돌아가는 전이입니다. cleanup은 파라미터로 만든 객체, 장치 핸들, 버퍼와 임시 상태를 해제해 다시 구성할 수 있는 초기 상태로 돌립니다.
짧은 일시정지와 장치 재연결을 같은 복구로 처리하면 불필요한 초기화가 늘거나 잘못된 상태가 남습니다. 오류 유형별로 deactivate만 필요한지, cleanup 후 재configure가 필요한지, 프로세스 재시작까지 가야 하는지를 나눠야 합니다.
on_error는 무한 재시도가 아니라 안전한 분기점이다
rclcpp_lifecycle API 문서는 상태 전이 콜백을 구현할 수 있는 인터페이스를 제공합니다. 오류 콜백에서는 출력 안전화, 원인 코드 보존, 해제 가능한 자원 정리와 다음 상태 결정을 수행해야 합니다.
항상 SUCCESS를 반환해 자동 재시작하는 정책은 반복 고장과 위험 동작을 숨길 수 있습니다. 동일 오류 횟수, 시간창, 하드웨어 건강, 사람 승인 필요 여부를 조건으로 두고 복구 불가능하면 격리 또는 Finalized로 보내는 편이 안전합니다.
감독기는 상태 전이를 조율하지만 각 노드의 안전 책임을 대신하지 않는다
Lifecycle Manager나 별도 supervisor는 여러 노드의 상태, 타임아웃과 의존 관계를 조정합니다. 그러나 네트워크 단절이나 감독기 오류가 생길 수 있으므로 각 노드도 명령 신선도, 장치 오류와 안전 입력에 따라 스스로 안전 출력으로 갈 수 있어야 합니다.
ROS 2 명령 보안의 권한 경계도 수명주기 서비스에 적용해야 합니다. 아무 노드나 activate·shutdown을 요청할 수 있으면 표준 상태 기계가 오히려 중요한 제어면을 넓힐 수 있습니다.
시작 순서는 상태 이름이 아니라 준비 조건 그래프로 설계한다
센서가 Active여도 유효 프레임이 아직 없을 수 있고 상태 추정기가 Active여도 공분산이 안정되지 않았을 수 있습니다. 따라서 단순히 모든 노드가 Active인지 보는 대신 데이터 수신, timestamp, 품질 지표와 안전 입력을 준비 조건으로 둡니다.
의존성 그래프에는 필수 노드와 선택 노드를 구분합니다. 선택 센서 하나가 실패했을 때 전체를 막을지 축소 기능으로 운전할지 결정하고, 모드별로 필요한 Active 집합과 금지 출력을 명시해야 부분 장애 복구가 가능합니다.
복구 시나리오는 일시 오류·지속 오류·연쇄 오류로 나눠 시험한다
일시 오류는 짧은 장치 끊김 뒤 reconnect와 재활성화를, 지속 오류는 재시도 제한과 격리를, 연쇄 오류는 하위 노드 실패가 계획·제어 노드에 어떻게 전파되는지를 시험합니다. 각 시나리오에서 마지막 안전 상태와 운영 알림을 확인합니다.
온보드 컴퓨터 과부하나 재부팅은 로봇 엣지 컴퓨팅 구조와 연결해 봐야 합니다. 프로세스 재시작만으로 해결되지 않는 메모리·전원·열 문제를 lifecycle 전이 실패로 반복시키지 않도록 시스템 지표를 함께 기록합니다.
통합 시험은 정상 전이와 실패 전이를 같은 비중으로 기록한다
정상 시작·정지뿐 아니라 configure 타임아웃, activate 중 센서 상실, deactivate 콜백 실패, cleanup 뒤 핸들 잔류와 감독기 재시작을 주입합니다. 서비스 응답과 실제 물리 출력이 같은 상태를 가리키는지도 별도 계측합니다.
전이 로그에는 요청자, 이전·다음 상태, 시작·종료 시각, 반환 코드, 원인, 안전 출력 확인과 연관 노드 상태를 남깁니다. 그래야 단일 노드 로그가 아니라 시스템 수준 시간축에서 연쇄 실패를 재구성할 수 있습니다.
| 시나리오 | 주입 | 판정 |
|---|---|---|
| 정상 시작 | 의존 순서 활성화 | 출력 시작 시점 일치 |
| 일시 오류 | 장치 단절 후 복원 | 제한 재시도·복귀 |
| 지속 오류 | 재연결 불가 | 격리·안전 출력 |
| 연쇄 오류 | 하위 노드 실패 | 상위 비활성·원인 보존 |
운영 기준은 전이 성공률보다 잘못된 활성화를 막는 데 둔다
activate 성공률이 높아도 준비되지 않은 입력으로 동작을 시작하면 좋은 시스템이 아닙니다. 활성 전 조건 누락, 전이 타임아웃, 안전 출력 지연, 반복 오류 횟수와 수동 개입 시간을 함께 지표로 둡니다.
실시간 제어 루프는 lifecycle 서비스 응답과 다른 시간 제약을 가집니다. 상태 전이는 운영 조율에 쓰고, 고속 안전 정지와 deadline 감시는 실시간·안전 경로에서 독립적으로 보장해야 합니다.
ROS 2 Lifecycle Node에서 자주 묻는 질문
Lifecycle Node를 쓰면 자동으로 안전해지나요?
아닙니다. 상태와 전이 인터페이스를 표준화할 뿐입니다. 각 상태의 출력 정책, 안전 조건과 실패 처리까지 구현하고 시험해야 합니다.
Inactive와 프로세스 정지는 같은가요?
아닙니다. 프로세스와 준비된 자원을 유지하면서 운영 기능을 멈춘 상태입니다. 어떤 콜백이 유지되는지는 구현 규칙으로 확인해야 합니다.
오류가 나면 무조건 cleanup 후 다시 configure하면 되나요?
오류 원인에 따라 다릅니다. 일시 중지로 충분한지, 자원 재생성이 필요한지, 하드웨어 격리나 프로세스 재시작이 필요한지 구분해야 합니다.
여러 노드는 어떤 순서로 활성화하나요?
데이터와 안전 의존 순서를 따릅니다. 보통 장치·센서부터 상태 추정과 계획, 제어·출력으로 올리고 정지는 위험 출력을 먼저 내립니다.
Lifecycle Manager가 멈추면 노드도 안전하게 멈추나요?
자동으로 보장되지 않습니다. 각 노드와 하드웨어 경로가 명령 신선도와 안전 입력을 감시해 독립적으로 안전 상태로 갈 수 있어야 합니다.
Lifecycle 상태는 안전 인증을 대신하지 않습니다. 실제 로봇의 정지·재시작 정책은 위험 분석, 하드웨어 안전 기능과 적용 규격에 맞춰 설계해야 합니다.