28.1.1.1.1. 상태 추정(State Estimation) 데이터와 제어 목표(Setpoint) 간의 디커플링 원리

28.1.1.1.1. 상태 추정(State Estimation) 데이터와 제어 목표(Setpoint) 간의 디커플링 원리

PX4-Autopilot의 역학 제어 핵심 아키텍처 사상 중 하나는 “기체가 현재 어디에, 어떤 속성으로 존재하는가(State Estimation)“를 판단하는 객관적 로직과 “기체가 향후 어디로 이동해야 하는가(Setpoint Generation)“를 결정하는 주관적 의도 로직을 데이터 버스(uORB)를 경계로 철저하게 단절(Decoupling)시켰다는 점이다. 본 절에서는 이 디커플링 원리가 uORB 미들웨어 통신 토픽(Topic) 레벨에서 어떻게 수학적이고 구조적인 단방향 파이프라인으로 전개되는지 심층 분석한다.

1. 시스템 내 핵심 데이터 토픽의 구조적 비대칭성

비행 제어 스택을 가로지르는 두 축의 가장 중요한 데이터 스트림은 생성 주체의 철학과 그 데이터의 성격이 완벽하게 비대칭적(Asymmetric)이다.

  • 현재 상태(Actual State) 스트림: 센서 계층과 EKF2(또는 LPE) 모듈에서 반복적으로 생산해 내는 vehicle_local_position (NED 좌표계 기반 3D 위치 및 선속도)와 vehicle_attitude (쿼터니언 기반 3D 회전 및 각속도) 토픽 묶음이다. 이 데이터는 과거부터 현재 프레임까지 누적된 물리적 현상에 대한 관측-보정치이므로, 변할 수 없는 **결과적 진실(Ground Truth Approximation)**을 의미한다.
  • 제어 목표(Setpoint) 스트림: 비행 모드 관리자(Flight Mode Manager의 FlightTask)가 생산하여 하위 제어 계층으로 하달하는 trajectory_setpoint (목표 3D 위치, 속도, 가속도, 저크 벡터)와 vehicle_rates_setpoint (목표 각속도 및 추력 배분량) 토픽 묶음이다. 이 데이터는 인간 조종사나 자율비행 컴퓨터(AI)의 의도가 반영된 가까운 미래의 **도달해야 할 수학적 이상점(Ideal Requirement)**을 의미한다.

PX4 시스템 설계는 이 절대 진실(State)과 이상향(Setpoint) 두 데이터 스트림이 스파게티 코드 내에서 혼용되거나 순환 참조(Circular Reference)되는 것을 프레임워크 차원에서 구조적으로 엄격히 통제하고 금지한다.

2. 디커플링(Decoupling) 원리: uORB 기반 단방향 통신 파이프라인

이러한 디커플링의 핵심 동작 원리는 **“상태 추정기는 제어 목표를 읽으려 하지 않고, 하위 제어기는 상층의 의도를 묻지 않으며, 오직 비행 모드 모듈만이 둘 사이의 간극을 비동기적으로 중재한다”**는 단방향(One-way) 파이프라인 교리(Doctrine)에 기인한다.

  1. Estimator의 맹목성 (Blind Aggregation): EKF2 모듈 내부를 아무리 뜯어보더라도 자신이 현재 ‘위치 제어(Position)’ 중인지 ‘자동 착륙(Auto Land)’ 중인지 모니터링할 변수나 권한 자체가 전무하다. 오로지 자이로, 가속도계, GPS, 비전 오도메트리의 관측 모델 수식을 통해 공분산 행렬 오차를 최소화하여 vehicle_local_position을 순수하게 “발행(Publish)“만 던져댈 뿐이다.
  2. Flight Mode의 브로커 역할 (Broker & Generator): FlightTask 다이나믹 인스턴스는 EKF2가 쏘아 올린 vehicle_local_position 현 상태를 끊임없이 “구독(Subscribe)“하면서 파일럿의 아날로그 조종기 매핑 데이터(manual_control_setpoint)를 조합한다. 이 둘의 미스매치를 부드러운 스플라인/저크(Jerk) 제한 함수로 깎아내어, 0.005초(200Hz) 뒤 기체가 향해야 할 물리적 이상향 궤적을 예측 보간하고 trajectory_setpoint 토픽으로 새롭게 “발행“한다.
  3. Controller의 오차 환원 (Error Minimization): mc_pos_control (멀티로터 위치 제어기) 모듈의 로직은 단순무식하다. 앞선 두 토픽(vehicle_local_position과 trajectory_setpoint)을 동시에 “구독“하는 것이 설계의 전부다. 진실 궤적 벡터와 이상 궤적 벡터 둘 사이의 오차 행렬(Error Matrix)을 도출하고, 오차를 0으로 감쇄시키기 위해 P-I-D 게인에 의존한 물리적 모터 추력(Actuator Control)을 계산 및 생성해 낸다.
