18.5.4.2. uORB::SubscriptionInterval: 지정된 Hz 이하로 수신 빈도를 제한하는 델타 타임(Delta Time) 검증 로직

현대 비행 제어 소프트웨어 환경에서는 센서 드라이버가 토픽(Topic)을 생산(Publish)하는 속도(Rate)와 상위 애플리케이션 모듈이 해당 데이터를 소비(Consume)하기 원하는 최적의 타이밍이 항상 일치하지는 않는다. 예를 들어, 하드웨어 타이머 인터럽트에 맞물린 자이로스코프(IMU) 드라이버는 1,000Hz 이상의 초고주파로 버퍼를 갱신해대지만, 시스템 배터리 잔량을 모니터링하거나 단순 백그라운드 로깅(Logging)을 수행하는 비핵심 스레드는 굳이 1,000Hz 주기로 매번 깨어나 시스템 버스를 낭비할 하등의 이유가 없다.

이러한 “생산과 소비 주파수 간의 비대칭성“을 시스템 파괴(Overload) 없이 무결하게 지휘하기 위해, PX4-Autopilot은 uORB::Subscription을 상속받은 uORB::SubscriptionInterval이라는 스마트 래퍼(Smart Wrapper) 클래스를 제공한다. 본 절에서는 해당 클래스가 어떻게 델타 타임(Delta Time) 기반의 다운샘플링(Down-sampling)을 선언적으로 보장하는지 그 내부 아키텍처 코드를 심층 탐구한다.

1. 주파수 제한(Rate Limiting)의 아키텍처적 가치와 의의

단순히 모듈 루틴 내부에 usleep()이나 지연 함수를 강제 삽입하는 절차적 방식과 달리, SubscriptionInterval 객체는 데이터 읽기 시점(update()) 자체에서 “객체 지향적인 캡슐화된 자체 타이머 검증“을 수행하여 운영체제 스케줄러(Scheduler)의 불필요한 개입 횟수를 무자비하게 삭감한다.

• 스레드 무효 웨이크업(Wake-up) 방지: poll()이나 OS 이벤트 큐 대기 시, 인터벌 속성(Interval Property)이 해당 구독자의 파일 디스크립터(fd) 환경에 제대로 바인딩되어 있다면, 사전에 설정 지정된 마이크로초(us)가 경과하기 전까지는 발행자 측 카운터가 백 번 늘어나도 커널은 이 백그라운드 구독자 태스크를 일부러 깨우지 않는다.
• 배터리 풋프린트와 CPU 점유율 대폭 감소: 유효하지 않은(인터벌이 미처 지나지 않은) 시점의 불필요한 데이터 폴링 루프를 update 내부 if 문 단 하나로 일찍 탈락(Early return)시켜 프로세서가 저전력 유휴(Idle) 상태에 머물 수 있는 물리적 시간을 극대화한다.

2. 델타 타임(Delta Time) 검증 로직의 핵심 파이프라인

uORB::SubscriptionInterval 내부에서 다형적으로 오버라이딩(Overriding)된 update() 및 updated() 메서드 호출 시 일어나는 핵심 시간차 검증 매커니즘은 다음과 같이 구현 파이프라인을 가진다.

// PX4 펌웨어 SubscriptionInterval 내부 시간 검증 논리 (개념적 재구성)
bool SubscriptionInterval::updated() {
    // 1. 기반 메인 클래스의 버퍼 데이터 도달 여부 1차 확인 (속도 제한과 무관)
    if (!Subscription::updated()) {
        return false; // 새 데이터가 아예 없으면 볼 것도 없이 false
    }
    
    // 2. 인터벌(Interval) 제한 설정 활성화 여부 확인
    if (_interval_us > 0) {
        // 3. 현재 시스템 하드웨어 절대 타임스탬프 획득 (NuttX hrT)
        // (hrt_absolute_time은 드론 구동 후 마이크로초 단위 누적 시간)
        const hrt_abstime now = hrt_absolute_time();
        
        // 4. 델타 타임(Delta Time) 수학적 평가
        if (now < (_last_update_time + _interval_us)) {
            // 아직 개발자가 지정한 설정 가능 시간이 경과하지 않았으므로, 
            // 링 버퍼에 쌓여있는 유효 메시지가 명백히 존재함에도 불구하고 의도적으로 false를 뱉어 무시(Skip)한다.
            return false;
        }
    }
    
    // 버퍼 내 신규 데이터도 존재하고, 시간 인터벌 대기선도 무사히 통과했음!
    return true;
}

이 알고리즘은 내부 멤버 타임스탬프 변수인 _last_update_time에 마지막으로 데이터를 수신(Fetch)했던 시점의 hrt_absolute_time() (고해상도 시스템 타이머) 스냅샷을 영구 보관해두고, 다음번 update 검증 요청이 스레드로부터 진입할 때마다 (현재 호출 시간) - (이전 갱신 완료 시간) 간의 델타 타임 폭이 미리 설정된 임계치 _interval_us를 초과했는지를 강력한 방어막(Guard)으로 삼는다.

개발자는 모듈 상단 구조체 선언부에서 uORB::SubscriptionInterval _sensor_sub{ORB_ID(sensor_accel), 20000}; (즉, 20,000us = 50Hz 주파수 제한) 형태로 단 한 번만 선언해 줌으로써, 복잡하고 지저분한 하위 제어 루프의 시간 연산 코드를 일절 삽입할 필요 없이 완벽하게 안전한 다운샘플링 율속(Rate Limiting) 파이프라인을 획득하게 된다.

3. 타임스탬프 오버플로우 방어 (Timestamp Wrap-around Defense)

거대한 64비트 정수 타임스탬프 표기계(hrt_abstime = uint64_t)를 전사적으로 채택하고 있는 PX4-Autopilot 생태계에서 마이크로초(us) 단위의 절대 타이머는 무한 실행 시 결국 오버플로우를 겪을 수학적 확률이 엄존하지만, 64비트의 한계치로 인해 실질적으로 약 584,000년(약 58.4만 년)이라는 아득한 천문학적 시간이 경과해야 단 1회 순환하므로 비행 로직에서는 랩어라운드(Wrap-around) 버그가 원천 배제된다.

만약 메모리 제약이 극심한 하위 소형 보드(32비트 타이머 기반) 컴파일 환경이라 할지라도, (now - _last_update_time) >= _interval_us 와 같이 명시적인 뺄셈을 통해 역전되어 가산된 오버플로우 차이 오차를 ’부호 없는 정수형(Unsigned Integer)’의 바이너리 특성을 교묘히 이용하여 0으로 롤오버(Roll-over) 시 상쇄시키는 시스템 프로그래밍 기법이 내부적으로 깊숙이 정렬되어 있다. 결론적으로 SubscriptionInterval 객체 확장은 실시간 비행 제어 도메인에서 비동기 센서 데이터 채널의 국지적 범람(Flood)을 물리적으로 막아주는 가장 영리하고 우아한 C++ 댐(Dam)으로 기능하여 극한의 효율을 창출한다.