28.1.1. 제어 스택 내 비행 모드의 위상 및 추상화 모델

픽스호크(Pixhawk) 하드웨어 기반의 PX4-Autopilot 생태계 내에서, 비행 제어 스택(Flight Control Stack)은 매우 정교하게 층(Layer)이 분리된 아키텍처를 지닌다. 이 복잡한 스택 내부에서 **비행 모드(Flight Mode)**는 상태 추정기(State Estimator)와 저수준 제어기(Low-level Controller) 사이를 이어주는 결정적인 중간 매개체, 즉 추상화(Abstraction) 모델로 기능한다.

1. 제어 스택의 3단계 파이프라인(Pipeline) 구조

비행 제어가 이루어지는 전 과정을 데이터의 흐름 단위로 도식화하면 크게 ’인지(Perception) -> 판단 및 궤적 생성(Planning & Trajectory Generation) -> 행동(Action)’의 3단계로 나눌 수 있다. PX4는 이 세 단계를 철저한 모듈 디커플링(Decoupling) 모델로 구현했다.

graph TD
    %% 1단계: 인지 (상태 추정)
    subgraph EstimationLayer [1. State Estimation Layer (Estimator)]
        IMU(IMU/Gyro/Accel) --> EKF2[EKF2 / LPE]
        GPS(GPS / RTK) --> EKF2
        MAG(Magnetometer) --> EKF2
        VISION(VIO / Odometry) --> EKF2
        EKF2 -->|vehicle_local_position \n vehicle_attitude| FM
    end

    %% 2단계: 판단 (비행 모드 및 궤적 생성)
    subgraph ModeLayer [2. Flight Mode Layer (Trajectory Generator)]
        RC(RC Input / Joy) --> FM[Flight Mode Manager \n (FlightTask)]
        MAV(MAVLink / Offboard) --> FM
        FM -->|trajectory_setpoint \n vehicle_rates_setpoint| CTRL
    end

    %% 3단계: 행동 (제어기 및 구동기)
    subgraph ControlLayer [3. Control & Actuation Layer (Controller)]
        CTRL[Position / Attitude \n Controller (mc_pos_control 등)] --> MIX[Mixer / Control Allocation]
        MIX -->|actuator_controls| PWM[PWM / DShot Drivers]
        PWM --> MOTOR(Motors / Servos)
    end

1.1 단계: 상태 추정 계층 (State Estimation Layer)

가장 꼭대기에는 수많은 원시 센서(Raw Sensor) 데이터를 융합하는 EKF2(Extended Kalman Filter 2) 모듈이 위치한다. 이 모듈의 유일한 역할은 ’현재 기체 공간 좌표계(Local/Global Frame) 상에 어디에 있고, 어떤 방향을 바라보며, 어느 속도로 움직이고 있는가?’를 확률적으로 계산해 내는 것이다. 산출된 결과물은 vehicle_local_position.msg와 vehicle_attitude.msg 토픽으로 uORB 버스에 발행(Publish)된다.
중요한 점은, 이 계층은 오직 물리 법칙과 센서 수식에만 관여하며, 기체가 ’자동 모드’인지 ’수동 모드’인지는 전혀 알지 못한다는 것이다.

1.2 단계: 비행 모드 계층 (Flight Mode Layer - 중추)

제어 스택의 정중앙에 위치하는 이 계층이 바로 본 28단원의 핵심인 Flight Mode Manager 모듈이다. 조종사의 조종기(RC 스틱) 입력이나 MAVLink/ROS2를 통한 외부 제어 명령(User Intent) 데이터가 이 계층으로 유입된다.
현재 활성화된 비행 모드(FlightTask)가 무엇이냐에 따라, 동일한 사용자 입력이라도 완전히 다른 **목표 궤적(Setpoint)**으로 해석된다.

예: Position 모드에서 스틱을 위로 밀면 ‘전진 속도(Forward Velocity) 5m/s’ 라는 trajectory_setpoint가 생성된다.
예: Acro 모드에서 스틱을 위로 밀면 ‘초당 피치 회전율(Pitch Rate) 100deg/s’ 라는 vehicle_rates_setpoint가 생성된다.

비행 모드는 인간/컴퓨터의 복잡한 추상적 요구사항을 하위 제어기가 이해할 수 있는 순수한 수학적 벡터 데이터(위치, 속도, 가속도, 저크(Jerk))로 정규화(Normalization)하여 토픽으로 하달한다.

1.3 단계: 제어기 및 구동 계층 (Control Layer)

**위치 제어기(Position Controller)**나 자세 제어기(Attitude Controller) 모듈의 역할은 대단히 단순 명료해진다. 1단계에서 올라온 ’내 기체의 현재 상태’와 2단계에서 하달된 ‘비행 모드가 원하는 목표 궤적(Setpoint)’ 두 개의 데이터만을 uORB로 구독(Subscribe)한다.
이후 PID 연산을 통해 둘 사이의 오차(Error)를 0으로 수렴하게 만들 모터의 회전율을 계산하는 역할만 수행한다. 이 계층 역시 현재 비행기 상태가 ’이륙 모드(Takeoff)’인지 ’복귀 모드(RTL)’인지 알 필요가 없다.

2. 추상화 아키텍처가 주는 공학적 혜택

만약 PX4에서 완전히 새로운 자율 비행 알고리즘, 예를 들면 ’수면에 레이저를 쏘아 일정 1m 고도를 파도에 맞춰 유지(Wave Surfing)하는 모드’를 개발해야 한다고 가정하자.
Ardupilot의 과거 아키텍처 방식의 철학이라면 센서 읽기, 고도 연산, 모터 제어까지 이어지는 파이프라인 전체를 모드(Mode) 파일 안에 버무려 건드려야 할 수도 있다.

하지만 PX4의 추상화된 디커플링 패러다임 하에서는 오직 2단계 구간의 FlightTask 단일 C++ 클래스만 새로 상속받아 개발(Custom Flight Task) 하면 된다. 이 클래스 코드 안에서 레이저 데이터를 읽어 위아래 Z축 속도 명령(trajectory_setpoint.velocity[2]) 토픽으로 쏴주기만 하면, 1단계의 센서 필터나 3단계의 캐스케이드(Cascade) 제어기는 코드를 한 줄도 수정하지 않고도 완벽하게 동작하게 된다.

이러한 모듈식 추상화 구조는 개발의 파편화를 막아주며, 학계나 산업계에서 PX4를 베이스로 수많은 ROS2 기반 자율 에이전트(Autonomous Agent)가 쉽게 이식될 수 있었던 핵심 설계적 요인이다. 다음 단원에서는 이 2단계 계층 최상위 인터페이스 내부에서 일어나는 상태 추정 데이터와 제어 목표(Setpoint) 간의 완벽한 분리(Decoupling) 메커니즘을 심층적으로 고찰할 것이다.