13.2.1.2.2. DroneCAN (UAVCAN v1/v0) 기반 RTK 노드: STM32 마이크로컨트롤러 내장 CAN 트랜시버 버스 토폴로지 및 DSDL 매핑

현대 PX4-Autopilot 아키텍처 환경에서, 고가의 엔터프라이즈 멀티로터나 VTOL 기체들은 더 이상 구형 UART 방식을 통해 RTK GPS를 연결하지 않는다. 여러 개의 I2C 지자기 센서 노이즈와 배선 복잡도, 그리고 그라운드 바운스(Ground Bounce) 문제를 해결하기 위해, 항공우주 산업의 표준으로 자리 잡은 CAN(Controller Area Network) 버스, 그중에서도 드론에 특화된 응용 계층 프로토콜인 DroneCAN(구 UAVCAN v0/v1) 매핑 구조가 전면적으로 도입되고 있다.

본 절에서는 단순한 NMEA 파싱을 넘어, u-blox F9P와 같은 고성능 수신기가 STM32 마이크로컨트롤러(MCU)를 거쳐 어떻게 PX4의 CAN 버스 인터페이스 노드로 기능하는지, 그 하드웨어적 토폴로지와 소프트웨어 데이터 구조(DSDL)를 심도 있게 분석한다.

1. CAN 트랜시버를 포함한 능동형(Active) 노드 하드웨어 토폴로지

기존의 일반 UART GPS 모듈이 ’수동적인 덤프(Dump) 출력 장치’에 불과했다면, DroneCAN 기반 RTK 모듈(예: Holybro DroneCAN H-RTK F9P 등)은 그 자체로 마이크로 RTOS(일반적으로 ChibiOS 또는 Zephyr)가 구동되는 작은 내장형 컴퓨터 노드(Node)이다.

1.1 하드웨어 추상화 토폴로지

내부 회로 기판을 살펴보면, ZED-F9P 칩셋은 외부 커넥터와 직결되는 대신 중간 매개자인 STM32 MCU에 병렬로 연결되어 있다.

graph LR
    A[우주 위성 신호] --> B[ZED-F9P \n RTK Engine]
    B <-->|UART/I2C (보드 내부)| C[STM32 MCU \n DroneCAN 노드 펌웨어 구동]
    C -->|디지털 CAN_Tx / Rx| D[CAN Transceiver \n TJA1051 등]
    D <-->|차동 신호 (CAN_H, CAN_L)| E((CAN Bus Network \n 데이지 체인))
    E <--> F[Pixhawk FC \n CAN 1/2 포트]
    
    subgraph "DroneCAN RTK GPS Module"
    B
    C
    D
    end

1.2 차동 신호(Differential Signaling)와 버스 저항

CAN 트랜시버(Transceiver) 칩셋은 MCU에서 넘어온 0과 1의 비트를 CAN_H와 CAN_L 이라는 두 가닥의 물리적 전압 차이로 변환하여 송출한다.

신호 무결성 방어: 멀티로터의 브러시리스 모터 전선과 CAN 배선이 나란히 묶여있어 노이즈 파동(EMI)이 선에 들어오더라도, 두 선의 전압이 동시에 같은 폭으로 출렁이게 된다. 차동 회로망은 두 선의 전압 ’차이(Difference)’만 판별하므로 외부 노이즈가 기적처럼 상쇄(Common-Mode Rejection)된다.
120옴 종단 저항(Terminal Resistor): 버스의 양 끝단 노드에 무조건 $120\text{ }\Omega$ 임피던스 저항을 병렬로 연결해야 한다. 신호가 케이블 끝에 부딪혀 반사(Signal Reflection)되는 에코(Echo)를 열로 흡수하기 위한 필수 하드웨어 맵핑 요건이다.

2. DroneCAN DSDL (Data Structure Description Language) 매핑

하드웨어적으로 CAN 뼈대가 잘 구축되었다 해도, PX4 uavcan 데몬(Daemon)이 이를 어떻게 센서 데이터로 인식하는지는 온전히 컴파일된 매핑 규격, 즉 DSDL 정의에 달려 있다.

