Nav2 행동트리는 ComputePath·FollowPath·ClearCostmap·Spin·Wait·BackUp 같은 동작을 성공·실패·실행 중 상태로 조합해 재계획과 복구 순서를 정합니다. 복구는 무조건 반복하는 기능이 아니라 오류 원인·공간 안전·재시도 한계와 운영자 호출 조건을 분리해야 합니다.
아래에서는 용어의 차이를 실제 시스템 경계, 실패 조건과 검증 순서로 나눠 살펴봅니다.
행동트리는 주행 알고리즘보다 실패 뒤의 순서를 결정한다
경로 계산과 추종 알고리즘 자체는 모션 플래닝과 궤적 최적화 글에서 다룬 문제와 연결됩니다. Nav2 행동트리는 ComputePath·FollowPath 같은 서버 호출과 조건·재시도·복구를 한 작업 흐름으로 조율합니다.
로봇이 막혔을 때 costmap을 지우고 다시 계획할지, 잠시 기다릴지, 회전·후진할지, 운영자를 부를지는 서로 다른 위험과 성공 조건을 가집니다. 행동트리는 이 선택을 눈에 보이는 구조와 상태로 관리합니다.
BT 노드는 SUCCESS·FAILURE·RUNNING으로 부모에게 상태를 돌려준다
Nav2 Behavior Trees 공식 문서는 XML로 action·condition·control node를 조합하는 예를 제공합니다. leaf action이 서버 작업을 수행하고 control node가 순서·대안·재시도 규칙을 결정합니다.
RUNNING 동작은 다음 tick에도 계속 관찰되고 SUCCESS와 FAILURE는 부모의 흐름을 바꿉니다. 오래 걸리는 action의 취소와 halt가 제대로 구현되지 않으면 새 목표나 안전 정지에도 이전 명령이 남을 수 있습니다.
기본 NavigateToPose 흐름은 경로 계산과 추종을 파이프라인으로 묶는다
ComputePathToPose는 planner server에 경로를 요청하고 FollowPath는 controller server가 그 경로를 따라 속도를 계산하게 합니다. 주기적 재계획은 이동 중 새 장애물과 위치 변화에 맞춰 global path를 갱신합니다.
재계획 빈도가 너무 높으면 계산량과 경로 흔들림이 늘고 낮으면 막힌 길을 오래 유지할 수 있습니다. 목표 갱신, path validity, progress checker와 controller 상태를 함께 조건으로 사용합니다.
| 실패 지점 | 관찰 신호 | 첫 복구 후보 |
|---|---|---|
| 경로 계산 | planner 오류·path 없음 | global costmap 확인·재계획 |
| 경로 추종 | progress 없음·controller 오류 | local costmap·controller 재시도 |
| TF·센서 | transform timeout·데이터 age | 정지·대기·센서 복구 |
| 공간 막힘 | 유효 경로·속도 없음 | wait·spin·backup 검토 |
RecoveryNode는 주 동작 실패 뒤 복구를 실행하고 다시 시도한다
Nav2 전용 BT 노드 문서는 RecoveryNode가 주 동작 실패 시 두 번째 복구 자식을 실행한 뒤 정해진 횟수 안에서 주 동작을 다시 시도하는 구조를 설명합니다.
복구 action이 SUCCESS를 반환했다고 문제가 해결된 것은 아닙니다. costmap clear가 실행됐다는 상태와 새 경로가 가능해졌다는 결과를 분리하고, 동일 오류가 반복되면 상위 복구로 승격해야 합니다.
문맥 복구는 실패한 서버와 가까운 원인을 먼저 바꾼다
planner가 잘못된 global obstacle 때문에 실패했다면 global costmap clear나 재계획이 직접적인 복구입니다. controller가 로컬 장애물과 진행 실패를 보고했다면 local costmap, progress checker, controller reset과 짧은 대기가 더 가까운 대응입니다.
모든 실패에 양쪽 costmap을 지우면 유효한 장애물 정보까지 사라지고 원인도 숨습니다. error code와 blackboard 상태를 기준으로 해당 문맥에서 필요한 복구만 선택합니다.
시스템 복구는 wait·spin·backup을 안전 조건 아래 순환한다
Nav2 기본 행동트리 상세 문서는 문맥 복구가 실패한 뒤 clear·spin·wait·backup 같은 시스템 수준 동작을 시도하는 구조를 보여줍니다. RoundRobin은 같은 동작만 반복하지 않게 후보를 순환할 수 있습니다.
사람이 잠시 지나가길 기다리는 문제와 센서 오염, 좁은 공간에 끼인 문제는 다른 복구가 필요합니다. 상태 변화가 없는데 wait를 반복하거나 후방 센서가 없는데 backup을 실행하면 회복보다 위험이 커집니다.
Spin과 BackUp은 공간이 있다는 증거가 있을 때만 실행한다
Spin은 주변을 다시 관측하고 방향을 바꿀 수 있지만 footprint 회전 공간과 장애물 신선도가 필요합니다. BackUp은 막힌 전방에서 벗어날 수 있어도 후방 센서 시야, 안전 거리와 탈출 방향이 확보돼야 합니다.
피지컬 AI 안전 계층의 독립 정지 경로는 복구 행동보다 우선합니다. 행동트리가 충돌 회피를 시도하더라도 하드웨어 안전 입력과 속도 제한을 우회해서는 안 됩니다.
센서·TF 오류는 움직이는 복구보다 정지와 건강 확인이 먼저다
laser scan이 오래됐거나 map–odom transform이 끊긴 상태에서 회전과 후진을 시도하면 코스트맵도 잘못된 정보를 사용합니다. 데이터 age, TF availability와 localization 상태가 복구 조건을 만족할 때까지 명령을 막아야 합니다.
센서와 위치 추정의 실패 특성은 SLAM 실패 조건과 연결됩니다. localization lost를 단순 path failure로 취급하지 말고 재초기화·운영자 확인·안전 위치 이동 같은 별도 분기를 둡니다.
오류 코드를 blackboard에 보존해야 다른 복구를 고를 수 있다
planner와 controller server가 반환한 오류 ID와 메시지를 blackboard에 남기면 조건 노드가 timeout, invalid path, progress failure와 TF 문제를 구분할 수 있습니다. 모든 실패를 하나의 boolean으로 줄이면 복구 선택이 거칠어집니다.
로그에는 goal ID, tree XML 버전, 실패 노드, error code, tick 시각, 선택된 recovery와 결과를 같은 요청 단위로 묶습니다. 그래야 현장 재현이 어려운 반복 복구를 시간순으로 분석할 수 있습니다.
재시도 상한은 횟수·시간·상태 변화 세 가지로 정한다
고정 횟수만 두면 긴 action과 짧은 action의 운영 영향이 다르고, 같은 실패가 상태 변화 없이 빠르게 반복될 수 있습니다. 전체 복구 시간, 동일 오류 연속 횟수, 위치·costmap·센서 상태가 실제로 바뀌었는지를 함께 조건으로 봅니다.
새 목표가 들어오거나 사람이 장애물을 치웠다면 카운터를 어떻게 초기화할지, 배터리 부족이나 안전 이벤트가 생기면 즉시 중단할지도 명시합니다. 상한을 넘은 뒤에는 실패 원인과 마지막 안전 상태를 운영자에게 전달합니다.
복구 시험은 오류를 주입하고 물리 궤적까지 판정한다
global path 차단, local obstacle 고정, TF 중단, scan 정지, 좁은 공간과 동적 사람을 각각 주입합니다. tree 상태 전이뿐 아니라 실제 속도, 정지 거리, spin·backup 궤적과 장애물 여유를 기록합니다.
복구 성공 후 같은 목표를 완료하는지, 잘못된 장애물 정보가 다시 쌓이지 않는지, 중단 요청에 즉시 멈추는지도 확인합니다. 시뮬레이션에서 통과한 tree는 실물의 센서 사각과 제동 지연에서 다시 시험해야 합니다.
| 주입 | 기대 분기 | 합격 기준 |
|---|---|---|
| global path 차단 | 재계획·global clear | 새 경로 또는 안전 실패 |
| local 진행 실패 | local clear·wait | progress 회복 |
| TF·scan 중단 | 움직임 차단·건강 확인 | 오류 중 무명령 |
| 복구 반복 | 상한 뒤 운영자 승격 | 정지·원인 보존 |
Lifecycle과 행동트리는 복구 범위를 나눠야 한다
ROS 2 Lifecycle Node 글은 노드 자원 재구성과 상태 전이를 다룹니다. 행동트리는 작업 흐름 안의 재계획·대기·회피를 맡고, 서버 자체 불량이나 장치 재연결은 lifecycle 감독 경로로 넘기는 편이 분명합니다.
운영 인수 문서에는 tree가 처리하는 실패와 supervisor가 처리하는 실패, 즉시 안전 정지가 처리하는 실패를 표로 구분합니다. 경계가 겹치면 여러 복구가 동시에 명령하거나 서로의 재시작을 방해할 수 있습니다.
Nav2 행동트리와 복구 동작에서 자주 묻는 질문
Costmap을 지우는 복구는 항상 안전한가요?
아닙니다. 실제 장애물 정보까지 잠시 사라질 수 있으므로 센서 재관측과 속도 제한, clear 범위를 함께 관리해야 합니다.
Spin과 BackUp 중 무엇을 먼저 써야 하나요?
현재 공간, 센서 시야와 실패 원인에 따라 다릅니다. 회전 공간과 후방 관측이 확인되지 않으면 어느 동작도 자동 실행하지 않는 편이 안전합니다.
재시도 횟수를 높이면 성공률이 올라가나요?
일시 장애에는 도움이 될 수 있지만 같은 원인이 유지되면 시간과 위험만 늘어납니다. 상태 변화와 전체 시간 상한을 함께 봐야 합니다.
센서 오류도 행동트리에서 복구할 수 있나요?
건강 상태를 조건으로 감지하고 정지·대기·재시작 요청을 보낼 수 있습니다. 장치 재구성은 lifecycle 또는 별도 supervisor가 맡는 편이 좋습니다.
복구 성공은 무엇으로 판정하나요?
복구 action 완료가 아니라 새 경로 계산, 진행 회복, 목표 완료와 안전 궤적까지 확인해야 합니다.
복구 행동은 안전 기능을 대신하지 않습니다. 실제 로봇의 spin·backup·clear 정책은 센서 범위, 제동 성능과 현장 위험 분석에 맞춰 검증해야 합니다.