28.2.1.1.1. `wq:nav_and_controllers` 큐 내에서의 Flight Mode Manager 우선순위(Priority) 배정

28.2.1.1.1. wq:nav_and_controllers 큐 내에서의 Flight Mode Manager 우선순위(Priority) 배정

임베디드 리얼타임 스케줄러(RTOS) 환경에서는, 한정된 CPU 코어 위에서 수많은 마이크로 앱 데몬들이 동일한 하나의 워크 큐(Work Queue) 스레드를 강제로 공유(Sharing) 할 때, 그 방 안에서 과연 누가 먼저 마이크를 뺏어 잡고 연산할 것인지(실행 우선순위 및 스케줄링 순서)를 정하는 아키텍처적 조율이 펌웨어 시스템 전체의 액추에이터 제어 지연 시간(Control Latency) 생사를 결정짓는 핵심 병목(Bottleneck)이 된다.

Flight Mode Manager(이하 FMM) 데몬은 PX4 스레드 풀 생태계 중에서도 가장 치열하고 타임 크리티컬(Time-critical)한 nav_and_controllers (실시간 항법 및 물리 제어 전용) 워크 큐의 심장부 한가운데에 무겁게 배정되어 숨 가쁘게 살아간다.

1. nav_and_controllers 워크 큐(Work Queue)의 무거운 거주민들

FMM 데몬이 탑승을 강제당한 이 고순위(High Priority) 커널 스레드 워크 큐 방 안에는 FMM 혼자만 쾌적하고 외롭게 존재하는 것이 결코 아니다. 이륙부터 비행의 끝을 물리적으로 책임지는 다음과 같은 무시무시한 파이프라인 데몬 몬스터들이, 이 좁은 스레드 스택 메모리 공간 하나를 처절하게 셰어링하며 어깨를 부딪치며 합숙하고 있다.

  • navigator: 웨이포인트(Mission) 및 RTL 등 거시적 글로벌 로직을 계산하는 느긋한 항법사
  • flight_mode_manager: 방금 전 항법 의도를 읽어 당장의 3D 물리 궤적로 번역하는 브로커 (주인공)
  • mc_pos_control / fw_pos_control: FMM의 궤적을 쫓아가기 위해 롤/피치 타각을 만들어내는 위치/자세 제어기
  • mc_att_control / mc_rate_control: 찰나의 흔들림을 잡아 실제 모터 회전역학 Rate을 계산하는 초고속 최하단 자세 제어기

2. uORB 연쇄 사슬에 의한 암묵적 우선순위(Implicit Priority) 파이프라인의 마법

이렇게 무거운 메인 크리티컬 타스크 모듈들은, OS 커널단 코드에서 명시적으로 “네가 1등, 그다음 너는 2등” 같은 하드코딩된 스케줄링 번호표를 촌스럽게 부여받지 않는다. 대신, PX4는 uORB 미들웨어의 토픽 발행(Publish)과 구독 인터럽트(Subscribe Callback)의 인과관계 사슬을 통해 마법처럼 우아하게 순일한 순차적 파이프라인 우선순위를 하향식으로 물 흐르듯 자연스럽게 형성해 낸다.

  1. 최상단 EKF2의 선제 타격 발진: 독립 스레드로 돌아가는 센서 칼만 필터 EKF2가 융합된 vehicle_local_position 토픽을 냅다 uORB 파이프에 비동기 발행(Publish)한다.
  2. FMM의 연쇄 기상(Wake-up) 및 우선 선점: 이 토픽을 구독(Subscription Trigger)하도록 큐에 걸어두었던 FMM의 Run() 함수가 즉시 인터럽트를 받아 nav_and_controllers 워크 큐 스케줄러 대기열 맨 앞부분으로 편입되어 가장 먼저 CPU를 선점 실행된다. FMM은 부리나케 이번 단일 틱 루프의 목표 수학치인 trajectory_setpoint 토픽을 짜내어 하단 우체통에 발행하고 쿨하게 스레드에서 퇴장해 버린다.
  3. 하단부 제어기들의 폭력적 후속 기상: FMM이 방금 막 갓 구워내 발행한 trajectory_setpoint 토픽이 파이프에 도착하자마자, 이를 오매불망 구독하며 입을 벌리고 기다리고 있던 하단의 물리 블루칼라 제어기(mc_pos_control) 데몬이 즉각 연쇄적으로 인터럽트 콜백을 받아 FMM이 방금 막 빠져나간 따뜻한 CPU 빈자리를 거칠게 치고 들어와 연속 실행(Cascade Execution) 된다.

결과적으로 FMM은 전체 제어 통로망 스케줄링에서 [EKF2(상태 추정) \rightarrow FMM(궤적 생성 선점) \rightarrow Pos Control(기체 제어 추종)] 으로 이어지는 폭포수(Waterfall) 파이프라인의 정중앙에 완벽하게 자연 위치하게 되며, 절차적 런타임 우선순위 프론트를 하드코딩 없이 아키텍처적으로 완벽하게 점유하게 된다.

3. 블로킹(Blocking) 금지 절대 원칙과 철저한 협력적 멀티태스킹(Cooperative Multitasking)

FMM이 이토록 무시무시하고 한 치의 지연도 용납되지 않는 nav_and_controllers 워크 큐 지붕 아래에 함께 합숙 동거하고 있다는 사실은, 외부 플러그인 프로그래밍 개발자 입장에서 볼 때 소프트웨어 공학적으로 매우 무섭고 끔찍한 잠재적 록업(Lock-up) 위험성을 내포한다.

  • 만약 신입 개발자가 카메라 커스텀 비행 모드(Custom Flight Task)를 하나 신규 추가하면서, while 무한 루프를 돌며 이미지 I/O 폴링을 대기한다거나(Blocking I/O), 지나치게 무거운 매트릭스 역행렬 부동소수점 수학 계산 연산을 집어넣어 FMM의 Run() 함수 단일 실행 시간이 스케줄러 타임아웃 경계인 1밀리초(ms)를 훌쩍 허무하게 넘겨버리면 어떻게 될까?
  • 동일한 커널 스레드 큐 뒤에서 인터럽트를 받고 조용히 대기하고 있던 mc_pos_control과 mc_att_control 초고속 하위 물리 제어기들은, 앞선 이기적인 FMM이 CPU 마이크를 놓아주고 return 할 때까지 단 한 줄의 C++ 제어 코드도 실행되지 못한 채 스케줄러 보드에서 영구적으로 지연되어 굶어 죽게(Starvation) 된다. 이는 즉각적인 프로펠러 모터의 동력 궤적 제어 상실과 기복 롤링 현상, 최악의 경우 공중 드론 추락을 무조건적으로 의미한다.
  • 따라서 FMM 내부 팩토리를 관통하여 생성되는 그 어떠한 사제 사용자 커스텀 비행 모드라 할지라도, **자신의 복잡한 궤적 래핑 연산을 마이크로초 단위 최소 사이클로 눈썹 흩날리게 단칼에 끝마치고 즉시 반환(Return)하여, 워크 큐 스레드의 절대적 CPU 점유권을 뒤에서 기다리는 물리 제어기 형제들에게 신사적으로 즉시 양보해야만 하는 엄격하고도 잔혹한 타임 쉐어링 도덕률(Extreme Rule of Cooperative Multitasking)**의 십자가를 설계 초기부터 숙명적으로 짊어지게 된다.