27.4.1. 상태 지연 문제의 정의

1. 개요 (Introduction)

현대의 무인항공기(UAV) 비행 제어 시스템은 단일 센서에 의존하지 않고 다중 센서 융합(Multisensor Fusion)을 통해 기체의 3차원 위치와 자세를 정밀하게 추정한다. PX4-Autopilot의 기본 추정기인 EKF2 (Estimation and Control Library, ECL)는 관성 측정 장치(IMU), GPS, 지자계 센서, 기압계, 그리고 외부 계측 장비(VIO 등)를 동시에 활용한다.

그러나 모든 센서는 측정(Measurement) 이벤트가 발생한 시점과 그 측정값이 비행 제어기(Flight Controller, FC)의 알고리즘 메모리로 진입하는 시점 사이에 물리적, 논리적 시차가 존재한다. 이를 상태 지연(State Delay) 혹은 타임스탬프 비동기화(Timestamp Asynchronization) 문제라고 정의한다. 이 지연을 수학적으로 모델링하고 EKF 추정기 내에서 정교하게 보상하지 않을 경우, 시스템은 과거의 관측치와 현재의 로컬 상태를 잘못 혼합하게 되어 추정 오차가 급격히 발산(Divergence)하는 치명적인 결과를 맞이하게 된다.

2. 상태 지연(State Delay)의 기술적 원인

다양한 센서 계측 데이터가 Pixhawk와 같은 중앙 제어 장치의 EKF 연산 루틴에 도달하기까지 발생하는 지연은 여러 단계의 소프트웨어 및 하드웨어 파이프라인에 걸쳐 누적된다.

2.1 하드웨어 측정 및 알고리즘 프로세싱 지연 (Sensory Processing Delay)

물리적인 연속 스펙트럼의 환경 변화가 디지털 샘플링 데이터로 변환되는 과정에서 발생하는 지연이다.

• GPS (GNSS) 모듈: 수신기 안테나가 위성의 전파를 수신한 후, 다중 경로(Multipath) 오차를 보정하고 측위 해(Fix Resolution) 알고리즘을 계산하여 NMEA나 U-BLOX 프로토콜 패킷으로 직렬화하는 데 상당한 코어 프로세싱 시간이 소비된다 (보통 50ms ~ 150ms 수준).
• 비전 기반 포지셔닝 센서 (VIO / Optical Flow): 이미지 센서(Camera)의 노출 시간(Exposure time)을 비롯 프레임 그래버(Frame Grabber) 전송, 그리고 특징점 추출 및 추적(Feature Extraction & Tracking)을 수행하는 컴퓨터 비전 연산 인프라에서 매우 거대한 연산 지연이 발생한다. ROS2와 라즈베리파이 등 컴패니언 컴퓨터 사용 시 가변적으로 50ms ~ 200ms 이상의 지연이 나타난다.

2.2 통신 버스 인터페이스 지연 (Communication Bus Latency)

센서 모듈에서 생성된 데이터 패킷이 물리적 와이어를 타고 FC로 이동하는 소요 시간이다.

• I2C / SPI: 기판 내부에 장착된 내장 센서(주로 가속도계/자이로스코프 IMU)와 통신하므로 시간 지연이 1 마이크로초(\mu s) 수준으로 매우 작아 실시간성을 최전선에서 담보한다.
• UART (Serial) / CAN: 위성 항법 장치 프로토콜 스택이나 원거리 텔레메트리와 같이 직렬 데이터 규격을 통해 수신받는 인터페이스에서는 데이터 크기 및 보드레이트(Baudrate) 병목 현상, 그리고 외부 노이즈(EMI)에 의한 체크섬 에러 재전송 등으로 밀리초(ms) 단위의 물리적 전송 누적 지연이 필연적으로 발생한다.

2.3 운영체제 스케줄링 및 메시징 미들웨어 지연 (OS & Middleware Latency)

• uORB 메시징: PX4는 실시간 운영체제인 NuttX RTOS 기반 하에 동작하며, 하드웨어 디바이스 드라이버가 센서 데이터를 읽어 들인 뒤 uORB(Micro Object Request Broker) 퍼블리시(Publish)를 수행한다. 이후 EKF2 쓰레드 모듈이 이 토픽을 구독(Subscribe)하여 자기 자신의 메모리 공간으로 카피오버 하기까지 스케줄러(Scheduler)의 선점 상황에 따라 시차가 더해진다. (최근 아키텍처에서 확립된 ROS2 uXRCE-DDS 브리지 연동 시에는 네트워크 스택까지 거치며 이 지연폭의 분산이 더욱 커진다.)

