19.8.1.2. 특정 인스턴스 지정 및 메시지 발행 속도(Hz) 파악

listener의 기본적인 구조체 덤프 출력 포맷을 완벽히 꿰뚫었다면, 이제 이 도청기(Wiretap)를 더욱 잔혹하게 다루어 **‘다중 인스턴스(Multi-instance) 추적’**과 **‘주파수(Hz) 측정’**이라는 두 가지 고급 엑스레이 스킬을 구사할 차례이다.

단순히 listener sensor_gps라고만 치면, 멍청한 쉘은 기본적으로 0번 주(Main) 방의 데이터만 한 번 물어오고 끝난다. 만약 0번 센서는 물리적으로 고장 났고 기체가 1번 보조 센서로 날아가고 있는 상황이라면, 0번 방만 계속 두들겨봤자 원인을 절대 찾을 수 없다.

1. 다중 인스턴스(Instance) 핀포인트 폭격 (-i)

이때 사용하는 옵션이 바로 인스턴스(Instance) 지정을 뜻하는 -i 파라미터이다. 당신이 1번 예비 GPS 센서 방의 혈압 상태만 단독으로 떼어내 검사하고 싶다면 아래와 같이 타격한다.

px4> listener sensor_gps -i 1

명령이 떨어지자마자, 커널은 sensor_gps 토픽 트리 밑에 숨겨져 있던 1번 서브 파이프라인의 뚜껑만을 뜯어내어 텍스트로 폭파시킨다. 만약 여기서 1번 센서의 timestamp가 수 밀리초 차이 이내로 멀쩡하게 올라오는데 0번 방에서만 seconds ago 지연이 폭주하고 있다면, 당신은 “하드웨어 0번 GPS 보드의 물리적 연결이 끊어졌다“라는 기체 결함 판정을 코딩 한 줄 없이 단 5초 만에 확정 지을 수 있게 된다.

만약 -i 뒤에 아직 VFS에 생성되지도 않은 3이나 4 같은 유령 번호를 집어넣는다면, 잔혹한 커널은 Never published 또는 No instance라는 차가운 에러 메시지를 뿜으며 해당 방이 애초에 존재하지 않음을 실시간으로 일깨워 줄 것이다.

2. 파이프라인 맥박(Heartbeat) 심전도 측정 (-r)

listener 명령어가 제공하는 또 다른 절대 권력은 바로 특정 파이프라인 안의 데이터가 1초에 도대체 몇 번이나 미친 듯이 박동하고 있는지, 즉 실측 발행 주파수(Hz: Rate)를 측정해 내는 -r (Rate) 옵션이다.

px4> listener sensor_accel -r 50

위 명령어의 -r 50은 커널을 향해 물리적인 시간을 걸고 **“지금부터 정확히 50개의 페이로드(Payload)가 이 파이프라인에 떨어질 때까지 쉘 프롬프트를 잠그고 숨죽이고 기다려라. 그리고 50개가 다 모이거든, 그 도착 시간들의 간격을 평균 내어 최종 맥박(Hz)을 도출해 내라!”**라는 무시무시한 스니핑 측정 명령이다.

명령어를 친 후 터미널은 잠시 멈칫하다가, 50번의 메시지가 링 버퍼를 통과하는 순간 아래와 같이 경이로운 통계 보고서를 찍어낸다.

TOPIC: sensor_accel
[통계 생략: 구조체 덤프 블록...]
Rate: 998.4 Hz (1.001 ms)

이 Rate: 998.4 Hz라는 한 줄의 텍스트가 의미하는 바는 엄청나다.
가속도(Accel) 퍼블리셔 데몬이 OS 스케줄러의 악조건 속에서도 타겟 주파수인 1000Hz에 근접하게(약 1밀리초 간격) 데이터를 무결점 펌프질하고 있다는 극강의 런타임 증명이기 때문이다.

만약 당신의 메인 EKF 루프가 400Hz로 돌아야 정상인데, -r 옵션으로 측정해 본 vehicle_local_position 파이프의 주파수가 120Hz밖에 나오지 않고 헐떡거린다면? 그것은 앞단(Frontend)의 IMU나 GPS 센서 버퍼 어딘가에서 치명적인 I/O 락이나 타임아웃 병목이 발생하여 파이프가 막혀있음을 시사한다. 이처럼 -r 옵션은 드론이라는 거대한 데이터 정수장 파이프라인 속에서 어디가 병목점(Bottleneck)인지를 색출하는 가장 확실하고 강력한 마스터 키이다.