13.5.1.3. 텔레메트리 대역폭 한계 도달 시 패킷 드롭(Packet Drop) 방지를 위한 `MAV_BROADCAST` 라우팅 테이블 파라미터 및 직렬 포트 보드레이트(Baudrate) 최적화

QGroundControl(QGC) 백엔드가 아무리 RTCM 데이터를 잘 쪼개어( $180 \text{ bytes}$ ) 큐잉(Queueing)하더라도, 물리적인 텔레메트리(Telemetry) 라디오 모뎀(예: $433\text{MHz} / 915\text{MHz}$ 통신 모듈)의 대역폭 한계에 부딪히면 패킷 드롭(Packet Drop) 현상이 구조적으로 발생하게 된다. 즉, 하늘의 PX4 비행 제어기(FC)에 수신되는 데이터보다 지상에서 쏘아 올리는 데이터가 훨씬 많아 직렬 포트의 버퍼링(Buffering)이 초과되어 패킷의 ’증발’이 시작되는 것이다.

본 절에서는 MAVLink의 전방위 멀티캐스트 네트워크 상에서 RTCM 패킷 드롭을 방지하기 위해 사용자가 반드시 숙지해야 하는 PX4-Autopilot의 핵심 라우팅 파라미터인 MAV_BROADCAST 와 통신 속도를 결정하는 보드레이트(Baudrate, SER_TEL1_BAUD) 네트워크 최적화(Optimization) 공학 기법을 분석한다.

1. 텔레메트리 대역폭의 수학적 포화(Saturation) 연산

일반적인 SiK Radio 계열 텔레메트리 모뎀의 기본 보드레이트는 $57600\text{ bps}$ (bits per second) 이다.
직렬 통신(UART)의 특성 상 $1\text{ Byte}$ (8비트)를 전송하기 위해서는 시작 비트(Start bit)와 썸/스톱 비트(Stop bit) 등 패딩 오버헤드가 발생하여 실질적으로 약 10비트( $10\text{ bits}$ )의 통로를 차지한다.

$\text{최대 전송량} = \frac{57,600 \text{ bps}}{10 \text{ bits/byte}} = 5,760 \text{ Bytes/sec}$

여기에 양방향 통신 손실과 시분할 다중화(TDD) 오버헤드, 기타 필수 MAVLink 데이터(Attitude, Position, RC Input) 비율 $40 \sim 50\text{\%}$ 를 제외하고 나면, 지상에서 드론으로 쏘아 올릴 수 있는(Uplink) 순수 유효 RTCM 대역폭은 초당 $1.5\text{ KB} \sim 2.5\text{ KB}$ 언저리로 극도로 협소해진다.

만약 Base 안테나가 GPS+GLONASS+Galileo+BeiDou 4대 위성군의 온갖 부가 정보(MSM7 등)를 모두 활성화하여 초당 $3 \sim 4\text{ KB}$ 짜리 RTCM 메시지를 발생시킨다면, 무선 모뎀의 송신 버퍼(Tx Buffer)는 순식간에 차오르고(Overflow) 파편화된 MAVLink GPS_RTCM_DATA 조각들 중 몇몇 패킷이 허공으로 유실(Lost)된다.
패킷 유실 시의 결과: 단 하나의 바이트라도 유실되면 u-blox 칩셋의 C++ 파서(Parser) 구문(Framing)이 깨져버리고, 해당 초의 RTK $1\text{Hz}$ 보정이 아예 취소되어버리는 재앙(RTK Float 강등)이 초래된다.

1.1 최적화 기법: 보드레이트(Baudrate) 상향

이를 해결하는 물리 계층의 가장 원초적이고 확실한 해법은 직렬 포트 보드레이트를 끌어올리는 것이다.
텔레메트리 하드웨어(예: RFD900, Microhard pDDL)가 지원하는 한도 내에서 최대한 높은 대역폭으로 PX4 파라미터를 변경한다.

SER_TEL1_BAUD (혹은 사용 중인 텔레메트리 포트 맵): $115200$ 이상 권장.
부작용: RF 보드레이트( $\text{Air Rate}$ )를 높이면 무선 통신의 수신 감도(Sensitivity)가 떨어져 절대적인 통신 도달 반경(Range)이 감소한다. (Trade-off: 전송량 증가 vs 비행 거리 손실)

2. 드론 편대 비행(Swarm)에서의 라우팅: `MAV_BROADCAST` 파라미터