3. 센서 간 지연 프로파일 및 비동기화 양상

PX4-Autopilot 환경(펌웨어 v1.14 기준)에서 주요 센서들을 스펙터클하게 비교해 보면, IMU 데이터가 거의 실시간에 도달하는 것에 비해 나머지 관측치 측정은 항상 후행(Lagging Measurement)하는 비대칭 특성을 갖는다. 아래의 수치는 일반적인 설정에서의 지연 범위 모델이다.

표 내 수식의 세로선은 \vert 구분자를 따른다.

4. 지연을 무시한 EKF 융합이 유발하는 수리 모델 붕괴 과정

만일 EKF 추정기가 이와 같은 지연 메커니즘을 묵살하고, 단순히 ’데이터가 EKF 모듈 내부로 진입한 시점’을 곧 ’해당 측정 이벤트가 발생한 시점’으로 잘못 간주하게 되면 시스템 동역학적으로 치명적인 붕괴 사이클이 나타난다.

1. 드론의 글로벌 상태 벡터 X_{t}는 IMU 모델 적분을 통해 현재 실시간 시간(T_{now})으로 민첩하고 빠르게 갱신되어 나간다.
2. 이때 EKF에 갓 도착한 외부 GPS 측정 벡터 Z_{k}는 과거의 시점인 T_{now} - \Delta t_{delay} (예: 150ms 전)에 측정된 기체의 지나간 글로벌 위치이다.
3. 필터는 이 두 극명히 다른 시간 선상을 동일 시간으로 매핑하고, 혁신 잔차(Innovation Residuals)를 구하기 위한 칼만 이득(Kalman Gain) 연산 및 업데이트를 무리하게 진행한다.
4. 결과적으로, 필터 시스템은 현재 고속 전진 중인 기체가 순식간에 150ms 이전의 위치 축으로 되돌아갔다고 착각(도우미 역효과)하게 되어, 튀어버린 오차 위치를 극복하려는 무작위 가속 피드백 명령을 위치/속도 제어 모듈(Position Controller)에 하달하게 된다.
5. 이러한 억지 오차 피드백 현상이 누적되면 자세/위치 제어 루프가 걷잡을 수 없이 진동(Oscillation)하며, 최악의 경우 Ardupilot 및 PX4 시스템에서 공통적으로 직면하게 되는 기체의 스핀아웃 크래시(Crash)나 수렴 발산(Divergence) 현상으로 직결된다.

5. 듀얼 타임라인 시각화 다이어그램

이러한 상태 지연과 도착 비동기화의 갭을 직관적으로 이해하기 위해 고속 IMU와 저속 지연 센서(GPS) 간의 정보 전달 이벤트 타임라인을 병렬 도식화한다.

sequenceDiagram
    participant P as Physical World
    participant I as IMU (Base)
    participant G as GPS (Lagged)
    participant FC as PX4 EKF2

    Note over P: 드론 물리적 이동 시작 (t=0)
    
    P->>I: 기계적 가속도/각속도 변화 인가
    I->>FC: [t=1ms] 즉각적인 UART/SPI 전달 및 필터링 완료
    Note over FC: 기체 현재 상태 (State t=1ms) 적분
    
    P->>G: 위성 신호 RF 변화 파악
    G->>G: [t=70ms] U-Blox 칩 내부 연산 및 Multipath 보정
    G->>G: [t=120ms] UART 패킷 NMEA Serialization
    G->>FC: [t=130ms] uORB 메시지 배포 및 EKF 도착
    
    Note over FC: 130ms 과거에 측정된 GPS 위치와 <br>현재 130ms 동안 적분해온 IMU 위치 정보가 <br>동시에 EKF 업데이트 보드에 투입됨 (비동기성 발생)

이렇듯 상태 지연은 관측의 ’후행성’이라는 거대한 난제를 낳으며, PX4 ECL 아키텍처는 이를 극복하기 위해 물리적 측정의 순서를 복원하는 타임머신 역할인 ‘과거 롤백(Rollback)’ 및 ‘링 버퍼(Ring Buffer)’ 체계를 그 기반에 두고 있다. 타 시스템 대비 PX4가 제공하는 고도의 추정 안정성은 이 지연에 대한 완벽한 통제력에서 비롯된다.