11.6.1.1 LiDAR 센서의 대역폭 한계(Choking) 극복을 위한 BEST_EFFORT QoS 매핑

ROS2와 Zenoh 클라우드 통합 관제망에서 가장 끔찍하게 시스템의 모가지를 비틀어 쥐는 원흉은 거대한 볼륨(Volume)을 자랑하는 물리 하드웨어 센서들이다. 특히 3D LiDAR(VLP-16 또는 32 채널급 이상) 센서 노드가 내뿜는 PointCloud2 타입의 메시지 스트림은 초당 수천만 개의 3차원 위치 포인트와 강도(Intensity) 바이트 덩어리들을 맹렬하게 쏟아낸다.

시스템 설계자가 기본적인 통신 지식만으로 이 거대한 소나기 트래픽의 스펙트럼(Spectrum)을 RELIABLE (신뢰성 보장) QoS 파라미터로 네트워크망에 태워 보내는 순간, 대역폭 한계점(Choking)을 넘어버린 데이터들이 관(Pipe)을 강제로 찢고 시스템 전반에 치명적 연쇄 지연(Cascading Jitter)을 유발하게 된다. 본 절에서는 대역폭 포화를 파괴하기 위해 BEST_EFFORT 철학 기반의 QoS를 선언하고 강제 매핑하는 엔지니어링 런북을 전개한다.

1. RELIABLE 프로토콜의 맹목적 재전송 병목 지옥

ROS2 코드를 다루는 많은 주니어 엔지니어들은 데이터 유실(Drop)에 대해 병적인 불안감을 느낀다. LiDAR 데이터를 내보내는 퍼블리셔(Publisher)를 선언할 때 거의 관성처럼 통신 품질(QoS) 옵션을 RELIABLE 기반인 디폴트 값으로 방치한다.

RELIABLE (TCP 또는 RTPS Acknowledgment 기반) 스위치가 켜진 상태에서 50MB 용량의 포인트 클라우드가 발포되었다고 치자. 로컬 이더넷 케이블에서는 잘 도달했지만 혼잡한 무선망을 통과하는 순간 3번 채널의 패킷 조각 하나가 대기중에 증발한다.
이 찰나, 수신측(Subscriber)은 조립이 안 되었다고 NACK(수신 불가) 신호를 보내고, 송신측 브릿지는 “어? 못 받았어?” 라며 송신 스레드를 멈춰 세우고 동일한 50MB 페이로드 속에서 유실된 버퍼를 다시 퍼 올려 재전송(Retransmission)하기 위해 CPU 기어를 올린다.

그러나 LiDAR 헤드는 0.1초마다 계속 도는 중이다. 이미 새로운 눈앞의 풍경 50MB 프레임이 또 덮쳐왔는데, 통신 스레드는 아까 유실된 옛 프레임 데이터 한 줌을 살려보겠다고 뒤돌아서서 쓰레기를 줍고 있는 꼴이다. 통신 버퍼 큐는 단 1초 만에 MAX_CAPACITY 에 부딪혀 팽창을 멈추고 시스템은 영구적인 패킷 병목(Choking) 상태에 처박힌다.

2. BEST_EFFORT 토폴로지 패러다임 180도 전환

실시간(Real-time) 센서 데이터를 취급할 때 아키텍트의 마음가짐은 잔혹해져야 한다.
“과거의 픽셀(포인트) 하나가 유실되었다면, 깨끗이 포기(Drop)하고 무조건 지금 갓 생성된 최신 픽셀을 덮어써라.” 이것이 대용량 데이터 전송의 제1 진리다.

LiDAR를 다루는 ROS 퍼블리셔와 브릿지 레이어의 QoS 양측 모두에게, 과거에 대한 재전송(집착)을 프로토콜 단에서 금지시키는 BEST_EFFORT QoS 매핑 지시를 하달해야 한다.

# [자율주행 코어 파이프라인] LiDAR 대응 BEST_EFFORT 억압형 QoS 세팅 런북 (Python 예시)
from rclpy.qos import QoSProfile, ReliabilityPolicy, HistoryPolicy

qos_lidar_profile = QoSProfile(
    reliability=ReliabilityPolicy.BEST_EFFORT, # 절대 재전송 금지, 쏘고 바로 잊는다.
    history=HistoryPolicy.KEEP_LAST,
    depth=1  # 과거 이력 저장 깊이 1 (오로지 제일 최신 프레임 1장만 붙잡는다)
)

self.publisher_ = self.create_publisher(PointCloud2, '/lidar/sparse', qos_lidar_profile)

3. Zenoh 브릿지 파이프에서의 QoS 오버라이드

앱 단 레이어에서 BEST_EFFORT 와 Queue Depth=1 을 조여 놓았음에도, 통계를 보았을 때 지연이 폭발한다면 이는 중간 과정인 zenoh-bridge-dds 가 QoS 매칭 실패를 겪거나, 로컬망에서 넘어온 패킷을 원격지로 쏠 때 여전히 Reliable 방식의 TCP 캐시 터널로 밀어 넣고 있기 때문이다.

이 병목을 척살하기 위해서 브릿지 데몬을 스타트할 때 전용 콘피그 설정파일이나 커맨드라인에서 이 특정 거대 토픽(lidar/*)에 대해 QoS 전송 모드를 강제 오버라이드(Override) 해버려야 한다.

만일 rmw_zenoh_cpp 코어가 적용된 상태라면, Zenoh의 내부 라우팅 설정 룰을 통해 /lidar/** 구역은 Zenoh TCP 레이어 단에서도 송신 보장을 끄거나 타임아웃 억제 모드로 던지라는 파이프라인 우회 명령(UDP 캐러밴)을 매핑해주는 극한 네트워크 옵티마이제이션이 요구될 수 있다.
대역폭의 초과는 엔진의 마력 부족이 아니다. 개발자가 데이터를 유실 없이 들고 가겠다는 무모한 욕심이 빚어낸 거대한 지체 트랜잭션 덩어리임을 자각할 때, 진정한 무중단 초저지연 스트림은 완성된다.