19.8.2.1. 시스템 전체 Topic 별 발행/수신 빈도(Hz) 및 데이터 크기 모니터링

19.8.2.1. 시스템 전체 Topic 별 발행/수신 빈도(Hz) 및 데이터 크기 모니터링

NSH 콘솔에서 uorb top을 타격하여 화면을 가득 채운 동적 매트릭스를 처음 마주하게 되면 눈이 팽핑 돌 수 있다. 수십 개의 토픽들이 초록색, 흰색 텍스트로 뒤섞여 실시간으로 요동치고 있기 때문이다.
하지만 우리는 침착하게 이 매트릭스의 좌측부터 중앙열에 포진한 기초 체력(Health) 지표들부터 심문해 들어가야 한다.

update: 1s, num topics: 112
TOPIC NAME                    INST #SUB RATE #VAL SIZE
sensor_accel                     0    6 1000    6   40
sensor_gyro                      0    6 1000    6   36
sensor_mag                       0    3   50    3   40
vehicle_local_position           0   12  100   12  124
sensor_test_data                 0    1  100    1   16
...

위의 텍스트가 의미하는 거시적 생태계의 민낯을 철저히 해부해 보자.

1. INST (다중 인스턴스 생존자 수)

  • INST 열에 0이라고 적혀있다면, 해당 이름표(Topic) 아래에 파이프라인이 오직 단 1방(0번)만 개통되어 있다는 뜻이다.
  • 만약 sensor_accel 토픽의 이 열에 2라고 적혀있다면? 당신 기체 안에는 이미 0, 1, 2 총 3대의 물리적인 가속도 센서 보드가 살아 숨 쉬며 파이프라인 3개를 맹렬히 굴리고 있다는 뜻이다. 시스템에 하드웨어를 꽂았는데 이 숫자가 늘어나지 않는다면 버스(I2C/SPI) 연결이 타버렸음을 직감해야 한다.

2. #SUB (종속성 거미줄 파악)

  • **#SUB**열은 해당 토픽 방에 입을 벌리고 기다리는 **‘구독자(Subscriber) 데몬의 총 머릿수’**이다.
  • 예를 들어 vehicle_local_position이 12라고 기록되었다면, 당신의 비행 제어기 안에 있는 비행 모드 컨트롤러, 로거, 미션 매니저 등 무려 12개의 핵심 모듈이 이 항법 데이터 하나에 목숨을 걸고 매달려 있다는 무시무시한 뜻이다.
  • 반대로 내가 야심 차게 띄운 sensor_test_data의 #SUB가 영원히 0이라면? 내 퍼블리셔 코드는 완벽하지만, 정작 이 데이터를 씹어먹어야 할 내 반대편 구독자 데몬 코드가 부팅조차 실패했거나 orb_subscribe 라인에 치명적인 오타(ORB_ID 착각)를 냈다는 결정적인 스모킹 건(Smoking gun)이 된다.

3. RATE (시스템 심장 박동수 점검)

  • **RATE**는 이 화면에서 가장 중요한 **실질 퍼블리싱 주파수(Hz)**이다.
  • sensor_accel의 RATE가 1000을 찍고 있다면 1초에 구조체가 1000번씩 오차 없이 찍히고 있다는 뜻이다. 만약 내 구독자 모듈이 이 1000Hz를 따라가지 못하고 락업이 걸리면 시스템 전체의 스케줄러가 터져 나가기 시작한다.
  • 개발 과정에서 타이머 버그를 냈다면, 내가 10Hz로 돌라고 명령한 커스텀 토픽의 RATE 열이 갑자기 24000 따위의 폭주하는 속도를 내며 시스템 CPU를 100%로 질식시키는 광경을 심심찮게 목격하게 될 것이다. 이 열을 보면 범인 색출은 1초면 족하다.

4. SIZE (메모리 대역폭 점유율)

  • **SIZE**는 C++ 구조체(struct)가 링 버퍼 한 칸을 차지하는 절대적인 바이트(Byte) 크기이다.
  • sensor_accel이 40 바이트이고 RATE가 1000이라면, 이 토픽 단 하나가 1초에 40,000 Byte (약 40KB)의 램 대역폭을 갉아먹고 있다는 뜻이다.
  • 초퍼보 개발자가 무턱대고 구조체 안에 double [100] 따위의 거대한 쓸데없는 배열을 선언하면 이 SIZE 열이 기하급수적으로 팽창한다. 마이크로컨트롤러(MCU)의 좁은 RAM 환경에서 이런 무식한 SIZE를 가진 토픽이 #SUB 10개를 거느리고 100Hz로 돌게 되면? uorb top 화면이 뜨기도 전에 EKF 스레드나 Logger 스레드의 펌프질이 멈추고 기체는 그 즉시 땅으로 곤두박질칠 것이다.

이 4가지 기초 열(INST, #SUB, RATE, SIZE)을 스캐닝하는 것만으로도, 드론 마더보드 위에서 데이터 트래픽이 어떤 비율로 흐르고 있으며, 내 모듈이 이 거대한 교통망 안에서 얼만큼의 차선을 점유하고 있는지를 시각적으로 지배할 수 있게 된다.
그러나 진정한 악몽은 이 표의 가장 우측, 피비린내 나는 LOSS 열에 숨어있으며, 다음 19.8.2.2 단원에서 이 은폐된 병목 현상을 어떻게 칼날처럼 째고 들어가는지 파헤칠 것이다.