1261.77 행동 제어에서의 지연 허용 한계(Latency Budget)
1. 지연 허용 한계의 정의
지연 허용 한계(latency budget)란 행동 제어 시스템의 특정 처리 경로(processing path)에서 허용되는 최대 지연 시간(maximum allowable latency)을 의미한다. 행동 제어 시스템은 센서 데이터의 취득부터 액추에이터 명령의 출력까지 일련의 처리 단계를 거치며, 각 단계에서 소비되는 시간의 총합이 전체 지연 허용 한계를 초과하지 않아야 시스템의 안전성과 성능이 보장된다(Buttazzo, 2011).
지연 허용 한계는 로봇의 물리적 특성(최대 속도, 질량, 제동 거리), 운용 환경(장애물 밀도, 동적 객체의 속도), 그리고 안전 요구사항(최소 반응 시간, 충돌 회피 여유 시간)로부터 결정된다. 지연 허용 한계를 위반하면, 로봇의 행동이 환경 변화에 적시에 대응하지 못하여 충돌, 임무 실패, 또는 안전 사고를 초래할 수 있다.
2. 종단 간 지연의 구성 요소
행동 제어 시스템의 종단 간 지연(end-to-end latency)은 센서 데이터 취득 시점부터 액추에이터 명령이 물리적 동작으로 전환되는 시점까지의 전체 소요 시간을 의미한다. 종단 간 지연은 다음의 구성 요소로 분해된다.
2.1 센서 지연
센서 지연(sensor latency)은 물리적 현상의 발생 시점부터 센서 데이터가 디지털 형태로 변환되어 호스트 프로세서에 도달하는 시점까지의 시간이다. 센서 지연은 센서의 샘플링 주기(sampling period), 아날로그-디지털 변환(ADC) 시간, 센서 내부 처리 시간, 센서-호스트 간 인터페이스(USB, SPI, Ethernet 등)의 전송 지연으로 구성된다.
대표적인 센서별 지연 범위는 다음과 같다.
| 센서 유형 | 전형적 지연 범위 |
|---|---|
| IMU(관성 측정 장치) | 0.1 ~ 5 ms |
| 2D LiDAR | 10 ~ 100 ms |
| 3D LiDAR | 50 ~ 100 ms |
| 카메라(영상 센서) | 10 ~ 50 ms |
| 초음파 센서 | 20 ~ 100 ms |
| GPS 수신기 | 100 ~ 1000 ms |
2.2 통신 지연
통신 지연(communication latency)은 센서 데이터 또는 행동 명령이 ROS2의 통신 인프라(DDS 미들웨어, Zenoh 프로토콜 등)를 통해 발행자에서 구독자로 전달되는 데 소요되는 시간이다.
통신 지연은 다음의 요소로 구성된다.
- 직렬화 시간(serialization time): 메시지 데이터를 네트워크 전송 가능한 바이트 스트림으로 변환하는 시간이다.
- 네트워크 전달 시간(network transit time): 네트워크 매체를 통해 데이터 패킷이 물리적으로 전달되는 시간이다. 노드 내부 통신(intra-process)에서는 0에 근접하고, 유선 이더넷(Ethernet)에서는 수 마이크로초, 무선 Wi-Fi에서는 수 밀리초 수준이다.
- 역직렬화 시간(deserialization time): 수신된 바이트 스트림을 메시지 데이터 구조로 복원하는 시간이다.
- DDS 프로토콜 오버헤드: 발견(discovery), QoS 협상, 신뢰성 보장(재전송, 응답 확인) 등에 소요되는 시간이다.
ROS2의 컴포넌트(component) 아키텍처를 사용하여 동일 프로세스 내에서 노드를 실행하면, 직렬화·역직렬화가 생략되고 제로 카피(zero-copy) 전송이 가능하여 통신 지연을 현저히 감소시킬 수 있다.
2.3 처리 지연
처리 지연(processing latency)은 수신된 센서 데이터를 기반으로 행동 결정, 경로 계획, 제어 명령 생성 등의 연산을 수행하는 데 소요되는 시간이다. 처리 지연은 알고리즘의 계산 복잡도(computational complexity), 프로세서의 연산 성능, 운영체제의 스케줄링 정책에 의해 결정된다.
행동 제어의 주요 처리 단계별 전형적 소요 시간은 다음과 같다.
| 처리 단계 | 전형적 소요 시간 |
|---|---|
| 센서 데이터 전처리(필터링, 변환) | 0.1 ~ 5 ms |
| 장애물 탐지·분류 | 5 ~ 50 ms |
| 행동 트리 틱(tick) 실행 | 0.01 ~ 1 ms |
| 경로 계획(로컬 플래너) | 5 ~ 50 ms |
| 제어 명령 계산(PID, MPC 등) | 0.1 ~ 10 ms |
2.4 액추에이터 지연
액추에이터 지연(actuator latency)은 제어 명령이 생성된 시점부터 물리적 동작(모터 구동, 관절 회전 등)이 실제로 개시되는 시점까지의 시간이다. 액추에이터 지연은 통신 인터페이스(CAN, EtherCAT, PWM 등)의 전송 시간, 모터 드라이버의 응답 시간, 기계적 관성(mechanical inertia)에 의한 동작 지연으로 구성된다.
2.5 스케줄링 지연
스케줄링 지연(scheduling latency)은 콜백 함수가 실행 준비 상태(ready state)에 진입한 시점부터 실제로 CPU에 의해 실행이 개시되는 시점까지의 대기 시간이다. 이 지연은 운영체제의 스케줄러 정책, CPU 부하, 콜백 우선순위, 인터럽트 처리 등에 의해 결정된다.
범용 Linux 커널에서는 스케줄링 지연이 수십 마이크로초에서 수 밀리초까지 변동할 수 있으며, PREEMPT_RT 패치가 적용된 실시간 Linux 커널에서는 이를 수십 마이크로초 이내로 제한할 수 있다(Cerqueira and Brandenburg, 2013).
3. 지연 허용 한계의 산정
3.1 물리적 제약으로부터의 도출
지연 허용 한계는 로봇의 물리적 특성과 운용 환경으로부터 역산(back-calculation)하여 도출한다.
장애물 회피 행동의 경우, 최소 반응 거리(minimum reaction distance) d_r은 다음과 같이 표현된다.
d_r = v \cdot t_{e2e} + d_b
여기서 v는 로봇의 현재 속도, t_{e2e}는 종단 간 지연, d_b는 제동 거리(braking distance)이다. 로봇과 최근접 장애물 사이의 거리가 d_r 이상이어야 안전한 정지가 가능하므로, 종단 간 지연 t_{e2e}의 상한(upper bound)이 결정된다.
예를 들어, 로봇의 최대 속도가 v = 1.0 m/s이고, 제동 거리가 d_b = 0.3 m이며, 센서의 최소 탐지 범위가 d_{\text{min}} = 0.8 m인 경우, 허용 가능한 종단 간 지연은 다음과 같다.
t_{e2e} \leq \frac{d_{\text{min}} - d_b}{v} = \frac{0.8 - 0.3}{1.0} = 0.5 \text{ s} = 500 \text{ ms}
실제 설계에서는 안전 여유(safety margin)를 포함시켜, 산정된 값의 50~70% 수준을 실 운용 지연 한계로 설정하는 것이 일반적이다.
3.2 지연 예산의 분배
산정된 종단 간 지연 허용 한계를 각 처리 단계에 할당(allocate)하는 과정을 지연 예산 분배(latency budget allocation)라 한다. 분배 시에는 각 단계의 고유한 지연 특성, 최적화 가능성, 그리고 단계 간 의존 관계를 고려하여야 한다.
전형적인 행동 제어 루프의 지연 예산 분배 예시는 다음과 같다.
| 구성 요소 | 할당 비율 | 할당 시간 (500 ms 기준) |
|---|---|---|
| 센서 취득 및 전처리 | 20% | 100 ms |
| 통신(센서→행동 제어) | 10% | 50 ms |
| 행동 결정 및 제어 연산 | 30% | 150 ms |
| 통신(행동 제어→액추에이터) | 10% | 50 ms |
| 액추에이터 응답 | 15% | 75 ms |
| 안전 여유 | 15% | 75 ms |
위 분배는 참고적 예시이며, 실제 시스템에서는 각 구성 요소의 실측 지연 데이터를 기반으로 조정하여야 한다.
4. DDS QoS를 활용한 지연 관리
ROS2의 기반 미들웨어인 DDS는 지연 관리를 위한 QoS(Quality of Service) 정책을 제공한다.
Deadline QoS: 토픽의 메시지가 지정된 기한(deadline) 내에 도착하지 않으면, 발행자와 구독자 양측에서 deadline_missed 이벤트가 발생한다. 행동 제어 시스템에서는 센서 데이터 토픽에 deadline QoS를 설정하여, 센서 데이터의 적시 도착 여부를 감시할 수 있다.
Latency Budget QoS: DDS 표준에 정의된 latency_budget QoS 정책은, 메시지가 발행 시점으로부터 구독자에게 전달되기까지 허용되는 최대 지연 시간을 명시한다. DDS 구현체는 이 힌트(hint)를 기반으로 전송 최적화(예: 배칭(batching), 우선순위 조정 등)를 수행할 수 있다.
Lifespan QoS: 메시지의 유효 수명(lifespan)을 설정하여, 지정된 시간을 초과한 메시지를 자동으로 폐기한다. 이를 통해 행동 제어 시스템이 시효 만료된(stale) 센서 데이터에 기반하여 잘못된 행동을 결정하는 것을 방지한다.
5. 지연 측정과 모니터링
5.1 측정 기법
행동 제어 시스템의 실제 지연을 정밀하게 측정하기 위해 다음의 기법을 활용한다.
ros2_tracing: LTTng 기반의 ROS2 전용 추적 도구인 ros2_tracing(Bédard et al., 2022)을 사용하여, 콜백 실행 시간, 메시지 발행-수신 간 지연, 실행자 스케줄링 지연 등을 나노초 해상도로 측정한다. ros2_tracing은 침습성(intrusiveness)이 극히 낮아 실시간 시스템에서도 적용 가능하다.
타임스탬프 내장 측정: 메시지의 헤더(header)에 포함된 타임스탬프(builtin_interfaces/Time)를 활용하여, 메시지 발행 시점과 수신 시점 간의 차이를 계산한다. 이 방법은 시스템 간 시간 동기화(time synchronization)의 정확도에 의존하므로, PTP(Precision Time Protocol) 또는 NTP(Network Time Protocol) 기반의 시간 동기화가 선행되어야 한다.
전용 지연 측정 노드: 행동 제어 파이프라인의 시작과 종료 지점에 지연 측정 전용 노드를 삽입하여, 종단 간 지연을 직접 측정하고 통계(평균, 표준 편차, 최대값, 백분위수)를 산출한다.
5.2 실시간 모니터링
ROS2의 ros2 topic hz 명령으로 메시지 발행 주기를 모니터링하여 기대 주기와의 편차를 감시한다. 주기의 편차가 지연 예산을 침식하는 수준으로 증가하면, 경보(alarm)를 발생시키거나 행동 제어 루프의 주기를 동적으로 조정하는 적응적 주기 관리(adaptive rate control)를 수행한다.
6. 지연 최적화 전략
지연 허용 한계를 충족하기 위한 최적화 전략은 다음과 같다.
- 컴포넌트 노드 활용: 관련 행동 제어 노드를 동일 프로세스 내의 컴포넌트로 구성하여 프로세스 간 통신 오버헤드를 제거한다.
- 콜백 그룹 최적화: 지연 민감 콜백을 상호 배타적 콜백 그룹(mutually exclusive callback group)에 할당하고, 멀티스레드 실행자에서 우선 실행되도록 구성한다.
- PREEMPT_RT 커널 적용: 실시간 Linux 커널을 적용하여 스케줄링 지연의 상한을 보장한다.
- 연산 오프로딩: 지연 허용적(latency-tolerant) 연산을 별도의 비동기 스레드나 에지 서버로 오프로딩하여, 메인 행동 제어 루프의 실행 시간을 단축한다.
- 메시지 크기 최소화: 불필요한 필드를 제거하고, 압축 가능한 데이터(예: 포인트 클라우드)를 사전 처리하여 직렬화·역직렬화 시간과 네트워크 전송 시간을 감소시킨다.
참고 문헌
- Bédard, C., Lütkebohle, I., & Dagenais, M. (2022). “ros2_tracing: Multipurpose Low-Overhead Framework for Real-Time Tracing of ROS 2.” IEEE Robotics and Automation Letters, 7(3), 6511–6518.
- Buttazzo, G. C. (2011). Hard Real-Time Computing Systems: Predictable Scheduling Algorithms and Applications. 3rd ed., Springer.
- Cerqueira, F. & Brandenburg, B. B. (2013). “A Comparison of Scheduling Latency in Linux, PREEMPT_RT, and LITMUS^RT.” Proceedings of the 9th Annual Workshop on Operating Systems Platforms for Embedded Real-Time Applications (OSPERT ’13), 19–29.
- Macenski, S., Foote, T., Gerkey, B., Lalancette, C., & Woodall, W. (2022). “Robot Operating System 2: Design, Architecture, and Uses in the Wild.” Science Robotics, 7(66), eabm6074.
v0.2.0