# 1. `navigator` 모듈의 시스템 아키텍처 및 스케줄링 모델

# 1. navigator 모듈의 시스템 아키텍처 및 스케줄링 모델

PX4-Autopilot의 수많은 모듈 중 navigator 모듈은 자율 비행(Auto Flight)의 두뇌 역할을 담당하는 가장 핵심적인 C++ 애플리케이션이다. 조종사의 조종기(RC) 스틱 입력이 개입하지 않는 모든 종류의 자동 비행 궤적(Waypoint 이동, Loiter, RTL 등)은 이 모듈 내에서 계산되어 하위 제어기(Position Controller)로 전달된다. 본 절에서는 navigator 모듈의 전반적인 시스템 아키텍처와 NuttX RTOS 기반의 스케줄링 모델, 그리고 내부 소스 코드 구성을 상세히 분석한다.

1.1 navigator 모듈의 역할과 시스템 토폴로지

navigator는 GCS(지상 관제 시스템)로부터 MAVLink를 통해 주입된 고차원적 명령(예: “위도 X, 경도 Y로 고도 Z를 유지하며 이동하라”)을 기체의 형상(멀티로터, 고정익, VTOL)에 종속되지 않는 범용적인 3차원 공간 설정점(Position Setpoint)으로 변환하는 계층이다.

Ardupilot이 메인 비행 제어 루프 내에서 모드 객체를 스위칭하는 동기적 방식과 달리, PX4의 navigator는 독립된 백그라운드 프로세스로 동작하며 uORB(Micro Object Request Broker) 메시징을 통해서만 통신하는 철저한 비동기 분산 아키텍처를 따른다. 즉, 모터 제어 지연성(Latency)에 민감한 태스크와 경로를 계획하는 비교적 여유로운 태스크가 분리되어 있다.

graph TD
    A[Vehicle Command <br/> (from commander)] -->|uORB 메시지| N[Navigator Module <br/> (Main Event Loop)]
    B[Vehicle Local Position <br/> (from EKF2)] -->|uORB 메시지| N
    C[Home Position] -->|uORB 메시지| N
    
    N -->|State Machine Evaluation| M[Navigator Modes <br/> (Mission, RTL, Loiter)]
    M -->|position_setpoint_triplet_s| O[Position Controller <br/> (mc_pos_control 등)]
    
    subgraph Navigator Internal
        N
        M
    end

1.2 비동기 이벤트 구동형 스케줄링 모델(Event-driven Scheduling)

navigator 모듈은 고정된 시간 주기로 무한 반복하는 하드 리얼타임(Hard Real-time) 루프 방식이 아닌, 특정 기준 이벤트가 발생했을 때 스레드가 깨어나는 이벤트 구동형(Event-driven) 폴링(Polling) 스케줄링 기법을 채택하였다.

소스 코드(src/modules/navigator/navigator_main.cpp)를 참조하면, 메인 루프는 uORB 구독자(Subscriber)인 vehicle_local_position 토픽의 파일 디스크립터(File Descriptor)를 px4_poll() 함수 시스템 콜을 이용해 대기열 블로킹(Blocking) 상태로 대기시킨다.

  1. Wake-up Trigger: 확장 칼만 필터(EKF2)가 기체의 갱신된 위치 및 속도 추정치(local_position)를 uORB로 퍼블리시하면, px4_poll() 블로킹이 해제되며 스레드가 깨어난다. (통상 50Hz 단위로 동기화)
  2. Data Fetching: 활성화된 스레드는 GCS 명령어 검사, 배터리 상태, GPS 신호 무결성 등 밀려 있던 제반 토픽들을 한꺼번에 Fetch(가져오기)하여 로컬 변수에 갱신한다.
  3. Mode Iteration: 현재 활성화된 Navigator Mode (예: Mission, RTL)의 핵심 갱신 함수인 on_active() 가상 함수를 호출하여 궤적 타겟을 업데이트한다.
  4. Publishing: 연산이 완료된 목표 궤적을 position_setpoint_triplet_s 토픽으로 직렬화하여 하위 위치 제어기에 전달한 뒤, 다시 리소스 점유를 양보하고 수면(Sleep) 상태로 진입한다.

이러한 설계는 불필요한 CPU 사이클 낭비를 원천적으로 억제한다. 특히 자율 에이전트 구성을 위해 동반 컴퓨터(Companion Computer, ROS2 프레임워크 기반)의 VIO 트래킹 모듈과 함께 구동될 때, 시스템 자원 기아 현상(Resource Starvation)을 방지하는 탁월한 스케줄링 효율성을 보장한다.

1.3 다형성(Polymorphism)을 활용한 클래스 설계 패턴

객체 지향 프로그래밍(OOP) 관점에서 navigator 모듈은 유지보수성, 디버깅, 및 기능 확장성을 극대화하기 위해 다형성(Polymorphism) 기반의 최신 C++ 계층적 클래스 설계를 엄격하게 적용했다. 이 설계는 최상위 추상 베이스 클래스인 NavigatorMode를 상속받아 파생 클래스로서 개별 자동 조종 모드들을 구현하는 형태다.

  • Navigator (Main Context Class): 전체 상태 머신의 흐름 관리, uORB 환경의 전역 메시지 구독 및 발행, 파라미터 실시간 업데이트를 총괄하는 허브 역할을 담당한다.
  • NavigatorMode (Base Class): on_inactive(), on_activation(), on_active() 등 생명주기와 관련된 순수 가상 함수 목록을 정의하여, 새로 추가되는 모든 비행 모드가 일정 통일된 인터페이스(API) 규칙을 준수하도록 문법적으로 강제한다.
  • 파생 클래스 (Derived Classes): Mission, Loiter, RTL, Takeoff, Land 클래스는 모두 독립적으로 NavigatorMode를 상속받아 각각 독자적인 궤적 최적화 산술 코드를 보유한다.

소프트웨어 아키텍처 측면에서, 개발자가 PX4-Autopilot에 커스텀 자동 비행 모드를 생성하고자 한다면, 다른 모듈과의 충돌 걱정 없이 단순히 NavigatorMode 베이스 인터페이스를 상속받는 구체 클래스(Concrete Class)를 작성하고 메인 인스턴스 배열 루프에 의존성을 등록하기만 하면 된다. 이는 개방-폐쇄 원칙(Open-Closed Principle)을 준수하는 모던 C++ 비행 제어기 로직의 모범적 구조이다.

1.4 하위 FlightTask 및 Commander 구조와의 결합도 최적화

navigator는 안전 관리의 주체인 기체의 상태 머신 마스터 모듈 commander와 철저히 분리(Decoupling)되어 구동된다. commander는 각종 안전 센서 진단 플래그와 비행 전 점검(Pre-flight Check)을 토대로 Auto 모드에 진입하는 것이 환경적으로 “안전 및 적합한가“를 검증하고 승인할 뿐, 공간상의 위치 제어 경로 생성에는 전혀 관여하지 않는다.

나아가, navigator가 생성한 거시적인 설정점(Setpoint Triplet) 메시지는 멀티로터 위치 제어 모듈(mc_pos_control) 내부의 FlightTaskAuto 인터페이스 층으로 수신된다. 이 브리지(Bridge) 계층을 통해 navigator 모듈은 기체 하드웨어의 PID 튜닝 특성, 틸트 저항 제한, 가속 및 제동률의 튜닝 스위트 파라미터를 인지할 필요 없이, 순수하게 GPS 모델 기반의 ‘궤적 로직(Mapping and Path Algorithm)’ 계산에만 집중하는 매우 높은 도메인 응집도(Cohesion)를 확보하게 되었다.