28.4. 비행 모드 전환(Mode Transition) 및 상태 천이 제어

비행 제어 소프트웨어에서 가장 많은 버그(Bug)와 추락(Crash)이 발생하는 구간은 역설적으로 비행 모드 자체의 논리적 결함보다는, 모드와 모드 사이를 전환(Transition)하는 찰나의 순간에 집중되어 있다.

예를 들어 드론이 15m/s로 맹렬하게 전진하던 수동(Manual) 모드 도중, 조종사가 갑자기 오빗(Orbit) 모드 스위치를 켰다고 가정해 보자. 새로운 오빗 제어기는 이전 수동 제어기가 쌓아둔 물리적 관성과 가속도를 전혀 모른 채 자신의 수학 공식을 0(Zero)부터 시작하려 할 것이다. 그 결과 모터에는 엄청난 역기전력 펄스(Pulse) 명령이 투입되고 기체는 공중제비를 돌며 추락한다.

PX4 아키텍처는 이러한 대참사를 막기 위해, 비행 모드 전환 시점을 단순한 C++ 변수 변경(mode = NEW_MODE;)으로 취급하지 않고, 고도로 정제된 상태 천이(State Machine Transition) 및 범프리스 전송(Bumpless Transfer) 파이프라인으로 관리한다.

1. 전환의 본질: 제어 권한(Authority)의 계승

비행 모드 전환이란 근본적으로 기체의 조종석(Cockpit)에 앉아있는 보이지 않는 파일럿(Flight Task)을 다른 파일럿으로 교대시키는 작업이다.

이때 부기장(이전 모드)이 기장(새로운 모드)에게 조종간을 넘길 때 가장 중요한 것은 “비행기가 현재 어떤 자세로 얼마나 빠르게 날고 있는지“에 대한 운동학적 컨텍스트(Kinematic Context)를 인계하는 것이다. PX4의 FMM(Flight Mode Manager)은 이전 FlightTask가 마지막으로 남긴 _trajectory_setpoint 버퍼의 궤적 역사(History)를 파기하지 않고, 새로 생성된 FlightTask의 초기값(Initial state)으로 부드럽게 주입시킨다.

2. 상태 천이 제어의 핵심 요구사항

PX4의 모드 천이 아키텍처는 다음의 3가지 엄격한 요구사항을 만족하도록 설계되었다.

• 1. 거부 권한 (Denial of Switch):
  모든 모드 천이는 무조건 성공하는 것이 아니다. GCS가 자율 비행(Auto) 명령을 내리더라도, 새로운 모드의 activate() 함수 내부에서 “GPS 신호가 부족하여 자율 비행 초기화 불가“라는 false를 반환하면, FMM은 즉시 전환을 취소(Abort)하고 이전의 안전한 모드로 회귀시킨다.
• 2. 적분기 리셋과 스무딩 (Integrator Reset & Smoothing):
  하위 위치 제어기(PID) 내부에는 이전 모드가 사용하며 쌓아둔 수많은 오차 누적 값(I-term)들이 팽팽하게 당겨진 스프링처럼 뭉쳐있다. 모드가 전환되는 즉시, FMM은 하위 제어기들에게 플래그를 던져 이 적분기들을 0으로 매끄럽게 리셋(Reset)하거나 필터를 걸어 방출(Bleed off)시킴으로써 이음새 없는(Seamless) 부드러운 기동 전환을 보장한다.
• 3. 하드웨어 리소스 해제 보장:
  앞서 다룬 소멸자(Destructor) 단락에서 보았듯, 이전 모드가 독점하던 uORB 통신 채널이나 스레드 락(Lock)을 완전히 풀어주어야만 새 모드가 충돌(Collision) 없이 커널 리소스를 할당받고 부팅을 완료할 수 있다.

이 장에서는 커맨더(Commander)의 모드 변경 트리거가 발생한 순간부터, FMM 내부의 스왑(Swap) 알고리즘을 거쳐 하위 제어기가 적분기를 세탁하며 새로운 궤적에 안착하기까지의 숨 막히는 상태 천이 제어 파이프라인을 추적해 본다.