28.1. PX4 비행 모드(Flight Mode) 시스템 아키텍처 개요

무인항공기(UAV)의 두뇌인 비행 제어기(Flight Controller, FC)의 핵심 임무는 인간 조종사 혹은 외부 관제 컴퓨터(GCS)의 의도(User Intent)를 해석하여, 물리적인 로터(Rotor)와 조종면(Control Surface)의 제어 명령으로 파이프라이닝하는 것이다. 이 과정의 정중앙에서 교통경찰 역할을 수행하는 논리적 추상화 계층이 바로 비행 모드(Flight Mode) 시스템이다. 본 장에서는 오프보드(Offboard) 자율 비행부터 고전적인 수동 제어(Manual)에 이르기까지, PX4-Autopilot이 비행 모드를 어떻게 아키텍처 수준에서 분리하고 객체 지향적(Object-Oriented)으로 관리하는지 개괄적으로 알아본다.

1. 비행 모드의 본질과 역할의 추상화

PX4-Autopilot의 설계 철학은 철저한 **모듈화(Modularity)**와 **디커플링(Decoupling)**이다. 이를 가장 잘 보여주는 계층이 비행 모드 시스템이다.
일반적으로 비행 제어 스택은 크게 세 가지 파이프로 나뉜다.

State Estimation (상태 추정): IMU, GPS, 비전 센서 데이터를 EKF2(Extended Kalman Filter 2)를 통해 융합하여 기체의 현재 상태(자세, 위치, 속도) 최적 추정치를 파악한다.
Trajectory Generation (궤적 생성 및 비행 모드): 조종기 스틱 값(RC PWM)이나 MAVLink/ROS2 명령을 기반으로, 기체가 최종적으로 공간 상에서 추종해야 할 제어 목표(Setpoint) 궤적을 산출한다.
Control (피드백 제어): 캐스케이드(Cascade) PID 제어기 등을 통해 실제 추정된 상태를 목표 추종 상태(Setpoint)로 수렴시키기 위한 구동기 출력(Actuator Control)을 역학적으로 계산한다.

비행 모드 시스템은 바로 구조적 정중앙인 **2번 계층(Trajectory Generation)**을 관장한다. 조종사가 동일하게 스틱을 밀더라도, 현재 체공 상태(예: Position 모드 vs Acro 모드)에 따라 이 입력을 ’목표 위치를 향한 3차원 공간상의 속도(Velocity Setpoint)’로 해석할지, 아니면 ’초당 회전 각속도(Rate Setpoint)’로 해석할지 결정하는 컨텍스트(Context)를 동적으로 제공하는 것이다.

2. Ardupilot과의 아키텍처 설계 비교

오픈소스 기반 무인기 제어 펌웨어의 양대 산맥인 PX4-Autopilot과 Ardupilot은 동일한 제어 목적을 달성하나, 소스 단위의 아키텍처 철학은 확연히 구분된다.

Ardupilot (절차 지향적 제어 사이클): 주로 핵심 전역 객체를 공유하고 mode.cpp와 같은 거대한 순환 제어 사이클 안에서 각 모드의 제어 로직이 절차적으로 수행되는 방식(Monolithic approach)을 강하게 취한다. 코드 로직이 직관적이지만 특정 기능 추가를 위해 공통 루프를 훼손하면 격리(Isolation) 독립성이 떨어져 잠재적 폴트 폭포(Fault Cascade)를 유발할 수 있다.
PX4-Autopilot (객체 지향적 자율 분산 시스템): 시스템은 마이크로커널인 NuttX RTOS 상에서 독립적인 태스크 워크 큐(Work Queue)로 동작한다. 제어 로직 간 데이터는 **uORB (Micro Object Resource Broker)**라는 발행/구동(Publish/Subscribe) 미들웨어를 통해서만 비동기적으로 중개된다.