DSDL은 통신에 사용할 메시지 구조체( $x, y, z$ 좌표나 위성 Fix 상태 등)를 텍스트로 정의해 놓은 파일군이며, 이 파일들은 빌드 타임에 C++ 헤더 패킷으로 파싱된다.

2.1 GPS Fix와 RTCM 스트림의 패킷 분할 규칙

CAN 2.0B 프레임은 한 번에 최대 8 바이트의 아주 작은 페이로드(Payload)만을 실어 나를 수 있다(CAN FD 규격 제외). 따라서 수백 바이트 단위인 RTCM 보정 데이터나 거대한 UBX 다중 위성 데이터를 전달하기 위해서는 DSDL 명세에 따른 **다중 프레임 분할 조립(Multi-frame Transfer)**이 강제된다.

uavcan.equipment.gnss.Fix2 (메시지 ID: 1063):
위경도, 고도, 속도 벡터 및 공분산(Covariance) 행렬을 포함하며, $30 \sim 40$ 바이트 규모이다. 이를 송출할 때 모듈의 STM32 노드는 CAN 드라이버 상에서 CRC(순환 중복 검사)를 포함해 데이터를 8 Byte씩 무참히 썰어(Fragmentation) 순차 발송한다.
수신 측 조립: PX4 상의 uavcan 노드 데몬은 버스에서 올라오는 Toggle Bit(분할 패킷의 조각 번호)를 확인하며 메모리 힙(Heap) 영역에서 다시 하나로 합체시킨 후(Defragmentation), 비로소 sensor_gps uORB 토픽으로 배포한다.

2.2 토폴로지 상의 매개 변수 동기화 원리

DroneCAN 시스템이 강력한 이유는 “단순 측위 기기“에서 벗어나 “PX4의 동기화된 서브 시스템“으로 존재하기 때문이다.
RTK 모듈 내부의 STM32 플래시 메모리에는 ZED-F9P를 설정하기 위한 노드 파라미터(Node Parameters)들이 존재한다. PX4나 QGroundControl은 부팅 시 uavcan.protocol.param.GetSet DSDL 메시지를 통해 GPS 돔 상단의 파라미터 트리 구조를 원격으로 덤프(Dump)하거나 수정해버릴 수 있다.
결과적으로, 시스템 운영자는 기판에 USB 케이블을 직접 꼽지 않아도 10m 떨어진 GCS에서 CAN 버스를 거쳐 위성 안테나의 동적 모델(Dynamic Model)이나 텔레메트리 대역폭을 손쉽게 하이잭(Hijack) 조정할 수 있다.

3. PX4 환경 설정 지침

DroneCAN RTK 수신기를 기존 I2C/UART 토폴로지에 삽입하기 전에는 다음의 PX4 파라미터(Parameter) 환경을 반드시 수립해야 한다.

UAVCAN_ENABLE = 2 (Sensors Automatic): PX4의 uavcan 데몬을 활성화하고, 부팅 시 CAN 버스로 주기적으로 신호를 쏘아 버스에 연결된 RTK 노드에게 동적으로 통신 ID를 부여(Dynamic Node ID Allocation)하는 DHCP 성격의 마스터 서비스를 수행하도록 한다.
GPS_1_CONFIG = 0 (비활성): 기존 마더보드 상의 Serial 포트 할당을 강제로 꺼주어야, EKF2 필터가 물리적 UART 인터페이스가 아닌 CAN 버스에서 올라오는 토픽으로 GPS 의존성을 우회(Route)할 수 있다.

요약하자면, DroneCAN 기반 RTK 하드웨어 토폴로지는 단순한 전선 규격 변경이 아니다. 이것은 극한의 비행 노이즈를 견뎌내는 차동 신호 방어선(Differential Defense Line) 위에, STM32 MCU와 PX4 FC가 DSDL 규격으로 실시간 분산 컴퓨팅(Distributed Computing)을 행하는 고신뢰성의 멀티 에이전트 인터커넥트(Interconnect) 기술이다.