21.6.2.1. 제어 주파수 및 지연성(Latency) 요구에 따른 분류

PX4의 버스 노선(Work Queue)은 단순히 번호순으로 나열되어 있지 않다. 각각의 버스는 철저하게 “드론의 물리적 움직임을 얼마나 빨리 통제해야 하는가?“라는 **제어 주파수(Frequency)**와 지연성(Latency) 요구 스펙에 따라 촘촘하게 설계되어 있다.

만약 여러분이 드론 펌웨어 코딩 면접에 가서 “모든 센서 필터와 통신 로직을 1000Hz로 똑같이 돌리면 가장 완벽하지 않나요?“라고 대답한다면, 면접관은 웃으며 당신을 집으로 돌려보낼 것이다. CPU의 100%를 연산에 쏟아붓는 것은 비행체의 전력 소모를 극대화할 뿐만 아니라, 가장 결정적인 순간에 중요한 연산이 큐에서 밀려나는 대참사(Starvation)를 유발한다.

따라서 우리는 비행 제어기(Flight Controller) 내부의 우주를 크게 세 가지의 시간대(Time Zone)로 나누어 전략을 짜야 한다.

1. 초고속 실시간 영역 (Hard Real-Time): 1kHz 이상

이 영역은 지연 시간(Latency)이 1밀리초(ms)만 밀려도 기체의 모터가 달달 떨리고 제어 루프가 발산(Oscillation)할 수 있는 무관용의 세계다.

• 주요 승객: 관성 측정 장치(IMU: 자이로스코프, 가속도계) 데이터를 읽어오는 센서 드라이버, 그 데이터를 섞어 기체의 현재 각도를 계산하는 내비게이션 필터(EKF), 그리고 그 각도를 바탕으로 4개 모터의 PWM 신호를 뽑아내는 자세 제어기(Attitude Controller)와 믹서(Mixer).
• 특징: 이 모듈들은 어마어마하게 빠른 속도(1000Hz ~ 4000Hz)로 돌지만, 한 틱(Tick)을 계산할 때 걸리는 시간(Execution Time)은 수십 마이크로초(us) 이내로 극히 짧고 간결해야 한다. 무거운 수학 내장 함수나 I/O 블로킹은 꿈도 꿀 수 없다.

2. 중간 속도 영역 (Soft Real-Time): 50Hz ~ 250Hz

드론이 허공에 뒤집히지 않고 똑바로 서 있는 자세(Attitude)를 잡았다면, 이제 “어디로 갈 것인가?“를 판단하는 두뇌의 시간대다.

• 주요 승객: GPS 데이터를 파싱하여 현재 위도/경도를 산출하는 모듈, 설정된 웨이포인트(Waypoint)를 따라가기 위해 목표 궤적을 만들어내는 위치 제어기(Position Controller), 미션 컴퓨터(Companion PC)와 고속 직렬 통신(MAVLink)을 주고받는 인터페이스 모듈.
• 특징: 이 모듈들은 1초에 50번(50Hz) 뛰는 맥박만으로도 드론의 부드러운 이동을 완벽히 통제할 수 있다. 대신 한 번 틱이 돌 때마다 삼각함수, 행렬 곱셈, 문자열 파싱 등 상대적으로 무거운 CPU 연산을 쏟아낸다. 만약 이 뚱뚱한 연산들을 초고속 라인에 태웠다가는 1ms 안에 연산이 끝나지 않아 전체 시스템 마비(Deadline Miss)를 초래할 것이다.

3. 백그라운드 영역 (Best-Effort): 1Hz ~ 10Hz, 또는 이벤트 기반

이 영역은 천천히 처리되어도 드론이 추락하지 않는 비(非) 비행 임무들을 다룬다.

• 주요 승객: SD 카드에 비행 데이터를 차곡차곡 기록하는 로거(Logger), 배터리 전압이 떨어졌을 때 LED 색깔을 빨간색으로 바꾸고 부저(Buzzer)를 울리는 알람 시스템, USB 케이블이 꽂혔는지 검사하는 감시자 무리.
• 특징: 이 모듈들은 다른 두 등급이 CPU 클럭을 남겨주었을 때만 남는 자원을 주워 먹고 돌아간다(Best-Effort). 아주 가끔 돌지만 I/O 대기(SD 카드 쓰기 등) 때문에 몇 밀리초(ms)씩 스레드가 굳어버리기도 한다.

이 세 가지 계급의 시간대에 맞춰 PX4 시스템은 정확히 매칭되는 버스 노선(wq_rate_ctrl, wq_nav_and_cmds, wq_lp_default)들을 굴리고 있다.
다음 장(21.6.2.1.1과 21.6.2.1.2)에서는 이 각각의 워크 큐 노선들이 실제로 어떤 스택(Stack) 메모리 한계를 지니고 있으며, 운영체제 단위에서 어떻게 분배되는지 현미경을 들이대 보도록 하자.