특히 PX4 내부에서 비행 모드는 FlightTask라는 다형성을 내포한 순수 가상 C++ 베이스 클래스를 상속받아 구현된다. MAVLink 명령으로 Flight Mode가 전환될 때마다 런타임 폴링 엔진이 동적으로 해당 파생 클래스(Derivative Task Class)를 스위치 하여 일관된 규격의 제어 목표 메시지(trajectory_setpoint.msg)를 생산 및 하달한다. 이 구조체계 덕분에 컴퓨터 비전 기반 ROS2 uXRCE-DDS 미들웨어와의 브리지 구축 시 코어 소스코드의 파손 없이 완벽히 분리된 연동 로직(Sandboxing) 구현이 기능하다.

3. 설정 및 관제(GCS) 생태계와의 통신망 연동

보드 단의 플래시 메모리 구역에서 동작하는 로컬 비행 모드의 상태(nav_state)는, MAVLink 통신 텔레메트리의 심장 박동인 HEARTBEAT 메시지와 VEHICLE_STATUS 패킷을 통해 주기적으로 1Hz 단위로 지상 관제 시스템(QGroundControl)으로 브로드캐스팅(Broadcasting)된다.

상태 동기화 및 락(Lock) 체계: Commander 모듈에서 관리하는 안전 허가 요건(GPS 3D Lock 여부, RC 통신 유실 상태 등)이 충족되지 않은 상황이라면, 관제 시스템이 MAVLink 명령 패킷(MAV_CMD_DO_SET_MODE)으로 특정 모드 활성화를 타진하더라도 제어권은 즉각 반려(Rejection) 처리되거나 차상위 안전 모드(예: Altitude, Stabilize)로 강하(Fallback) 처리된다.
ROS2 연동 자율 비행(Autonomous Offboard Flight): 최근 고성능 엣지 컴퓨팅(Jetson Orin 등)은 SLAM 비전 AI 장애물 회피나 추적(Tracking)을 전담하고, 픽스호크는 오직 비행 동역학만 맹목적으로 제어한다. 이 역할을 나누기 위해 PX4는 특수한 OFFBOARD 모드를 활성화한다. 외부 컴퓨터에서 퍼블리싱되는 유효한 외부 제어 주기 트리거 토픽(Topic)이 0.5초(Timeout limit) 간격 이상으로 누락되지 않고 도착해야만 동작을 승인하는 깐깐한 타임아웃 펜스를 세우고 있다.

4. 소스 코드 빌드 환경 및 내부 디렉터리 체인

PX4 저장소 내부, 비행 모드의 핵심 소스 베이스는 최상단 src/modules/flight_mode_manager 디렉터리에 군집화되어 있다. 파일 빌드 엔진인 CMakeLists.txt 체인 규칙을 살펴보면, tasks/ 서브 디렉터리의 각 모드들은 모듈 단위로 컴파일 링크 여부를 개별 스위칭할 수 있도록 구성되어 있다.
이는 하드웨어의 SRAM(Memory Footprint)이나 플래시 메모리 용량 제약(예: 구형 Pixhawk 2 CubeBlack 프로세서의 한계)에 따라, Kconfig 인터페이스를 통해 불필요한 비행 모드 바이너리를 빌드 과정에서 완전히 삭제하여 파편화를 막기 위한 전략적 프레임워크 설계의 산물이다.

본 28.1장에서는 개괄적인 구조를 소개했다. PX4의 비행 모드 아키텍처는 이처럼 안정적인 상태 천이(State Transition)를 담보하는 시스템 레벨의 방어적 프로그래밍(Defensive Programming)과 기능 확장을 열어두는 C++ 소프트웨어 디자인 패턴이 교차하는 아름다운 교차로이다. 이어지는 장에서는 이 거대한 구조체들이 FlightTask 코어 시스템과 uORB 토픽 버스로 어떻게 긴밀히 맞물려 동작하는지 체계적으로 해부할 것이다.