13.3.2. 네트워크 RTK (NTRIP) 시스템 연동 및 백엔드 소켓(Socket) 통신 아키텍처

13.3.2. 네트워크 RTK (NTRIP) 시스템 연동 및 백엔드 소켓(Socket) 통신 아키텍처

무인 항공기(UAS)의 고정밀 항법을 위해 로컬 베이스 스테이션(Local Base Station)을 운용하는 것은 오프그리드(Off-grid) 환경에서 필수적이지만, 측량(Survey-in)에 소요되는 긴 시간과 전파 도달 거리(LOS, Line of Sight)의 한계라는 치명적인 단점을 갖는다. 이를 극복하기 위해 현대의 자율 비행 시스템은 국가 또는 민간이 광역에 구축해 놓은 상시 관측소(CORS) 네트워크를 4G/5G 인터넷망을 통해 렌로딩하는 네트워크 RTK (NTRIP, Networked Transport of RTCM via Internet Protocol) 생태계를 적극 활용한다.

본 절에서는 단원 이름이 암시하듯, NTRIP 생태계가 PX4-Autopilot 및 QGroundControl(QGC)과 맞물려 돌아가는 전체적인 소켓(Socket) 통신 아키텍처를 분석하고, QGC 백엔드 클라이언트가 캐스터(Caster) 서버와 어떻게 인증, 요청, 그리고 데이터 스트리밍을 관리하는지 구조적으로 조망한다.

1. NTRIP 기반 네트워크 RTK 시스템 아키텍처 계층

NTRIP 생태계는 본질적으로 월드 와이드 웹(HTTP) 위에서 동작하는 ’데이터 스트리밍 중계 아키텍처’이다. 시스템은 다음 세 가지 주요 컴포넌트로 분리되어 작동한다.

1.1 NTRIP 베이스 (Server) 및 상시 관측소 (CORS)

국토지리정보원이나 민간 통신사(예: SKT, KT) 건물 옥상에 영구적으로 고정된 하이엔드 수신기들이다. 이 장비들은 자신의 3D 위치를 밀리미터 단위로 파악하고 있으며, 초당 1회(1\text{Hz}) 이상 지속적으로 해당 지역의 이온층/대류권 보정 데이터를 포맷팅하여 중앙 서버로 밀어 올린다.

1.2 NTRIP 캐스터 (Caster) - 소켓 중계 허브

스트리밍 인터넷 라디오 서버(Icecast 등)의 구조를 차용한 소프트웨어 스위치이다.

  • 캐스터는 퍼블릭 IP와 포트(주로 TCP 2101 포트)를 열어두고 수만 명의 사용자(드론, 트랙터, 측량기)의 소켓 연결을 대기한다.
  • 다양한 마운트 포인트(Mountpoint, 예: VRS-RTCM31, RTK-GGA 등)를 호스팅하며, 드론이 요청하는 가상 참조국(VRS) 생성을 위해 중앙 서버와 클라이언트 사이의 데이터를 브릿징한다.

1.3 NTRIP 클라이언트 (Client) - QGroundControl 백엔드

PX4 생태계에서 NTRIP 클라이언트 역할은 비행기가 아닌 지상 관제소(QGC) 가 전담한다. QGC를 실행 중인 노트북이나 스마트폰이 LTE/5G 인터넷에 연결되어 있다면, QGC 내부의 C++ 백엔드 스레드가 캐스터 서버로 TCP 소켓을 연결하고 RTCM 데이터를 빨아들인다.

2. QGC 통신망 구조와 MAVLink 브릿징 메커니즘

NTRIP 클라이언트에서 드론 기체(PX4)까지 데이터가 도달하는 과정은 일방적인 파이프라인(Pipeline)이 아닌 쌍방향 스위칭망을 따른다.

2.1 NMEA GGA 패킷의 역전송 (VRS/FKP 통신용)