여러 대의 드론(Rover)이 하늘에 떠 있고 지상관제소(GCS)는 단 한 대뿐인 상황(Multi-vehicle or Swarm)을 가정해 보자.
QGC가 생성한 GPS_RTCM_DATA (메시지 ID 233) 패킷은 특정 드론 한 대만을 지목하는 타겟 시스템 ID(Target System ID) 방식이 아니라, “내 주파수를 듣고 있는 시스템은 모두 받아라” 라는 의미의 전방위 브로드캐스팅(Broadcasting) 모티브로 뿌려진다.

어떤 한 드론( $\text{System ID } 1$ )이 텔레메트리 포트 1(TELEM1)로 패킷을 받았을 때, “나는 받았으니 나랑 통신망에 엮인 내 친구(예: 징검다리 WiFi에 묶인 $\text{System ID } 2$ 나 호환 주변장치)에게도 이 엄청난 데이터들을 다시 릴레이(Relay)해 주어야 하나?” 라는 네트워크 포워딩 정책의 기로에 놓인다.

2.1 포워딩/라우팅 폭주로 인한 MAVLink 병목 (Broadcast Storm)

만약 드론의 펌웨어가 이 $180\text{ bytes}$ 짜리 무거운 RTCM 데이터를 자기 CPU 안에 있는 모든 시리얼 포트(UART2, UART3, USB, WiFi 등)로 무작위 복사 변조하여 중계(Routing)해 버린다면, 드론 내부와 외부 통신망 전체가 쓰레기 데이터로 포화되는 ’멀티캐스트 태풍(Broadcast Storm)’이 일어난다.

2.2 `MAV_BROADCAST` 제어 구조

PX4는 이러한 네트워크 과부하를 억제하기 위해 MAV_BROADCAST 파라미터를 제공한다.

이 파라미터는 비트마스크(Bitmask)로 작동하며, “수신된 MAVLink 메시지를 다른 포트로 넘겨줄 것인가(Forwarding) 마감할 것인가?“를 정의하는 커스텀 라우팅 테이블(Routing Table) 역할을 수행한다.

0 (Disable): 라우팅 금지.
Bit 0 (1 ): 외부에서 들어온 텔레메트리 신호를 또 다른 텔레메트리 포트로 포워딩 허용.
만일 드론이 단독 운용(Single Vehicle)이라면 이 값은 $0$ 에 가까운 구조로 유지되거나, 최소한 외부 텔레메트리 릴레이 체인(Relay chain)으로 무거운 GPS_RTCM_DATA 가 반사(Reflection)되지 않도록 막아야 한다.

// src/modules/mavlink/mavlink_receiver.cpp (메시지 포워딩 유사 검증 로직)
if (msg->msgid == MAVLINK_MSG_ID_GPS_RTCM_DATA) {
    // 1. 자신의 uORB 모자에 주입 (내부 로컬 소비)
    _gps_inject_data_pub.publish(inject_data);

    // 2. 다른 포트들로 중계/재전송(Broadcast) 할 것인지 여부 판별 (MAV_BROADCAST 참조)
    if (_mavlink->forwarding_enabled() && needs_routing) {
        // 이 무거운 송신 트리거가 켜져 있으면 대역폭이 순식간에 거덜 난다.
        forward_message_to_all_other_links(msg);
    }
}

결론적으로 PX4의 RTCM 텔레메트리 파이프라인 설계는 단순 송수신 단계를 초월한 고도의 무선 네트워크 엔지니어링이다. 만약 드론의 RTK Fix가 수시로 떨리거나(Float $\rightarrow$ Fix $\rightarrow$ Float) MAVLink 연결 자체가 끊어진다면(Connection Lost), 소프트웨어 엔지니어는 가장 먼저 $57600\text{ bps}$ 가 토해내는 시리얼 보드레이트(SER_TEL1_BAUD) 대역폭(Bandwidth) 연산 공식을 점검하고 MAV_BROADCAST 릴레이 파라미터를 차단하여 통로 속의 산소 결핍(Packet Drop) 현상부터 지혈하는 것이 프로페셔널한 ト러블슈팅(Troubleshooting)의 절대적 기준이라 평가할 수 있다.

13.5.1.3. 텔레메트리 대역폭 한계 도달 시 패킷 드롭(Packet Drop) 방지를 위한 MAV_BROADCAST 라우팅 테이블 파라미터 및 직렬 포트 보드레이트(Baudrate) 최적화