28.1.2. PX4 Navigation State (`nav_state`) 상태 머신 구조

28.1.2. PX4 Navigation State (nav_state) 상태 머신 구조

PX4-Autopilot 아키텍처에서 조종사의 물리적 조향 의도나 지상 관제 시스템(GCS)의 자율 비행 명령이 하위 제어기(Controller) 스택으로 파이프라인 되기 전에, 반드시 그 적합성을 검증받고 통과해야 하는 최상위 논리적 검문소이자 두뇌 역할을 하는 시스템 코어 메커니즘이 바로 **Navigation State (nav_state)**이다. 흔히 일반 유저들이 뭉뚱그려 “비행 모드(Flight Mode)“라고 통칭하는 다이나믹한 개념의 실체를, 하드코어 커널 레벨 시스템 상태 머신(State Machine) 관점에서 가장 본질적이고 정확하게 대변하는 C++ 변수가 바로 이 녀석이다.

1. nav_state와 Flight Mode Manager의 개념적 분리 아키텍처

PX4 C++ 소스 코드를 처음 마주하는 개발자들이 아키텍처 해석에서 가장 크게 혼동하는 지점이 바로 이 nav_state 변수 개념과 Flight Mode Manager 모듈 간의 롤플레잉(Role-playing) 및 경계 차이다. 이 둘은 아키텍처 상 엄격하게 주종이 분리된 계층망과 책임을 지닌다.

  1. nav_state (상태 머신 브레인 변수 자체):
  • 소속: 펌웨어 내 최상위 상태 결정권자 모듈인 Commander 앱에서 이 변수를 전담하여 실시간으로 평가(Evaluation)하고 할당한다.
  • 역할: “기체가 지금 수학적으로, 율법적으로 어떤 논리 상태를 점유하고 있는가?“를 최종 규정하는 단일한 1차원 열거형(Enum) 정수형 상수 표식이다. “지금 우리는 수동 자세 안정화 제어 중이다(STABILIZED)”, “지금은 웨이포인트 미션 수행 중이다(MISSION)“와 같이, 기체 전체 시스템에 절대적인 행동 강령 방침을 지시하는 최고 사령부의 **행정 명령서(Directive)**에 비유할 수 있다.
  1. Flight Mode Manager (행정 실무 집행 모듈):
  • 소속: 최루의 nav_state 글로벌 토픽 변수를 비동기 폴링으로 구독(Subscribe)하여, 실제로 물리적인 하위 제어 타겟 추방 궤적 데이터(trajectory_setpoint)를 빚어내는(Generate) 중간 논리 관리자 데몬 모듈이다.
  • 역할: Commander 사령부 모듈이 내려준 nav_state 행정 명령서의 넘버링 값을 바탕으로, “아, 지금은 미션 상태군. 그렇다면 수많은 C++ FlightTask 서브 클래스 중 FlightTaskAutoMapper 객체를 메모리에 컨텍스트 스위칭 띄워 활성화(Activate)시켜야겠군“을 판별하고 물리적 실행 연산에 돌입하는 실무 집행 국장이다.

즉, 데이터의 흐름 지휘 체계는 사용자 명령 파서(RC/MAVLink) \rightarrow Commander 모듈 산하의 엄격한 nav_state 상태 전이 유효성 검사 \rightarrow flight_mode_manager 모듈의 해당 상태 상수에 1:1 매칭 조립된 FlightTask 객체 다형성 호출을 통한 역학 궤적 생성 실행 순서의 폭포수로 흘러내려 간다.

2. vehicle_status.msg 내비게이션 트리의 척추 구조

이러한 핵심 nav_state 상수 식별자 값은 PX4 펌웨어 전체의 장기(Organ) 호흡 상태를 관장하는 척추 코어 토픽인 vehicle_status.msg 구조체 내부 한가운데에 uint8 nav_state 변수로 단단히 문신처럼 박혀 비동기로 브로드캐스팅 라우팅된다.
모든 PX4의 내부 옵스 모듈들(자세 제어기, 로우 디스크 로거, 위치 추정 EKF2, 이탈 방지 Failsafe 데몬 등)은 상호 간에 스파게티처럼 직접 레퍼런스 통신하지 않는다. 오직 이 중앙 관제 vehicle_status 토픽을 가만히 들여다보며 현재 전체 여객 기체의 nav_state가 무엇으로 선언되어 있는지 읽어내고, 독립적으로 자신의 틱 작동 로직 분기점(If-else / Switch-case)을 스스로 판단 지어버린다.