가상 기준점(VRS, Virtual Reference Station) 아키텍처를 사용할 경우, 중앙 서버는 묻지마 식으로 전국 데이터를 뿌리지 않는다. 캐스터 서버는 “이 클라이언트가 현재 지구 어디에 떠 있는지“를 알아야만 그 위치 주변 하늘의 전리층 오차를 역산하여 맞춤형 보정 데이터를 내려준다.

  1. PX4 기체의 EKF2 필터는 자체 내장 GPS 칩셋이 수신한 부정확한 원시 위치(\pm 3\text{ m} 오차)를 GPS_RAW_INT 메시지 등을 통해 QGC 텔레메트리 링크로 하향 브로드캐스팅한다.
  2. QGC 백엔드는 이 MAVLink 메시지를 낚아채어, 국제 해양 전자 규격인 NMEA의 $GPGGA 문장(Sentence)으로 문자열 변환(Formatting)한다.
  3. 이 GGA 문자열 덩어리를 인터넷 TCP 소켓을 통해 캐스터 서버로 초당 1\text{회} 주기로 역-업로드(Reverse-Upload)한다.

2.2 RTCM 수신 및 MAVLink 인캡슐레이션

NTRIP 캐스터가 GGA 메시지 기반의 생성한 조합 보정 데이터를 내려보내면, QGC의 소켓 수신 버퍼는 순수한 RTCM 바이너리 스트림을 획득하게 된다.

  • 이 지점부터의 처리는 로컬 베이스 스테이션 모드와 완벽히 동일한 체계를 탄다.
  • RTCMMavlink 클래스가 호출되어, 내려받은 인터넷 데이터 스트림을 180\text{ bytes} 크기의 로 쪼개어(Fragmentation), MAVLINK_MSG_ID_GPS_RTCM_DATA 페이로드로 포장한다.
  • 그리고 인터넷망에서 들어온 이 정보는 기기 내부 버스를 타고 900MHz/2.4GHz 무선 텔레메트리 송신기(SiK Radio, Microhard 등)를 거쳐 비행 중인 드론으로 발사된다.

3. 네트워크 RTK의 한계와 실무적 맹점 방어

“인터넷만 터지면 삼각대가 필요 없고 밀리미터 오차로 난다“는 것은 마케팅적 환상이다. 현장에서 시스템 엔지니어가 겪게 되는 네트워크 RTK 아키텍처의 한계와 방어 기술은 다음과 같다.

  1. TCP 통신 지연 (Latency)과 Jitter:
    로컬 베이스는 유선 수준의 직결 통신이지만, NTRIP은 라우팅망을 여러 번 뛰쳐나니므로(Hops) 전송 지연(Delay)이 필수 불가결하다. 캐스터에서 쏜 데이터가 1\text{초} 이상 지연(Age of Differential)되어 드론에 도착하면, 빠르게 날아가는 고정익의 경우 이미 그 공간을 벗어나 있기 때문에 EKF 필터링이 흔들린다.
  2. 데이터 링크 상실 보호 메커니즘 (Data Link Loss Failsafe):
    산악 지대나 철탑 구간을 지날 때 LTE 통신이 3\text{초} 이상 끊기면, QGC 소켓은 Block 상태에 빠지고 RTCM 데이터 공급은 즉각 멎어버린다. PX4의 EKF2 필터는 이런 상황을 대비하여 약 10 \sim 30\text{초} 정도의 ‘데드 레코닝(Dead Reckoning)’ 마진을 가지며, 이후 고정밀 RTK 모드 추정을 포기(Fallback)하고 일반 3D Fix 기반 단독 측위로 퇴보시킨다.
    이러한 다운그레이드 트랜지션을 모니터링하기 위해 GCS 화면에서는 GPS_INFO 의 fix_type 변화 (State: 6(RTK Fixed) -> 5(RTK Float) -> 3(3D Fix))를 반드시 감시해야 한다.

요약하자면, PX4에 NTRIP을 연동한다는 것은 기체, 텔레메트리, GCS(노트북), 그리고 국가 규모의 인프라(LTE 및 Caster 서버)가 하나로 엮이는 거대 시스템 통합(System Integration)의 극한에 부딪히는 일이다. 클라이언트는 이 복잡한 프로토콜 미로 속에서 TCP 소켓의 오류를 극복하며 RTCM 바이너리를 하늘로 안전하게 운송해야 한다.