28.1.2.1. `vehicle_status.msg` 내 `NAVIGATION_STATE_*` 열거형 상수 심층 분석

28.1.2.1. vehicle_status.msg 내 NAVIGATION_STATE_* 열거형 상수 심층 분석

PX4의 다채로운 비행 모드 구조를 C++ 펌웨어 코드 레벨에서 완벽히 통제하고 확장하기 위해서는, 모든 내비게이션 상태의 원천 데이터베이스이자 유일무이한 열거형(Enum) 레퍼런스인 msg/vehicle_status.msg 파일의 내부 구조를 반드시 해부하고 근본적으로 이해해야만 한다.

이 uORB 메시지 패킷 한가운데 위치한 핵심 nav_state 변수에 메모리 상으로 할당될 수 있는 상수(Constant)들은 오직 NAVIGATION_STATE_ 라는 엄격한 접두사로 시작하는 고정된 uint8 정수형 매크로 식별자들뿐이다. 이 상수들은 기체의 역학적 권한 분리에 따라 크게 3가지의 거대한 카테고리(군)로 논리적으로 분류되어 전체 펌웨어 시스템 스케줄링을 통압 통제하게 된다.

1. 열거형 상수표의 논리적 권한 분류 체계 (Taxonomy)

PX4 소스코드 트리에 영구 내장된 이 상수들은 가장 하드웨어에 가까운 무보정 원초적 수동 제어부터 시작하여 고차원적인 인공지능 웨이포인트 자율 비행, 그리고 최후의 파괴적인 인명 방호 안전 강제 추락 상태에 이르기까지 총 20여 개 이상의 체계적인 인덱스 번호를 빈틈없이 부여받고 있다.

1.1 카테고리 1: 수동 제어 상태 군 (Manual & Assisted Control Domain)

아날로그 조종사가 어떤 형태로든 조이스틱을 통해 기체의 궤적이나 자세 제어 PID 루프에 실시간으로 직접 개입(Interrupt/Override)하여 기체를 뒤흔들 수 있는 1차원적으로 열린(Open) 권한 상태들을 통칭한다.

  • 대표 상수: NAVIGATION_STATE_MANUAL, NAVIGATION_STATE_ALTCTL, NAVIGATION_STATE_POSCTL, NAVIGATION_STATE_ACRO, NAVIGATION_STATE_STAB
  • 특징: 기체 구조 상 입력 파이프라인의 핵심인 manual_control_setpoint 토픽이 최상급 우선순위로 존중되며, 자동 센서 퓨전의 고집보다 인간 조종사의 물리력 의도(Human Intent)가 시스템의 최종 스로틀 통제권을 굳건히 쥐고 있는 상태다.

1.2 카테고리 2: 자동 제어 상태 군 (Auto & Autonomous Control Domain)

조종사의 물리적 조향 타각 조작이 전면 소프트웨어적으로 차단되거나 철저히 무시되며, 오직 비상 오버라이드(Take-over) 트리거 전용으로만 전락한다. 대신 펌웨어 코어 내부의 고도화된 자동 길찾기(Path-finding) 및 미션 수행 알고리즘이 스스로 기체 궤적을 100% 지배하는 철저히 닫힌(Closed) 피드백 궤환 상태들을 의미한다.

  • 대표 형상 상수: NAVIGATION_STATE_AUTO_MISSION, NAVIGATION_STATE_AUTO_LOITER, NAVIGATION_STATE_AUTO_RTL, NAVIGATION_STATE_AUTO_TAKEOFF, NAVIGATION_STATE_AUTO_LAND
  • 특징: 지상 관제망 GCS(QGroundControl)에서 업로드해 둔 GPS 웨이포인트 행렬이나 홈(Home) 좌표만이 유일한 삼차원 제어 목표 추적 타겟 점이 된다. 이 과정은 오로지 상위 Commander 모듈의 내부 지리 판단 조건(웨이포인트 도달 반경 통과 완료 등)에 의해서만 다음 상태 번호표로 직렬 전이(Chained Automatic Transition)된다.

1.3 카테고리 3: 오프보드 및 특수/비상 상태 군 (Offboard & Emergency/Failsafe Domain)

ROS2, MAVSDK 등을 연동하는 외부 동반 컴퓨터(Companion Computer) API망에 기체의 직접 통제권을 양도(Delegation)했거나, 배터리 부족/센서 고장 시 기체 모터 시동을 허공에서 강제로 꺼버리는 등 인명 대형 사고를 막기 위한 비상 인터럽트 발동 상태들을 포괄한다.

  • 대표 상수: NAVIGATION_STATE_OFFBOARD, NAVIGATION_STATE_TERMINATION, NAVIGATION_STATE_DESCEND
  • 특징: 일반적인 비행 모드의 느슨한 궤적 로직을 안전을 위해 완전히 논리적으로 우회(Bypass) 및 파괴해 버리며, 다른 어떠한 사용자 개입 조작보다도 가장 폭력적이고 최상단 계층의 인터럽트 우선순위(Highest Preemptive Priority)를 무조건적으로 런타임 보장받는다.

2. 컴파일러 최적화 관점에서의 단일 열거형(Single Enum) 일원화 원칙

초보 펌웨어 개발자들은 C++ 소스를 분해하다가 종종 “왜 이토록 성격이 다른 20개가 넘는 비행 모드들을, 구조체나 배열로 깔끔하게 카테고리를 분할하지 않고 우식하게 0번부터 20번까지 하나의 거대한 1차원 uint8 평면 열거 변수 안에 모조리 몰아넣어 하드코딩했을까?” 라고 의문을 품기 마련이다.

동역학적 성격별로 변수 트리를 나누지 않은 맹목적인 이유는 단 하나, 유한 상태 기계의 절대 무결성(Integrity) 때문이다.

PX4 펌웨어가 촌각을 다투며 실시간으로 작동하는 스핀로크 NuttX RTOS 환경에서는, 동적 메모리 할당 용량이나 CPU 파이프라인 구조상 조건 분기문 예측(Branch Prediction) 실패 페널티가 지극히 까다롭다. 만약 드론이 추락하는 긴박한 시점에서 비행 모드를 확인하려 할 때 2~3개의 복합적인 상태 변수(is_auto == true AND mission_type == 3)를 &&/|| 연산으로 확인해야만 한다면, 이는 C++ 메모리 스택 힙 상의 심각한 동시성 지연 버그(Race Condition)나 예측 불가능한 분기 명령어 패치 오버헤드(Overhead)를 유발할 가장 강력한 잠재적 추락 위험 요소로 변모한다.

따라서 달리는 기체의 현재 상태 머신은 오직 **단 1바이트 크기 환경에서 완벽히 상호 배타적(Mutually Exclusive)**이어야만 한다는 엄격한 흑백 논리 수학적 단일주의(Monolithic) 설계 철학이 시스템 코어에 강제 이식되었다.
만약 메모리에 마킹된 변숫값이 2 (즉, NAVIGATION_STATE_POSCTL) 단 하나라면, 컴파일러는 이 기체가 절대 3 (MISSION)이거나 다른 동시 상태로 겹쳐있지 않음을 if(nav_state == NAVIGATION_STATE_POSCTL) 구문 단 한 번의 단일 CPU 레지스터 원자 단위(Atomic) 사이클 확인만으로 100% 확신하고 스레드를 미친 듯이 가장 안전하게 병렬 전개해 나갈 수 있는 고속도로를 확보하게 되는 것이다.