# msg/vehicle_status.msg 내비게이션 상태 상수 정의표 (일부 발췌)

uint8 nav_state             # 현재 적용 완료된 내비게이션 상태(비행 모드)

# --- 수동 조작 계열 상태망 (Manual / Supported) ---
uint8 NAVIGATION_STATE_MANUAL = 0       # 어떠한 보조도 없는 쌩 수동 모드 (주로 Fixed Wing 코어 전용)
uint8 NAVIGATION_STATE_ALTCTL = 1       # 고도 제어 기압계/GPS 유지 보조 모드 (Altitude)
uint8 NAVIGATION_STATE_POSCTL = 2       # 전체 3D 위치 고정 정지 보조 모드 (Position)
...
# --- 자율 비행 계열 상태망 (Auto / Offboard) ---
uint8 NAVIGATION_STATE_AUTO_MISSION = 3 # GCS 업로드 웨이포인트 임무 수행 모드
uint8 NAVIGATION_STATE_AUTO_LOITER = 4  # 현재 위치 자동 배회 고수 대기 모드 (Hold)
uint8 NAVIGATION_STATE_AUTO_RTL = 5     # 자동 이륙원점/안전지점 복귀 모드 (Return To Launch)
...
# --- 특수/치명적 비상 상태망 (Emergency/Kill) ---
uint8 NAVIGATION_STATE_TERMINATION = 19 # 비행 시스템 강제 록다운/추락 유도 비상 종료 모드

위 펌웨어 패킷 소스 코드 발췌에서 증명되듯, 시스템의 nav_state는 일반인들이 아는 대여섯 개의 표면적 비행 모드를 아득히 넘어서는 20개 이상의 매우 엄밀하고 세분화된 행동 상태(State Node)를 명확히 규정하고 있다.
조종사가 QGC 스크린에서 ‘Hold’ 버튼 아이콘 단 하나만 탭(Tap) 하더라도, 내부적으로는 수십 개의 센서 건강 상태(Health check) 매트릭스와 CPU 과부하 검증 프레임워크를 나노초 안에 통과한 후, 최종적으로 Commander 모듈에 의해 해당 상태 변수 상수가 NAVIGATION_STATE_AUTO_LOITER (4) 로 단단히 치환(State Transition Commit)되어야만 진정한 홀드 비행 모드 궤적 체계가 모터 믹서를 돌리며 본격 구동을 시작하는 메커니즘이다.

3. 유한 상태 기계(Finite State Machine) 아머(Armor)의 절대 강건성

이 nav_state 변숫값의 변경 시퀀스는 다른 변수들처럼 이빨 빠진 단순한 덮어쓰기(Overwrite Allocation)가 결코 허용되지 않는다. Commander 데몬 내부에는 이 변수를 지키기 위한 철저한 수학적 논리 조합망인 유한 상태 기계(FSM: Finite State Machine) 전이 매트릭스 로직이 콘크리트처럼 구축되어 있다.

예증을 들어 기체의 위성 GPS 신호가 산맥에 가려 완전히 끊겨 EKF2의 vehicle_local_position 토픽이 불신 발행 불량(Timeout/Invalid Invalidated) 블랙아웃 상태에 빠졌다고 역산해 보자. 조종사가 패닉에 빠져 아무리 물리적 조종기 Taranis 스위치를 달칵 토글하여 POSCTL (Position) 안심 모드로 강제 진입하려 발버둥을 치더라도, FSM 상태 천이 검증 함수가 단호하게 이 nav_state 인덱스 변경 승인을 즉각 기각(Reject) 통보하고 거부 반환(Abort)해 버린다.

이는 각 센서의 수학적 오차 분산 조건, 기체의 모터 시동(Arming) 물리 여부 등 무수하게 얽힌 선행 안전 검증 조건(Pre-condition Flags) 다발 톱니바퀴가 완벽히 오차 없이 일치해 맞물려야만 nav_state의 다음 상태 칸막이 노드(Node Transition)로 안전망을 헤치고 넘어갈 수 있도록 고안된 설계다. PX4 시스템이 허점투성이인 인간 조종사의 실수를 원천 방어해 내는 가장 견고한 커널 레벨 물리적 소프트웨어 아머(Software Armor)의 형태로 빚어져 있음을 강력히 시사하는 대목이다.