sequenceDiagram
    autonumber
    participant EKF as Estimator (EKF2)
    participant FM as Flight Mode (FlightTask)
    participant CTRL as Controller (mc_pos_control)
    
    Loop 250Hz ~ 400Hz (비동기 폴링)
        EKF ->> uORB: Publish: vehicle_local_position (현재 상태 추정 결괏값)
        
        FM -->> uORB: Subscribe & Poll: vehicle_local_position
        Note over FM: 사용자 의도(RC/MAVLink)를 해석하여<br/>가속도 제한이 걸린 스플라인 궤적 산출
        FM ->> uORB: Publish: trajectory_setpoint (도달해야 할 목표 상태)
        
        CTRL -->> uORB: Subscribe & Poll: vehicle_local_position
        CTRL -->> uORB: Subscribe & Poll: trajectory_setpoint
        Note over CTRL: (제어 목표 행렬 - 현재 상태 행렬) 오차 도출 후<br/>Feedforward + PID 피드백 모터 믹싱 산출
    End

3. 인터페이스 의존성(Dependency) 분리를 통한 확장성 극대화 보장

상태(State)와 제어 타겟(Target) 간의 하드웨어/소프트웨어 통합 디커플링 설계는 결과적으로 절차 지향 코드를 넘어선 인터페이스 분리 및 의존성 주입(Dependency Injection) 소프트웨어 아키텍처 패턴의 가장 모범적인 적용 사례다.

가상의 시나리오로, 향후 PX4의 탑재 보드가 업그레이드되어 GPS/EKF2를 덜어내고, 카메라 SLAM 베이스의 타사(Third-party) 최첨단 위치 추정 알고리즘 패키지를 삽입해야 한다고 상상해 보라. 새로운 서드파티 통합 패키지가 오로지 PX4의 uORB 통신 양식에 맞추어 vehicle_local_position 토픽 하나만을 제대로 발행(Publish)해 주기만 한다면 아키텍처적 전환은 그것으로 종료된다.

비행 제어의 꽃인 Flight Mode Manager 모듈이나 하드코어한 컨트롤러(Controller) 소스코드 내부는 단 한 줄의 #include 수정이나 컴파일 헤더 오버헤드 없이, 기존과 100% 동일하게 그저 vehicle_local_position을 읽어 들여 완벽한 자율 포지셔닝 비행을 지속 수행할 수 있다.

이와 같은 상태와 목표 궤적 간의 파이프라인 디커플링(Decoupling) 기술은, 기체 제어 스택의 수많은 컴포넌트들이 오직 하나의 통일된 uORB 인터페이스(Message Interface Specification) 규격 단 하나의 포인트만을 바라보게 함으로써, 궁극적으로 방대한 C++ 펌웨어 소스 전체의 이식성 파편화(Fragmentation)와 아키텍처 부채(Technical Debt)를 제로 수준으로 유지하는 중추적인 댐 역할을 성공적으로 수행하고 있는 것이다.