28.2. Flight Mode Manager (flight_mode_manager) 핵심 모듈 분석

PX4 펌웨어의 거대한 제어 아키텍처 생태계에서 Flight Mode Manager (이하 FMM) 데몬 애플리케이션 모듈은 가장 방대한 트래픽을 처리하면서도 가장 우아하게 정제된 통제 인터체인지(Interchange) 브로커다.

이 모듈은 인간 조종사의 조종기 스위치나 지상 GCS가 내린 고차원적인 비행 정책(예: “그 자리에 멈춰라!”, “집으로 즉시 돌아와라!”) 인텐트(Intent)를, 최하단 물리 모터 믹서(Mixer)가 컴퓨터로서 알아들을 수 있는 저차원적인 3차원 공간 가속도 궤적 계산식(Trajectory Setpoint Vector)으로 고속 번역해 내는 유일무이한 마이크로서비스 팩토리(Factory) 베이스캠프다.

1. FMM 커널 시스템의 아키텍처적 위상 및 존재 이유

앞선 상태 머신 챕터에서 숱하게 강조했듯, 최고 사령부 데몬인 Commander 앱의 유일한 의사 결정 결과물은 그저 1바이트짜리 nav_state (예: 3번, 4번) 열거형 숫자 메모리에 불과하다. Commander는 현재 배터리와 센서 데이터가 유효한지 생존 가부(Validity)만 엄격하게 체크한 뒤 상태 번호표만 uORB 통신망에 시크하게 던진다.

반대로 C++ 스택 최하단에서 기다리는 블루칼라 제어기인 mc_pos_control(멀티로터 위치 제어기) 데몬은 오직 ‘그래서 지금 현재 시간(t)에서 X, Y축으로 초당 몇 미터(m/s) 속도로 달려야 하는가?’ 포맷으로 수학적으로 완벽히 정규화된 trajectory_setpoint.msg 토픽 데이터 덩어리만 애타게 기다리며 구독할 뿐이다.

• 이 두 집단 극단적인 상단의 이상향(Abstract Policy)과 최하단의 물리적 공학 수학(Physical Matrix) 간의 어마어마한 언어적 공백(Abstract Gap)을 완벽하게 이어주는 미들웨어 브로커 데몬이 바로 flight_mode_manager 모듈이다.
• FMM 데몬은 스스로 자신의 cpp 코드 내부에는 그 어떤 복잡한 자율 비행 수학 계산이나 PID 제어기 로직도 소유하고 있지 않다. 오직 어느 비행 수학 전문가 객체(FlightTask 서브 클래스)를 램(RAM) 영역에 띄워 채찍질하여 궤적을 토해내게 만들 것인가만을 결단하고 집행하는 냉혹한 인력 파견 소장(Factory Manager) 역할의 극의를 보여준다.

2. FMM 데몬의 3대 핵심 임무 로직 (Core Responsibilities)

2.1 비행 상태 폴링 모니터링 및 동적 태스크 스위칭 (Dynamic Task Switching)

FMM 데몬은 매 틱 스케줄마다 쉬지 않고 vehicle_status 토픽을 넌블로킹(Non-blocking) 비동기 폴링(Polling)하며 상부의 nav_state 번호표가 바뀌었는지 날카롭게 감시한다.
순간적인 모드 변경이 감지되면 내부의 무거운 switchTask() 트랜잭션 함수를 호출하여 C++ 다형성(Polymorphism) 기반 팩토리 트리를 가동시킨다. 새롭게 요구되는 FlightTask 객체를 new 연산자로 램의 빈자리에 갓 찍어내어 통제권 포인터를 위임하고, 수명을 다한 이전 모드 객체는 잔인하게 파괴(delete)하여 메모리 위에서 한 치의 끊김도 없는 비행 모드 핫스와핑(Hot-swapping) 절차를 집행한다.

2.2 객체 생명주기 통제 및 페일세이프 록인 (Lifecycle Fallback Management)

새로 생성 램에 띄워진 비행 모드 객체에 대해 FMM은 즉각적으로 activate() 초기화 검증 가상 함수를 강제 실행한다.
만약 외부 동반 컴퓨터가 다운되어 Offboard 타스크가 에러를 뱉거나, GPS가 갑자기 먹통이 되어 Mission 타스크가 위치 이노베이션 오차 한계를 초과해 활성화를 펄쩍 거부(false 리턴)하면 어떻게 될까? FMM 매니저는 즉시 이 실패 플래그를 로깅한 뒤, 하위 고도 보위 의존 태스크(Altitude Control) 등으로 강제 우회 다운그레이드 매핑(Fallback Degradation) 결정을 단독으로 내려버린다. 이는 기체의 모드가 전환되는 아찔한 공중 과도기(Transitional Phase)에서 모터가 얼어붙는 소프트웨어 다운타임(Downtime) 데드락을 원천 차단하는 파워풀한 시스템 생존 기작을 보장한다.

2.3 최종 궤적 매트릭스 생성 및 메시지 발행 (Trajectory Setpoint Publishing)

성공적으로 승인받아 활성화된 FlightTask 객체에 대해 FMM은 자신의 메인 작업 큐(Work Queue) 루프에서 무한 반복적으로 update() 가상 함수만을 일정 간격으로 채찍질하듯 호출해 댄다.
이를 통해 그 안의 미션 알고리즘 객체나 수동 조종 파서 객체가 열심히 빚어낸 3차원 [위치, 속도, 가속도, 저크(Jerk)] 물리 벡터 형상 집합체를 반환 구조체로 얻어낸다. FMM은 최종적으로 이 날 것의 벡터 값들을 규격화된 포장지에 예쁘게 래핑(Wrapping)하여 trajectory_setpoint.msg 토픽 구조체 팩으로 uORB 그물망 통신 채널에 뿌려버리고(Publish) 다음 틱(Tick)을 준비한다.

3. 총괄 요약: 진정한 무상태(Stateless) 브로커 디자인 패러다임

src/modules/flight_mode_manager/flight_mode_manager.cpp 핵심 소스 코드를 막상 C++ IDE에서 열어보면, 수천 줄의 방대한 비행 모드가 얽혀 있음에도 불구하고 코드가 의외로 한 화면에 다 들어올 정도로 짧고 간결한 충격적인 모습에 놀라게 된다.

FMM 데몬 그 자체는 특정 비행 모드의 내부 지역 변수, 웨이포인트 배열 오프셋 크기, 현재 조종기 스틱 타각 버퍼 같은 상태값들을 자신 안에 구질구질하게 전역으로 보관(Stateful)하거나 공유하지 않기 원칙을 지키기 때문이다.
이 데몬은 펌웨어 가상 메모리 공간을 흘러 다니는 이기종의 파생 C++ 수학 객체(Objects)들을 오직 적재적소에 생성(Create)하고 파괴(Destroy)하며, 그들의 멱살을 잡아 표준화 약속된 update() 율법 함수만 무식하게 강제로 실행시키고 결과물을 토스하는 진정한 의미의 **비동기 오케스트라 지휘자(Asynchronous OOP Conductor)**로서, PX4 커널 아키텍처 특유의 모던한 디자인 우아함을 여실히 증명해 내고 있다.