제9부 규격·프로토콜·인터페이스
9.6 오토파일럿 생태계와 미들웨어: PX4·ArduPilot·ROS 2/DDS·FPV 링크·독점 프로토콜
9.6.1 이 장에서 배우는 것 / 선수 지식 / 특히 중요한 독자
2.10는 비행 소프트웨어가 정해진 시각 안에 답을 내야 한다는 조건과 그것을 지키는 내부 구조를 다루었다. 이 장은 그 바깥을 본다. 오픈소스 오토파일럿 두 종류(PX4·ArduPilot)는 구조가 어떻게 다른지, 그 위에서 임무 컴퓨터가 ROS 2와 DDS로 어떻게 연결되는지, 조종 링크(FPV)는 어떤 규약으로 동작하는지, 문서가 없는 독점 프로토콜은 무엇이 위험한지를 원문과 소스로 확인한다. 이 규약은 대부분 합의 표준이 아니라 프로젝트의 문서와 소스 코드이므로(9.1.2), 이 장은 무엇이 문서로 확인되고 무엇이 확인되지 않는지를 함께 적는다.
배우는 것:
- 두 스택의 구조 차이 — PX4의 uORB 발행–구독(갱신에 반응하는 모듈)과 ArduPilot의 스케줄러 태스크 표(Copter 주 루프 기본 400 Hz).
- 라이선스의 상업적 영향 — BSD 3-Clause와 GPLv3, GPLv3 6항의 설치 정보 의무가 보안 부팅 설계와 만나는 지점.
- DDS와 QoS — DDS 1.4의 QoS 정책, ROS 2의 프로파일과 호환성 규칙, RTPS의 순서 가용성, DDS-Security.
- 브리지 — PX4 uXRCE-DDS와 ArduPilot AP_DDS의 구조, QoS 불일치, 토픽 집합과 메시지형의 차이.
- 네 가지 계산 — 브리지 대역폭, 신뢰성 QoS의 정체 시간, 설정값 스트림 주기와 위상 지연, ExpressLRS의 패킷율과 링크 버짓.
- 링크 규약과 독점 프로토콜 — CRSF 사양, ExpressLRS 소스, DJI 사례(NDSS 2023), 사양과 구현이 어긋난 예.
선수 지식: 2.10(비행 소프트웨어 구조)의 발행–구독과 실시간 개념, 9.1(규격의 세계)의 사실상 표준과 합의 표준의 구분, 3.8(링크 버짓과 통달거리 설계)의 감도·거리 관계를 읽었다고 가정한다. 이 장이 맡지 않는 것은 MAVLink 패킷 구조와 서명(9.5), 기체 내부 버스(9.4), 영상 링크(3.12), 시뮬레이션(8.28), 제품 비교(24.27), 군 상호운용성(9.7~9.11)이다.
특히 중요한 독자: 엔지니어는 9.6.3·9.6.6~9.6.10을, 인증·법무 담당자는 9.6.4·9.6.11·9.6.15를, 정책 담당자는 9.6.11·9.6.13을, 사업 담당자는 9.6.4와 9.6.12(스택 선택)를 먼저 읽는다.
기준 시점과 정직성. 2026년 11월 기준이다. 원문을 읽은 것: PX4 v1.17.0(2026-05-13)의 문서(architecture·uORB·uXRCE-DDS·오프보드·ROS 2 사용자 안내·EKF2·멀티콥터 비행 모드)와 소스(dds_topics.yaml, msg 정의 30종(중첩형 포함), commander_params.c, LICENSE). ArduPilot Copter-4.7.2(2026-10-14) 태그의 README·COPYING.txt·AP_Scheduler·Copter.cpp·AP_DDS(config·토픽 표·IDL)와 개발 문서 4쪽. ROS 2 문서 저장소의 Lyrical Luth(2026-05-22) 분기(QoS·미들웨어·보안·릴리스·실시간 문서). OMG DDS 1.4(formal/2015-04-10)의 QoS 표, DDSI-RTPS 2.5(formal/2022-04-01)의 8.4·9.4·10.2, DDS-XRCE 1.0(formal/2020-02-01)의 8.3과 부속서 C.1, DDS-Security 1.2(formal/25-03-06)의 표 49와 10.5. TBS의 CRSF 사양(GitHub main), ExpressLRS 4.1.0(2026-07-17)의 소스와 FAQ, Fast DDS 저장소 master의 기본 시간 상수, Micro-XRCE-DDS-Client v2.4.3, NDSS 2023 논문(Schiller 외, 17쪽). 읽지 못한 것: DDS-XTypes 본문(CDR 정렬 규칙의 정확한 문구), ROS 2 Lyrical이 번들하는 Fast DDS의 판, PX4의 Micro-XRCE-DDS-Client 포크와 에이전트 소스, Semtech SX1280 데이터시트, Crossfire 제품의 내부 사양, DJI·Walksnail·HDZero와 아날로그 FPV의 규격, 사용자 환경의 실측 지연. PX4 v1.18.0-rc1(2026-09-10)은 사전 릴리스여서 문서를 읽지 않았다. 아래 계산의 입력 중 '가정'이라고 적은 것은 설명을 위한 값이며 측정이 아니다. 제조자·프로젝트의 수치는
(공개 주장치), 읽지 못한 것은(확인 필요)로 표시했다. 라이선스 설명은 조문의 요지이며 법률 자문이 아니다.
9.6.2 개념·직관 — 오토파일럿은 제품이 아니라 생태계다
비행 제어 컴퓨터의 소프트웨어는 혼자 동작하지 않는다. 위에는 임무 컴퓨터가 연결되는 미들웨어가 있고, 옆에는 조종기와 지상국 링크가 있으며, 아래에는 센서와 작동기 버스(9.4)가 있다. 이 장은 앞의 셋을 한 생태계로 보고 연결점마다 규약의 상태를 확인한다. 연결점마다 시간 척도가 크게 다르다는 점이 첫 번째 사실이다.
| 층 | 대표 주기 | 근거 |
|---|---|---|
| 비행 스택 내부 | PX4는 대부분의 IMU 드라이버가 1 kHz 표본을 적분해 250 Hz로 발행, ArduPilot Copter는 주 루프 400 Hz | PX4 architecture.md, AP_Scheduler.cpp |
| 브리지(미들웨어) | PX4는 토픽별 발행 상한 기본 100 Hz, AP_DDS는 토픽별 상수(5~1,000 ms) | dds_topics.yaml, AP_DDS_config.h |
| RC 링크 | 패킷 50~1,000 Hz, 원격측정(텔레메트리)은 초당 수 패킷 | ExpressLRS common.cpp |
| 오프보드 생존 신호 | 2 Hz 초과 | PX4 오프보드 문서 |
결론부터: 이 장의 논지는 셋이다. 첫째, 두 스택은 구조가 달라서 같은 ROS 2 인터페이스에서도 메시지형과 QoS가 다르다(9.6.6). 둘째, 미들웨어의 QoS 설정은 제어에 영향을 주는 시간 성질(정체와 데이터 나이)을 정하며, 신뢰성 설정이 항상 안전한 방향은 아니다(9.6.8). 셋째, 이 모든 규약은 합의 표준이 아니라 프로젝트 문서와 소스이고, 독점 링크는 문서조차 없다(9.6.11). 2.10.3.2는 미들웨어(ROS 2·DDS)가 비행 중요 경로에 부적합하다고 표시했는데, 이 장의 계산(9.6.7~9.6.9)이 그 이유를 수치로 보인다.
세 축에서 요구는 다르다. 군용 드론은 이 장의 범위 밖이다. 민간 UAS는 오픈소스 스택과 상용 독점 링크가 시장의 대부분이며 인증 증거보다 연동 편의와 갱신 속도가 먼저다. AAM의 인증 제품은 개발 보증과 형상 동결이 우선이어서(2.10.10.1) 오픈소스는 시제품과 보조 기능에 머무르고, 이 장의 규약은 인증 경로 밖의 인터페이스에 해당한다.
9.6.3 두 오픈소스 스택 — PX4와 ArduPilot
9.6.3.1 PX4 (v1.17.0, 2026-05-13)
PX4 문서는 구조를 두 층으로 설명한다. 추정과 비행 제어를 하는 비행 스택과, 장치 드라이버·외부 통신·uORB를 포함하는 미들웨어이다. 모든 기체형(멀티콥터·고정익·VTOL·로버 등)이 하나의 코드베이스를 공유하고, 모듈이 비동기 메시지로만 통신하는 반응형 설계라고 밝힌다(architecture.md).
uORB는 스레드와 프로세스 사이의 비동기 publish()·subscribe() API이다. 모든 모듈이 하나의 주소 공간에서 공유 메모리로 통신한다(architecture.md). 메시지 버퍼는 기본이 한 개여서 발행이 빠르면 이전 값이 대체되며, 손실이 곤란한 토픽은 2의 거듭제곱 길이의 큐(ORB_QUEUE_LENGTH)를 지정한다(uorb.md). 모든 메시지 정의는 uint64 timestamp를 포함해야 하는데, 로거가 토픽을 기록하는 데 필요하기 때문이다(uorb.md). 모듈은 갱신을 기다려 동작하므로 갱신 주기는 대개 드라이버가 정한다. IMU 드라이버는 1 kHz로 표본화해 적분한 뒤 250 Hz로 발행하고, 내비게이터 같은 모듈은 훨씬 느리게 동작한다(architecture.md).
실행 방식은 둘이다. 모듈이 자기 스택과 우선순위를 가지는 태스크, 또는 공유 스레드를 사용하는 워크 큐 태스크이며, 후자는 협력적이어서 슬립·폴링·블로킹 입출력을 할 수 없다(architecture.md). 실시간 운영체제(RTOS)는 NuttX이다. PX4 문서는 NuttX를 "BSD license"로 적지만 NuttX 저장소 master의 LICENSE는 Apache License 2.0으로 시작한다(9.6.4의 표). 추정기 EKF2는 센서별 지연을 보상하기 위해 지연된 '융합 시간 지평'에서 동작하고, 보완 필터로 현재 시각까지 상태를 전파한다. IMU 입력은 최소 100 Hz가 필요하다(EKF2 안내). 멀티콥터 비행 모드는 수동(Position·Altitude·Stabilized·Acro 등)과 자율(Hold·Return·Mission·Takeoff·Land·Orbit·Follow Me·Offboard)로 나뉘며, Offboard가 외부 컴퓨터의 설정값을 받는 진입점이다(flight_modes_mc).
9.6.3.2 ArduPilot (Copter-4.7.2, 2026-10-14)
ArduPilot 저장소 README는 차량 코드를 Copter·Plane·Rover·Sub·AntennaTracker로 열거하고, 개발 문서는 Blimp를 더해 여섯 종이라고 적는다(두 문서의 목록이 다르다). 구조는 다섯 부분이다. 차량 코드, 차량이 공유하는 라이브러리(센서 드라이버·EKF·PID), 이식을 위한 하드웨어 추상화 계층(AP_HAL), 도구, 외부 코드(ChibiOS RTOS·DroneCAN·MAVLink)이다(개발 문서 Learning ArduPilot — Introduction).
핵심은 AP_Scheduler의 태스크 표이다. 각 항목이 함수, 호출 주기 [Hz], 예상 실행 시간 [µs], 우선순위를 가진다. FAST_TASK는 '빠른 루프(fastloop) 태스크 표'를 만드는 매크로이며 주기를 지정하지 않는다(AP_Scheduler.h). Copter 표는 INS 갱신, 각속도 제어기, 모터 출력, AHRS(EKF), 관성 항법의 순서로 주 루프 안에 두고 rc_loop 250 Hz, throttle_loop 50 Hz 같은 느린 태스크를 따로 둔다(Copter.cpp). 주 루프 기본값은 Copter와 Sub가 400 Hz, 나머지가 50 Hz이며 SCHED_LOOP_RATE는 50~400이고 400 초과는 "highly experimental"이라고 적혀 있다(AP_Scheduler.cpp). 개발 문서의 스레딩 안내는 모든 플랫폼이 1 kHz 타이머 콜백을 제공한다고 설명한다. 이 문서의 일부(PX4 드라이버 shim 설명)는 오래된 구조를 서술하므로 현행 코드와 대조해야 한다. 기본 추정기의 종류(AHRS_EKF_TYPE의 기본값)는 확인하지 못했다 (확인 필요).
9.6.3.3 구조 비교
| 항목 | PX4 | ArduPilot |
|---|---|---|
| 모듈 간 연결 | uORB 발행–구독, 모듈이 갱신에 반응 | 스케줄러가 태스크 표의 함수를 호출하고 라이브러리를 공유 |
| 기본 코어 주기 | IMU 1 kHz 표본, 250 Hz 발행 | Copter 주 루프 400 Hz |
| 메시지 정의 | uORB .msg(ROS 2에는 px4_msgs로 대응) | MAVLink와 ROS 표준 메시지형(AP_DDS) |
| RTOS | NuttX | ChibiOS(STM32 보드) |
| 기체 계열 | 한 코드베이스에서 멀티콥터·고정익·VTOL·로버 | Copter·Plane·Rover·Sub·Blimp·AntennaTracker |
| 라이선스 | BSD 3-Clause | GPLv3 |
| 호스팅 | Dronecode(Linux Foundation) 산하 | ArduPilot 프로젝트(파트너 프로그램) |
아키텍처 일반론과 RTOS·파티셔닝은 2.10가, Pixhawk·Cube 같은 제품 비교는 24.27이 맡는다. 이 장의 관심은 두 스택이 외부와 연결되는 지점이 어떻게 다르게 설계되었는가이다.
9.6.4 라이선스와 상업적 영향 — BSD-3 대 GPLv3
라이선스는 코드가 아니라 제품 구조를 바꾼다. 두 스택의 조건을 원문으로 비교한다.
| 항목 | BSD 3-Clause (PX4) | GPLv3 (ArduPilot, ExpressLRS 4.1.0) |
|---|---|---|
| 재배포 조건 | 저작권 고지와 면책 조항을 유지하고 기여자 이름으로 홍보하지 않는다 | 객체 코드를 전달하면 대응하는 소스를 함께 제공한다 |
| 파생물 | 비공개로 유지할 수 있다 | 같은 GPLv3로 배포해야 한다 |
| 소비자 제품(User Product) | 해당 조항 없음 | 설치 정보(Installation Information)를 제공해야 한다(6항) |
| 비공개 코드와 결합 | 모듈로 통합 가능 | ArduPilot 문서는 임무 컴퓨터에서 비공개 코드를 실행할 수 있다고 안내한다 |
GPLv3 6항의 설치 정보. 소비자 제품(consumer product)은 개인·가족·가사 목적으로 보통 사용되는 유형 동산이며, 의심스러운 경우는 소비자 제품으로 본다고 정의한다. 설치 정보는 수정본을 그 제품에 설치하고 실행하는 데 필요한 방법·절차·인증 키 등이며, 수정했다는 이유만으로 수정본의 계속적 동작이 막히지 않을 정도여야 한다. 제조자도 제3자도 수정본을 설치할 능력을 유지하지 않으면(예: ROM에 설치) 이 의무가 없다. ArduPilot 문서는 이를 제품을 산 고객이 비행 제어기의 펌웨어를 업그레이드하거나 교체할 권리를 가진다는 뜻으로 설명하고, 작동이 보장될 필요는 없고 교체가 가능하기만 하면 된다고 적는다.
보안 부팅과의 충돌. 8.13이 요구하는 서명된 이미지와 보안 부팅은 제조자가 서명 키를 통제하는 설계이다. GPLv3가 적용되는 소비자 제품에서 수령자가 수정본을 설치할 방법이 막히면 6항의 설치 정보 의무와 부딪힐 수 있다. 반대로 BSD 계열에는 이 의무가 없다. 어느 쪽이 적법한지는 제품의 분류와 설계에 달려 있으므로 법무 검토가 필요하다. 이 책은 충돌 가능성을 지적할 뿐 법률 자문이 아니다.
| 구성요소 | 라이선스 | 근거 |
|---|---|---|
| PX4 | BSD 3-Clause | PX4 LICENSE, README |
| ArduPilot | GPLv3 | README, COPYING.txt |
| ExpressLRS 4.1.0 | GPLv3 | LICENSE 파일의 머리글 |
| NuttX | Apache License 2.0으로 시작(PX4 문서는 BSD로 적음) | NuttX 저장소 LICENSE |
| Micro XRCE-DDS Client v2.4.3 | Apache 2.0 | LICENSE 파일의 머리글 |
| Fast DDS (ROS 2 기본 RMW) | Apache 2 | ROS 2 미들웨어 문서, 저장소 LICENSE |
| Cyclone DDS·Zenoh | Eclipse Public License 2.0 | ROS 2 미들웨어 문서 |
| Connext·GurumDDS | 상용 | ROS 2 미들웨어 문서 |
9.6.5 ROS 2와 DDS — 발행·구독과 QoS
9.6.5.1 계층과 지원 기간
ROS 2는 DDS와 그 전송 규약 RTPS 위의 발행–구독으로 시작했고 지금은 Zenoh 같은 비DDS 미들웨어도 지원한다. 미들웨어는 RMW 인터페이스로 교체할 수 있으며 기본은 Fast DDS이다. 문서는 서로 다른 DDS 구현 사이의 통신이 보장되지 않으므로 같은 ROS 판과 같은 RMW를 사용하라고 권고한다. 배포판 사이의 통신도 보장되지 않는다(릴리스 문서). 배포판의 지원 기간은 계산 결과 다음과 같다(9.6-calc.py).
| 배포판 | 출시 | 지원 종료 | 기간 |
|---|---|---|---|
| Humble Hawksbill | 2022-05-23 | 2027-05 | 4.9년 |
| Jazzy Jalisco | 2024-05-23 | 2029-05 | 4.9년 |
| Kilted Kaiju | 2025-05-23 | 2026-12 | 1.5년 |
| Lyrical Luth | 2026-05-22 | 2031-05 | 4.9년 |
REP 2000의 master 사본은 Kilted의 종료를 2026-11로 적어 문서의 표(2026-12)와 다르다. 이 표는 문서의 값이며 월 단위 오차가 있다.
9.6.5.2 QoS 정책
DDS 1.4의 QoS 표(2.2.3, 쪽 92~101)는 정책마다 요청·제공의 호환 규칙(RxO)과 기본값을 정한다. 이 장의 논의에 필요한 정책만 모았다.
| 정책 | 뜻 | DDS 1.4 기본값 | RxO |
|---|---|---|---|
| RELIABILITY | RELIABLE은 누락 표본을 재시도하고 BEST_EFFORT는 재시도하지 않는다 | 발행자 RELIABLE, 구독자·토픽 BEST_EFFORT | 있음 |
| HISTORY | KEEP_LAST는 최근 깊이만 유지, KEEP_ALL은 전부 유지 | KEEP_LAST, 깊이 1 | 없음 |
| DURABILITY | 늦게 참가한 구독자에게 과거 표본을 줄지 정한다 | VOLATILE | 있음 |
| DEADLINE | 갱신 간격의 약속과 기대 | 무한 | 있음 |
| LATENCY_BUDGET | 허용 지연에 대한 힌트이며 감시·강제하지 않는다 | 0 | 있음 |
| LIVELINESS | 발행자의 생존 확인 방식과 임대 기간 | 자동, 무한 | 있음 |
LATENCY_BUDGET이 힌트일 뿐 감시하거나 강제할 필요가 없고 위반을 알릴 필요도 없다는 정의는 중요하다. DDS의 QoS는 지연의 상한을 보장하는 장치가 아니다. 정책 표에서 경성 마감을 보장한다고 정의한 항목은 없다. ROS 2 문서도 실시간 시연은 Linux에서 Connext의 정적 DDS API로 소스 빌드한 경우에만 지원한다고 적는다.
9.6.5.3 ROS 2 프로파일과 호환성
ROS 2의 기본 프로파일은 KEEP_LAST 깊이 10, reliable, volatile이다. 센서 데이터 프로파일은 최신 표본을 제때 받는 것이 모든 표본의 도착보다 중요하다는 이유로 best effort와 작은 큐를 사용한다(ROS 2 QoS 문서). DDS 1.4의 구독자 기본값이 BEST_EFFORT인 것과 달리 ROS 2의 기본 구독은 reliable이다. 연결은 "요청 대 제공" 모형으로 결정된다.
| 정책 | 발행자 | 구독자 | 연결 |
|---|---|---|---|
| 신뢰성 | Best effort | Best effort | 된다 |
| 신뢰성 | Best effort | Reliable | 되지 않는다 |
| 신뢰성 | Reliable | Best effort | 된다 |
| 내구성 | Volatile | Transient local | 되지 않는다 |
호환되지 않으면 둘 사이에 메시지가 전혀 전달되지 않는다(ROS 2 문서). ROS 2는 이를 알리는 '비호환 QoS' 이벤트를 제공한다. PX4는 정확히 이 지점에서 함정을 만든다(9.6.6).
9.6.5.4 보안
DDS-Security 1.2(2026-02 채택)는 위협을 무권한 구독, 무권한 발행, 변조와 재전송, 데이터 무권한 접근의 네 범주로 둔다(7.1.1). 기본 플러그인은 인증이 PKI와 Diffie-Hellman(DDS:Auth:PKI-DH), 접근 제어가 서명된 권한 문서(DDS:Access:Permissions), 암호가 AES-GCM과 AES-GMAC(DDS:Crypto:AES-GCM-GMAC)이다(표 49, 10.1). ROS 2의 보안(SROS 2, 도구는 sros2 패키지)은 이 플러그인을 사용하며 기본이 꺼져 있다. ROS_SECURITY_ENABLE을 켜야 하고, 설정이 잘못된 참가자는 기본값에서 보안 없이 시작하며 ROS_SECURITY_STRATEGY=Enforce일 때만 시작에 실패한다(ROS 2 보안 문서).
보안에는 대역폭 비용이 든다. 부제목 단위 보호에서 수신자별 MAC 없이 정렬 패딩을 무시한 하한으로 계산하면, 표본마다 SEC_PREFIX 24 B, SEC_BODY 8 B, SEC_POSTFIX 24 B로 56 B가 늘어난다(CryptoHeader 20 B와 공통 MAC 16 B는 10.5.2.3·10.5.2.5). 15 B짜리 OffboardControlMode는 RTPS 메시지가 63 B에서 119 B(+88.9 %), 114 B짜리 VehicleOdometry는 162 B에서 218 B로 늘어난다. 한편 XRCE 규격은 직렬·UDP·TCP 전송이 모두 보안을 제공하지 않는다고 적는다(11장, 부속서 C.1). 즉 PX4와 임무 컴퓨터 사이의 직렬 구간은 인증도 암호도 없고, DDS-Security는 에이전트 뒤의 DDS 네트워크에서만 적용된다.
9.6.6 브리지 — PX4 uXRCE-DDS와 ArduPilot AP_DDS
9.6.6.1 PX4 uXRCE-DDS
PX4 v1.14에서 Fast-RTPS 브리지를 대체한 uXRCE-DDS는 비행 제어 컴퓨터의 클라이언트와 임무 컴퓨터(PX4 문서의 companion computer)의 에이전트로 이루어지며 직렬과 UDP만 지원한다. 에이전트는 클라이언트의 대리인으로 전역 DDS 데이터 공간에 발행·구독한다. 클라이언트는 빌드 시 dds_topics.yaml이 열거한 uORB 토픽의 부분집합으로 컴파일되며 이 파일이 uORB와 ROS 2 메시지의 대응을 완전히 정의한다. v1.17.0의 발행 토픽은 27개, 구독 토픽은 38개이다(dds_topics.yaml의 항목 수). 기본 네임스페이스는 /fmu/out/과 /fmu/in/이다. 발행에는 rate_limit을 둘 수 있고 지정하지 않으면 최대 100 Hz이다.
주의할 점이 다섯이다. 첫째, ROS 2 쪽은 클라이언트와 같은 메시지 정의(px4_msgs)로 빌드해야 한다. 둘째, 토픽 집합은 릴리스마다 다르다. 셋째, v1.16부터 메시지 버전(MESSAGE_VERSION)과 번역 노드가 있다. 넷째, PX4의 클라이언트는 Micro XRCE-DDS v2.x 기반이어서 v3.x 에이전트와 호환되지 않으며, ROS 2 작업공간에서 에이전트를 빌드할 때 ROS 2 판별로 맞는 에이전트 판(Humble·Foxy v2.4.2, Jazzy v2.4.3)이 정해져 있다. 다섯째, 발행의 QoS는 TRANSIENT_LOCAL·BEST_EFFORT·KEEP_LAST이므로 ROS 2의 기본 구독(RELIABLE)과 호환되지 않는다. PX4 문서는 구독자가 rmw_qos_profile_sensor_data를 사용해야 한다고 안내한다. 반대로 ROS 2 발행자는 기본 QoS로 PX4에 보낼 수 있다. ROS 2로 외부 비행 모드를 등록하는 PX4 ROS 2 Interface Library(Auterion 저장소)는 PX4 문서가 "Experimental"로 표시한다.
9.6.6.2 ArduPilot AP_DDS
AP_DDS는 같은 Micro XRCE-DDS 클라이언트를 사용하지만 메시지형이 다르다. sensor_msgs/Imu, geometry_msgs/PoseStamped·TwistStamped, sensor_msgs/BatteryState, NavSatFix 같은 표준 ROS 메시지를 IDL로 정의해 사용하고, 서비스(시동, 모드 전환, 이륙, 파라미터)를 제공한다. 발행 주기는 AP_DDS_config.h의 상수이다. IMU 5 ms, 시각 10 ms, 자세·속도 33 ms, RC 100 ms, 배터리 1,000 ms이며 IMU 토픽은 "experimental" 항목이다. QoS는 토픽별로 코드에 고정되어 있다(시각은 RELIABLE 깊이 20, NavSatFix는 BEST_EFFORT 깊이 5, tf_static은 TRANSIENT_LOCAL·RELIABLE 깊이 1).
| 항목 | PX4 uXRCE-DDS | ArduPilot AP_DDS |
|---|---|---|
| 메시지형 | 자체 px4_msgs(uORB 정의와 일대일) | 표준 ROS 메시지형 |
| 토픽 집합 | 빌드 시 dds_topics.yaml | 코드의 토픽 표와 설정 상수 |
| 발행 상한 | 기본 100 Hz, 토픽별 지정 | 토픽별 주기 상수 |
| 발행 QoS | BEST_EFFORT 고정 | 토픽마다 RELIABLE·BEST_EFFORT 혼합 |
| 시험 단계 | ROS 2 Interface Library가 실험적 | IMU 등 실험 항목이 존재 |
같은 ROS 2 코드가 두 스택에서 그대로 동작하지 않는다. 메시지형이 다르기 때문이다. 표준형은 이식성을 주지만 크기가 크다(9.6.7).
9.6.7 워크스루 I — 브리지의 대역폭
결론부터: PX4 브리지의 상시 흐르는 기본 토픽 22개를 상한 주기로 보내면 115,200 baud 직렬선은 6배 넘게 초과하고, 921,600 baud도 76 %가 찬다. 메시지 크기와 주기의 곱이 직렬 속도를 정한다. 계산은 DDS 메시지를 CDR(공통 데이터 표현)로 직렬화한 크기에서 시작한다.
가정. ① 메시지 정의는 PX4 v1.17.0 msg/*.msg이며 중첩 메시지를 펼쳤다. ② CDR은 자연 정렬이고 정렬은 4 B 캡슐화 머리글 뒤에서 시작한다(RTPS 2.5 10.2). 8 B 형을 4 B에 정렬하는 XCDR2 규칙은 DDS-XTypes를 읽지 못해 비교로만 계산했으며 차이는 토픽당 최대 4 B이다. ③ 표본마다 XRCE 메시지 한 개와 직렬 프레임 한 개를 보낸다(배치 없음). 오버헤드는 XRCE 메시지 머리글 4 B(세션 id가 0x80 이상이면 clientKey가 없고 eProsima v2.4.3은 0x81을 사용한다), 부제목 머리글 4 B, 요청·객체 식별자 4 B, 직렬 프레임 7 B로 19 B이며 바이트 이스케이프로 평균 0.78 %가 는다(XRCE 8.3, 부속서 C.1). ④ 직렬은 8N1이어서 바이트당 10비트이다. ⑤ 발행률은 rate_limit, 없으면 100 Hz로 둔 상한이며 실제 발행률과 구독자 유무에 따른 전송 여부는 확인하지 못했다 (확인 필요).
| 토픽 | CDR 본문 [B] | 주기 [Hz] | 선 위 [B/표본] | 선 위 [B/s] |
|---|---|---|---|---|
sensor_combined | 48 | 100(상한) | 67.5 | 6,752 |
vehicle_attitude | 49 | 100(상한) | 68.5 | 6,853 |
vehicle_odometry | 114 | 100(상한) | 134.0 | 13,404 |
vehicle_local_position | 216 | 50 | 236.8 | 11,842 |
vehicle_gps_position(SensorGps) | 163 | 50 | 183.4 | 9,171 |
vehicle_status | 80 | 5 | 99.8 | 499 |
battery_status | 176 | 1 | 196.5 | 197 |
상향 OffboardControlMode | 15 | 20(가정) | 34.3 | 685 |
상향 TrajectorySetpoint | 64 | 50(가정) | 83.6 | 4,182 |
ArduPilot sensor_msgs/Imu | 328 | 200 | 349.7 | 69,942 |
ArduPilot PoseStamped | 80 | 30.3 | 99.8 | 3,023 |
ArduPilot TwistStamped | 72 | 30.3 | 91.7 | 2,779 |
발행 27개 전부를 상한으로 보내면 선 위 103,328 B/s이다. 요청·응답·이벤트 성격의 다섯 토픽을 빼고 22개를 상한으로 보내면 69,869 B/s이며 이용률은 115,200 baud(11,520 B/s)에서 606.5 %, 460,800 baud에서 151.6 %, 921,600 baud(92,160 B/s)에서 75.8 %이다. 오프보드 비행에 필요한 최소 하향 집합(vehicle_odometry·vehicle_attitude 100 Hz, vehicle_local_position 50 Hz, vehicle_status 5 Hz)은 32,598 B/s로 115,200 baud의 283.0 %, 460,800 baud의 70.7 %, 921,600 baud의 35.4 %이다. 상향 4,868 B/s는 115,200 baud의 42.3 %이다. 따라서 115,200 baud는 이 브리지에 맞지 않고, PX4 문서가 예로 든 921,600 baud가 현실적인 하한이다.
세 가지를 읽는다. 첫째, 표준 메시지형은 크다. ArduPilot의 Imu는 표본당 349.7 B로 PX4 sensor_combined(67.5 B)의 5.18배이며 공분산 행렬 세 개(각 72 B)가 대부분이다. 200 Hz로 보내면 이 토픽 하나가 921,600 baud의 75.9 %를 차지한다. 둘째, IMU 기반 토픽이 250 Hz로 발행된다면 상한 100 Hz는 40 %만 전달한다. 나이퀴스트 주파수는 50 Hz이므로 임무 컴퓨터는 그 위의 성분을 볼 수 없다. 각속도 루프 같은 내부 루프를 브리지 바깥으로 옮길 수 없는 이유이다(2.10.2). 셋째, 대역폭은 보안 비용(9.6.5.4)과 합쳐진다.
9.6.8 워크스루 II — 신뢰성 QoS의 재전송 정체
결론부터: 신뢰성(RELIABLE) 설정은 손실을 없애지만 손실이 있는 동안 뒤의 표본을 막는다. 제어에 사용하는 최신 값 스트림에서는 이 정체가 손실 자체보다 해롭다. RTPS 2.5는 한 변경이 응용에 보이려면 더 작은 번호의 변경 중 누락(MISSING)이나 미확인(UNKNOWN)이 없어야 한다고 정한다(8.4.10.4). 누락은 HEARTBEAT를 받아야 알며, 구독 측은 응답 지연 뒤 ACKNACK을 보내고(8.4.12.2 T5), 발행 측은 응답 지연 뒤 재전송한다(8.4.9.2 T11). 요청된 표본이 이력에서 이미 사라졌으면 DATA 대신 GAP이 가고(T12), HEARTBEAT의 firstSN이 그 표본보다 커도 구독 측은 그 표본을 '없음'으로 처리하고 정체를 끝낸다(8.4.12.2 T7).
시간 상수는 구현과 명세가 크게 다르다. 명세 기본값은 nackResponseDelay 200 ms(8.4.7.1)와 heartbeatResponseDelay 500 ms(8.4.10.1)이고 하트비트 주기의 명세 기본값은 없다. Fast DDS 저장소 master(프로젝트 버전 3.6.2.0)의 소스는 하트비트 주기 3 s, nack 응답 5 ms, 하트비트 응답 5 ms이다. ROS 2 Lyrical이 번들하는 판의 값은 확인하지 못했다 (확인 필요).
모형. 표본 손실이 독립이고 확률 $p$이며 스트림 주기 $f$라고 가정한다. 손실 뒤 재전송 표본이 보이기까지의 시간 $R$과 정체 길이 $S$, 정체에 놓인 시간 비율 $u$는 다음과 같다.
$$R = d + t_{hb} + \frac{\mathrm{RTT}}{2} + t_{nack} + \frac{\mathrm{RTT}}{2},\qquad S = \begin{cases}\min\!\left(R,\ \dfrac{N+1}{f}\right) & \text{하트비트가 표본에 편승} \\ R & \text{주기 하트비트만}\end{cases},\qquad u = 1 - e^{-f\,p\,S}$$
| 기호 | 뜻 | 값(가정) |
|---|---|---|
| $d$ | 누락 탐지 지연 | 편승이면 $1/f$, 주기 하트비트만이면 $T_{hb}/2$ |
| $t_{hb}$, $t_{nack}$ | 하트비트 응답 지연, nack 응답 지연 | 구성에 따름 |
| RTT | 링크 왕복 시간 | 2 ms |
| $N$ | KEEP_LAST 깊이 | 10(ROS 2 기본) |
| $f$ | 스트림 주기 | 50 Hz |
세 구성을 비교한다. A는 명세 기본 응답 지연(0.5 s와 0.2 s)에 편승 하트비트, B는 Fast DDS 기본 지연(5 ms와 5 ms)에 편승 하트비트, C는 Fast DDS 기본 지연에 주기 하트비트(3 s)만 있는 경우이다. 허용 나이를 $\tau=100$ ms로 두면 최선 노력(BEST_EFFORT)은 연속 5개가 사라져야 나이가 $\tau$를 넘는다.
| 구성 | $R$ | $S$ ($N=10$) | $p=1\%$ 정체 비율 | $p=1\%$ 나이 100 ms 초과 비율 |
|---|---|---|---|---|
| A 명세 기본 지연 | 722 ms | 220 ms | 10.4 % | 5.82 % |
| B Fast DDS 기본, 편승 | 32 ms | 32 ms | 1.6 % | 0.00 % |
| C Fast DDS 기본, 주기만 | 1,512 ms | 1,512 ms | 53.0 % | 50.64 % |
| 최선 노력 | 해당 없음 | 0 | 0 % | $1.00\times10^{-8}$ % |
읽을 점은 넷이다. 첫째, 같은 reliable이어도 시간 상수에 따라 정체가 1.6 %에서 53 %까지 달라진다. 둘째, 이력 깊이가 정체의 상한을 정한다. 편승 하트비트에서는 표본이 이력에서 삭제되는 $N/f$ 뒤 한 주기 안에 정체가 끝나므로 깊이 10에서 A의 정체는 722 ms가 아니라 220 ms이고 깊이 1이면 40 ms이다. 셋째, 마지막 표본의 손실(뒤에 표본이 없는 경우)은 하트비트가 와야 탐지되므로 주기 하트비트만 있으면 평균 1.5 s, 최대 3.0 s가 걸린다. 이는 이륙 명령 같은 사건성 메시지에 해당한다. 넷째, 최선 노력에서 5개 연속 손실은 $p=1\%$에서 $10^{-10}$이며 $p=5\%$에서도 $3.13\times10^{-5}$ %이다. 이 결과가 ROS 2의 센서 데이터 프로파일과 PX4의 BEST_EFFORT 발행의 근거이다. 한계는 분명하다. 손실이 독립이라는 가정(실제 무선 링크는 군집 손실)과 구현이 하트비트에 편승하는 방식은 측정으로 확인해야 한다 (확인 필요).
9.6.9 워크스루 III — 설정값 스트림의 주기와 위상 지연
결론부터: PX4가 오프보드 모드에 요구하는 2 Hz는 제어 주기가 아니라 생존 신호이다. 설정값을 이 주기로 보내면 교차 주파수 1 Hz의 외부 루프에서 위상이 97.2° 지연된다. PX4 문서는 외부 컨트롤러가 2 Hz 초과의 OffboardControlMode 또는 MAVLink 설정값을 보내야 하며 1초 이상 받은 뒤에 오프보드가 시작되고, 신호가 끊기면 제한 시간(COM_OF_LOSS_T, v1.17.0 기본 1.0 s) 뒤에 페일세이프 동작으로 넘어간다고 적는다(offboard.md, commander_params.c).
영차 유지(ZOH)로 수신한 설정값은 평균 $T/2$ 늦고, 전송·처리 지연 $\tau$가 더해진다. 외부 루프의 교차 주파수 $f_c$에서 위상 지연은 다음이다.
$$\varphi = 360^\circ \, f_c \left(\frac{1}{2 f_{sp}} + \tau\right)$$
| $f_c$ [Hz] | 2 Hz | 10 Hz | 20 Hz | 50 Hz | 100 Hz |
|---|---|---|---|---|---|
| 0.5 | 48.6° | 12.6° | 8.1° | 5.4° | 4.5° |
| 1.0 | 97.2° | 25.2° | 16.2° | 10.8° | 9.0° |
| 2.0 | 194.4° | 50.4° | 32.4° | 21.6° | 18.0° |
가정은 $\tau = 20$ ms와 외부 위치 루프의 $f_c$ 세 값이다. 열은 설정값 주기 $f_{sp}$이다. $f_c = 1$ Hz인 외부 루프에서 2 Hz 스트림은 97.2°를 소모하고 20 Hz는 16.2°, 50 Hz는 10.8°이다. 필요한 위상 여유는 2.2와 2.10.6의 계산과 같은 방식으로 정한다. 제한 시간 1.0 s는 20 Hz 스트림에서 연속 20개 손실에 해당한다. 제한 시간은 손실 허용 폭을, 주기는 위상 지연을 정하는 서로 다른 두 설계 변수이다. 지연된 외부 측정(시각 오도메트리 등)은 EKF2가 센서별 지연 파라미터(EKF2_*_DELAY)로 보상하며, 그러려면 브리지의 시각 동기(UXRCE_DDS_SYNCT, 기본 활성)와 메시지의 timestamp가 정확해야 한다.
9.6.10 FPV·RC 링크 — ExpressLRS와 CRSF
FPV는 두 링크의 합이다. 조종 명령을 보내는 RC 링크와 영상을 받는 영상 링크이다. 영상 링크(아날로그·디지털)의 전송과 지연은 3.12이 다루고, 이 절은 공개 문서가 있는 RC 링크 규약만 본다.
9.6.10.1 CRSF 사양
TBS가 유지하는 공개 사양은 스스로를 "단일 진실 출처"라 부른다. 기체 쪽 이중선 전이중 UART는 416,666 baud 8N1이 기본이고 RC–송신 모듈의 단선 반이중은 400 kbaud이다. 프레임은 최대 64 B, 길이 값의 유효 범위는 2~62, 동기·길이·형·페이로드·CRC 순이며 CRC는 형과 페이로드에 대한 CRC8(다항식 0xD5)이다. 0x16 프레임은 16채널을 11비트로 묶은 22 B 페이로드이고 전체 프레임은 26 B이다. 사양은 페일세이프에서 이 프레임의 송신이 멈추며 비행 제어기가 페일세이프 절차를 시작하기 전에 1초를 기다리기를 권장한다. 0x14 링크 통계는 RSSI(dBm × -1), 링크 품질 %, SNR을 포함한다. 0xAA 봉투는 최대 281 B의 MAVLink2 프레임을 데이터 58 B 이하의 청크로 나누어 보낸다. 사양 파일에는 암호화·인증·서명을 다루는 항목이 없다(해당 낱말을 검색해 확인했다).
| 계산 | 값 |
|---|---|
| 26 B RC 프레임의 직렬 시간(416,666 baud) | 624 µs |
| 이용률(50·250·500·1,000 Hz) | 3.1 %·15.6 %·31.2 %·62.4 % |
| 최대 프레임 64 B | 1,536 µs |
| MAVLink2 281 B의 CRSF 전달 | 청크 5개, 직렬 7.68 ms |
9.6.10.2 ExpressLRS 4.1.0 (2026-07-17, GPLv3)
ExpressLRS는 Semtech SX127x·SX1280 계열의 LoRa 변조를 사용하는 오픈소스 RC 링크이며, README는 900 MHz가 최대 200 Hz, 2.4 GHz가 1,000 Hz까지 가능하다고 소개한다 (공개 주장치). 같은 저장소의 common.cpp에는 900 MHz 250 Hz LoRa와 1,000 Hz FSK 행(LR1121 구간)이 있어 README의 서술과 다르다. 공중 패킷은 8 B(OTA4: 4채널 10비트와 스위치) 또는 13 B(OTA8)이며, CRC의 초깃값은 UID(바인드 문구에서 나온 식별자)·OTA 판 식별자·패킷 nonce로 만든다(OTA.cpp). 이는 오류 검출과 수신기 구분이지 인증이 아니다. FAQ는 바인드 문구가 보안이 아니라 충돌 방지를 위한 주파수 도약 패턴의 시드라고 밝힌다.
소스의 패킷율 표(ExpressLRS_AirRateConfig·ExpressLRS_AirRateRFperf)에서 2.4 GHz LoRa 행을 읽고(소스 상수이므로 (공개 주장치)) 파생값을 계산했다. 점유율은 공중 시간을 패킷 간격으로 나눈 값, 거리비는 500 Hz 대비 감도 차이를 자유공간 손실로 환산한 값이며 가정은 송신 전력·안테나·수신 잡음이 같다는 것이다.
| 율 | 간격 [ms] | 공중 시간 [µs] | 점유율 | 감도 [dBm] | 거리비 | 평균 명령 지연 [ms] | 단절 판정 [ms] |
|---|---|---|---|---|---|---|---|
| 500 Hz | 2.00 | 1,507 | 75.3 % | -105 | 1.00 | 1.00 | 2,500 |
| 333 Hz 8채널 | 3.00 | 2,374 | 79.1 % | -105 | 1.00 | 1.50 | 2,500 |
| 250 Hz | 4.00 | 3,300 | 82.5 % | -108 | 1.41 | 2.00 | 3,000 |
| 150 Hz | 6.67 | 5,871 | 88.1 % | -112 | 2.24 | 3.33 | 3,500 |
| 100 Hz 8채널 | 10.00 | 7,605 | 76.0 % | -112 | 2.24 | 5.00 | 3,500 |
| 50 Hz | 20.00 | 10,798 | 54.0 % | -115 | 3.16 | 10.00 | 4,000 |
읽을 점은 셋이다. 첫째, 패킷율을 500 Hz에서 50 Hz로 낮추면 감도가 10 dB 좋아져(900 MHz 행은 200 Hz에서 25 Hz로 11 dB) 자유공간 통달거리가 3.16배가 되지만 명령 지연은 평균 1 ms에서 10 ms로 늘고 텔레메트리는 초당 3.9개에서 3.1개 수준(비율 1/128과 1/16)에 머문다. 링크 버짓과 통달거리 설계의 방법은 3.8가 다룬다. 둘째, 소스의 공중 시간은 Semtech LoRa 식으로 검증할 수 있다. 900 MHz 행 다섯 개(SX127x, 대역폭 500 kHz)는 식이 표를 ±4 µs 이내로 재현한다(200 Hz 행 4,384 대 4,380 µs). 2.4 GHz 행은 SX1280 데이터시트를 읽지 못해 식 검증을 하지 못했고 표 값을 그대로 사용했다 (확인 필요). 셋째, 단절 판정 시간(2.5~4 s)은 수신기가 링크 단절을 선언하는 기준이며, 기체의 링크 상실 절차는 이와 별개로 3.11과 2.6이 다룬다. 감도는 프로젝트가 기대하는 최소 감도이며 측정·인증 결과가 아니다 (공개 주장치).
9.6.11 독점 프로토콜과 사실상 표준 — 위험과 입증
독점 프로토콜은 문서·구현·시험 방법이 공급자에게만 있는 규약이다. 문서가 있는 오픈 규약과 비교하면 위험이 세 가지로 나뉜다. 문서 부재는 독립 검증을 불가능하게 하고, 폐쇄는 상호운용과 감사를 막으며, 보안 주장의 미검증은 주장이 사실인지 확인할 수단을 없앤다. 가장 상세한 공개 사례가 DJI이다.
NDSS 2023 논문(Schiller 외)은 DJI 드론의 OcuSync와 DroneID에 공개 문서가 없다고 적고, DJI의 보안 백서가 DroneID 전송을 명시하지 않는다고 지적한다(쪽 5). 백서는 업링크와 다운링크가 AES-256으로 암호화된다고 설명한다 (공개 주장치). 논문이 인용한 언론 보도는 DroneID도 암호화되어 있다고 전했고 DJI가 이를 두 번 확인했다고 한다(쪽 5). 그러나 저자들은 펌웨어와 물리 계층의 역공학으로 DroneID가 암호화되어 있지 않고 드론과 조종자의 위치를 노출함을 확인했으며(쪽 1·2), 그 보도는 이 연구 결과를 반영해 정정되었다(쪽 5). 저자들은 16개 취약점을 보고했고 DJI가 모두 수정했다고 한다(쪽 2). 이 결과는 논문 발표(2023-02) 당시의 특정 기종에 대한 것이며 현재 제품의 상태를 말하지 않는다. 읽을 점은 문서가 없으면 외부의 역공학만이 검증 수단이라는 사실이다.
오픈 규약이라고 안전하거나 정확한 것은 아니다. 이 장에서 원문을 대조해 확인한 예는 네 가지이다.
| 사례 | 원문에서 확인한 것 | 의미 |
|---|---|---|
| CRSF | 사양은 공개되어 있으나 인증·암호 항목이 없고 CRC8만 있다 | 문서 공개와 보안은 별개이다 |
| ExpressLRS | 바인드 문구는 보안이 아니라고 FAQ가 밝힌다. 공중 패킷의 CRC는 UID로 초기화 | 오류 검출과 진본 확인은 다르다 |
| XRCE 직렬 CRC | 명세 부속서 C.1.1.6은 $x^{16}+x^{12}+x^5+1$(RFC 1662)이라고 적는데, Micro-XRCE-DDS-Client v2.4.3의 표는 0x8005 다항식(반사형 0xA001)의 표와 앞 8개 항목이 일치하고 0x1021 계열과는 다르다 | 명세와 구현이 어긋날 수 있다(에이전트와 PX4 포크는 읽지 못했다) |
| ROS 2 Kilted | REP 2000 사본의 종료일(2026-11)과 문서 표(2026-12)가 다르다 | 판의 날짜는 출처마다 확인해야 한다 |
오픈소스 오토파일럿과 미들웨어는 인증의 관점에서도 위치가 분명하다. OMB 회람 A-119의 구분(9.1.2)으로는 합의 표준 기구의 절차를 거치지 않은 규약이므로 사실상 표준이고, 인증의 입증 방법으로 인정받으려면 별도의 근거가 필요하다(9.1.5). 오픈소스의 장점은 소스가 공개되어 감사할 수 있다는 점이고, 약점은 판이 프로젝트의 일정으로 바뀐다는 점이다. 계산상 PX4 v1.16.0에서 v1.17.0까지 280일, ExpressLRS 4.0.0에서 4.1.0까지 161일이며 ROS 2 장기 지원은 4.9년이다. 9.1.7의 표본에서 규격의 판 간격은 중앙값 10.0년이었다. 인증 형상은 판을 동결하고(2.10.10.1) 보안 갱신은 별도 절차로 관리해야 한다(8.13).
9.6.12 설계 트레이드오프 — 스택·연결·링크
스택 선택은 세 방식으로 펼친다.
- ① PX4(BSD-3). 장점은 라이선스가 비공개 파생·서명 잠금과 충돌하지 않고, 모듈이 uORB로 분리되어 교체와 로그가 쉽다는 점이다. 단점은 메시지형이 자체 정의여서 ROS 2 표준 도구와 직접 연결되지 않고, 릴리스마다 토픽 집합이 달라진다는 점이다. 누구에게 맞는가: 파생 제품을 비공개로 유지하는 사업자와 모듈 단위 개조를 하는 연구·시제품.
- ② ArduPilot(GPLv3). 장점은 차량 계열이 넓고 표준 ROS 메시지형을 제공하며 소스가 항상 공개되어 있다는 점이다. 단점은 소비자 제품에서 설치 정보 의무가 서명 잠금과 충돌할 수 있고, 비공개 코드를 임무 컴퓨터로 분리해야 한다는 점이다. 누구에게 맞는가: 소스 공개를 받아들이는 제조자, 사용자가 펌웨어를 교체할 권리가 중요한 시장.
- ③ 독점·인증형 비행 제어 컴퓨터(24.27). 장점은 개발 보증과 형상 동결이 계약으로 제공된다는 점이다. 단점은 외부 인터페이스가 공급자 문서에 묶이고 갱신 일정을 통제하지 못한다는 점이다. 누구에게 맞는가: 인증을 받는 AAM과 대형 UAS.
견해: 인증을 받지 않는 제품은 ① 또는 ②에서 라이선스와 서명 정책을 먼저 맞추고, 인증 경로의 기능은 ③ 또는 인증 가능한 코어로 분리한다. 근거는 두 가지이다. 라이선스는 서명·보안 부팅 설계를 직접 제약하므로 제품 구조가 정해진 뒤에는 바꾸는 비용이 크고(9.6.4), 오픈소스의 성숙도는 인증 증거가 아니기 때문이다(2.10.10.1). 이것은 이 책의 견해이다.
미들웨어 연결도 세 방식이 있다. ① uXRCE-DDS·AP_DDS 브리지는 ROS 2 생태계를 그대로 사용하지만 대역폭(9.6.7)과 QoS 불일치(9.6.6)를 설계해야 한다. ② MAVLink 오프보드(9.5)는 좁은 인터페이스로 작지만 표준 ROS 도구가 없다. ③ 자체의 좁은 인터페이스는 DDS를 임무 컴퓨터 안에서만 사용하고 비행 제어 컴퓨터와는 정의한 메시지 집합만 주고받는다(9.4·8.3). 상호운용성은 없지만 인터페이스를 전부 통제하고 시험할 수 있다.
견해: ROS 2·DDS는 비행 중요 경로 밖에서만 사용하고, 발행은 BEST_EFFORT와 센서 데이터 프로파일을 기본으로 한다. 근거는 9.6.8의 계산이다. 신뢰성 설정이 순서 가용성 때문에 최대 53 %(구성 C)의 시간 동안 스트림을 정체시키고, 100 Hz 상한이 내부 루프의 정보를 40 %만 전달하기 때문이다(9.6.7). 사건성 메시지(명령·응답)만 reliable로 두고, 하트비트가 주기뿐인 구현에서는 마지막 표본 손실의 탐지 시간(평균 1.5 s)을 응용 수준 재전송으로 보완한다. 이것은 이 책의 견해이며 구현별 실측이 필요하다.
9.6.13 세 축 비교
| 항목 | 군용 드론 | 민간 UAS | AAM(eVTOL) |
|---|---|---|---|
| 주된 스택 | 이 장의 범위 밖 | PX4·ArduPilot·상용 독점 스택 | 인증 가능한 비행 제어 컴퓨터, 오픈소스는 시제품·보조 기능 |
| 미들웨어 | 이 장의 범위 밖 | ROS 2·uXRCE-DDS·MAVLink | 인증 경로는 좁은 인터페이스(9.4), ROS 2는 임무 쪽 |
| RC·조종 링크 | 이 장의 범위 밖 | CRSF·ELRS 등 문서가 공개된 규약과 독점 링크 | 인증 대상은 C2 링크(3.11)이며 이 장의 RC 규약은 직접 대상이 아니다 |
| 라이선스·공급망 | 이 장의 범위 밖 | GPLv3·BSD 선택이 제품 구조를 정함 | 형상 동결·SBOM이 우선(8.13) |
| 입증 | 이 장의 범위 밖 | 시장·운용 위험 평가에 의존 | 인정된 합의 표준과 개발 보증 |
9.6.14 관련 규격·프로토콜
| 문서 | 발행 | 무엇을 정하나 | 상세 장 |
|---|---|---|---|
| DDS 1.4(formal/2015-04-10) | OMG | QoS 정책·RxO·기본값, 정책 표 쪽 92~101(원문 확인) | 이 장 |
| DDSI-RTPS 2.5(formal/2022-04-01) | OMG | 순서 가용성(8.4.10.4), 응답 지연 기본값, 하트비트 처리, 메시지 구조(원문 확인) | 이 장 |
| DDS-XRCE 1.0(formal/2020-02-01) | OMG | 클라이언트–에이전트 메시지·스트림·직렬 프레임(원문 확인) | 이 장 |
| DDS-Security 1.2(formal/25-03-06) | OMG | 보안 모델과 기본 플러그인, AES-GCM-GMAC 형식(원문 확인) | 이 장, 9.19 |
| DDS-XTypes | OMG | CDR 표현의 정렬 규칙 (미확인) | — |
| ROS 2 문서(Lyrical 분기) | ROS 2 프로젝트 | QoS·RMW·보안·릴리스(원문 확인) | 이 장 |
| REP 2000 | ROS 프로젝트 | 배포판 지원 기간(원문 확인, Lyrical 항목은 사본에 없음) | 이 장 |
| PX4 v1.17.0 문서·소스 | PX4(Dronecode) | uORB·uXRCE-DDS·오프보드·토픽 집합(원문 확인) | 이 장, 2.10 |
| ArduPilot Copter-4.7.2 소스·문서 | ArduPilot 프로젝트 | 스케줄러·AP_DDS·라이선스(원문 확인) | 이 장, 2.10 |
| CRSF 사양 | TBS | 프레임·CRC·채널 패킹·링크 통계(원문 확인) | 이 장 |
| ExpressLRS 4.1.0 소스 | ExpressLRS | 패킷율 표·OTA 패킷·CRC(원문 확인) | 이 장 |
| MAVLink 2 | MAVLink 프로젝트 | 지상국·오프보드 메시지 (이 장에서 미확인) | 9.5 |
| GPLv3, BSD 3-Clause | FSF, 프로젝트 | 라이선스 조건(원문 확인) | 이 장 |
| Semtech SX127x·SX1280 데이터시트 | Semtech | LoRa 공중 시간 식 (미확인, 소스 표로 대조) | — |
전체 지도는 A.6에 있다.
9.6.15 관련 규제·인증 요구와의 연결
- 오픈소스와 인증(2.10.10.1·8.8). 성숙도는 DO-178C의 객체 목표를 대신하지 못한다. 시뮬레이션과 SITL(8.28)은 시험 환경이며 도구 자격 인정의 대상이 될 수 있다.
- 제품 보안(8.13·8.11·8.12). PX4·ArduPilot·ROS 2·Fast DDS는 SBOM의 구성요소이다. DDS-Security와 SROS 2는 CRA 부속서 I의 통신 기밀성·무결성 요구(8.13.4)를 충족하는 수단의 후보이지만 기본이 꺼져 있고 직렬 구간에는 적용되지 않는다.
- 서명과 GPLv3(9.6.4·8.13.9). 서명 키 정책이 소비자 제품의 설치 정보 의무와 만난다.
- 하이재킹과 노획(8.16·8.17). RC 링크에 인증이 없으면 링크 경로가 공격 표면이다. 오픈소스는 코드 노출이 기본이므로 비밀은 코드가 아니라 키에 있어야 한다.
- 링크 상실 절차(3.11·2.6). ELRS의 단절 판정 시간(2.5~4 s)과 오프보드 제한 시간(1.0 s)은 기체의 링크 상실 절차와 별개의 값이다.
- 형상 관리와 비행 기록(8.22·8.23). 판·토픽 정의·파라미터를 동결하고, uORB의 timestamp 규칙이 로그의 기준이 된다.
- 규격 문서 읽기와 적합성(9.23·9.1). 사실상 표준의 판과 구현을 확인하는 절차이다.
- 주파수(17.19·18.16). ELRS의 900 MHz·2.4 GHz 운용은 지역 전파 규정을 따르며 이 장은 읽지 못했다
(확인 필요).
9.6.16 함정과 한계
| 오해 | 실제 | 더 볼 곳 |
|---|---|---|
| ROS 2 구독자는 PX4 토픽을 기본 설정으로 받는다 | PX4 발행은 BEST_EFFORT이고 ROS 2 기본 구독은 RELIABLE이어서 연결되지 않는다. sensor data 프로파일을 지정한다 | 9.6.5.3·9.6.6.1 |
| reliable이면 손실이 없어 안전하다 | 순서 가용성 때문에 손실 동안 뒤 표본이 정체한다. 1 % 손실에서 1.6~53 %(모형) | 9.6.8 |
| PX4용 ROS 2 코드가 ArduPilot에서도 동작한다 | 메시지형이 다르다(px4_msgs 대 표준 ROS 메시지) | 9.6.6.2 |
| DDS의 QoS는 지연을 보장한다 | LATENCY_BUDGET은 힌트이고 강제하지 않는다 | 9.6.5.2 |
| 모든 uORB 토픽이 ROS 2에 나온다 | dds_topics.yaml의 부분집합이며 릴리스마다 다르다 | 9.6.6.1 |
| 직렬 115,200 baud로 충분하다 | 최소 하향 집합만으로 283 %이다 | 9.6.7 |
| 오픈소스 라이선스는 어느 쪽이든 같다 | GPLv3 6항의 설치 정보가 서명·보안 부팅과 충돌할 수 있다 | 9.6.4 |
| 바인드 문구·CRC가 링크를 보호한다 | 충돌 방지와 오류 검출일 뿐 인증이 아니다 | 9.6.10 |
| 사양이 있으면 구현이 따른다 | XRCE 직렬 CRC에서 사양 문구와 구현 표가 다르다 | 9.6.11 |
| 독점 링크는 암호화되어 있다는 제조자 주장을 믿어도 된다 | DJI DroneID는 역공학으로 비암호화가 확인되었다 | 9.6.11 |
미해결 문제. 이 장의 자료로 답할 수 없는 것이 있다. 오픈소스 스택과 미들웨어를 인증 증거의 일부로 인정받는 경로, 보안 부팅과 GPLv3 설치 정보 의무의 양립, DDS 구현별 정체와 데이터 나이의 실측과 손실 군집 모형, RC 링크에 인증을 도입하는 방법, 최신 사전 릴리스(PX4 v1.18.0-rc1)와 ROS 2 Lyrical이 번들하는 Fast DDS에서 이 장의 수치가 유지되는지는 확인하지 못했다 (확인 필요).
9.6.17 체크포인트·연구 질문
체크포인트:
- PX4 발행자(BEST_EFFORT)와 ROS 2 기본 구독자(RELIABLE)가 연결되지 않는 이유와 구독자가 해야 할 일을 설명하라.
vehicle_odometry(CDR 114 B, 100 Hz)가 직렬선에서 차지하는 B/s와 115,200 baud 이용률을 구하라(9.6-calc.py).- 50 Hz 스트림, 이력 깊이 10, 손실 1 %에서 구성 A(S = 220 ms)의 정체 시간 비율을 식으로 계산하라.
- 외부 루프 교차 주파수 1 Hz, 지연 20 ms에서 설정값 주기 2 Hz와 50 Hz의 위상 지연을 구하라.
- ELRS 2.4 GHz에서 500 Hz와 50 Hz의 감도 차이와 거리비, 평균 명령 지연의 차이를 구하라.
- GPLv3 6항에서 설치 정보 제공 의무가 적용되지 않는 조건을 적고, 서명된 펌웨어 제품이 이 조건에 해당하는지 논하라.
연구 질문(25.7에 모은다):
- 오픈소스 오토파일럿·미들웨어를 인증의 입증 방법으로 인정받으려면 어떤 증거와 절차가 필요한가.
- 신뢰성 QoS의 정체와 데이터 나이를 구현별로 측정하고, 군집 손실 모형으로 이 장의 독립 손실 모형을 보정할 수 있는가.
- 보안 부팅을 유지하면서 GPLv3의 설치 정보 의무를 만족하는 키 관리 방식이 존재하는가.
- 인증이 없는 RC 링크 규약에 무선 인증을 도입할 때 지연과 호환성의 비용은 얼마인가.
1차 출처(이 장):
- OMG, Data Distribution Service (DDS) v1.4(formal/2015-04-10) — 2.2.3. 공개 문서.
- OMG, DDS Interoperability Wire Protocol (DDSI-RTPS) v2.5(formal/2022-04-01) — 8.4, 9.4, 10.2.
- OMG, DDS for eXtremely Resource Constrained Environments (DDS-XRCE) v1.0(formal/2020-02-01) — 8.3, 부속서 C.1.
- OMG, DDS Security v1.2(formal/25-03-06) — 7.1.1, 표 49, 10.5. v1.1(formal/2018-04-01)도 대조했다.
- ROS 2 문서(ros2_documentation 저장소 lyrical 분기) — QoS, 미들웨어 공급자, 보안, 릴리스, 실시간 프로그래밍. REP 2000.
- PX4-Autopilot v1.17.0 —
docs/en(architecture·uORB·uxrce_dds·offboard·ros2),dds_topics.yaml,msg/,commander_params.c, LICENSE. - ArduPilot Copter-4.7.2 — README, COPYING.txt,
AP_Scheduler.cpp,Copter.cpp,libraries/AP_DDS. ArduPilot 개발 문서(license-gplv3, learning-ardupilot-introduction·threading, ros2). - eProsima, Fast DDS(master)의
WriterAttributes.hpp·ReaderAttributes.hpp, Micro-XRCE-DDS-Client v2.4.3. - TBS, CRSF Protocol(tbs-crsf-spec, GitHub main). ExpressLRS 4.1.0 소스(
common.cpp·OTA.cpp)와 FAQ. - N. Schiller 외, "Drone Security and the Mysterious Case of DJI's DroneID", NDSS 2023.
- 읽지 못함: DDS-XTypes 본문, Semtech SX1280 데이터시트, ROS 2 Lyrical이 번들하는 Fast DDS의 판
(확인 필요).
다음 장: 9.7~9.11은 군사 중심 장이므로 건너뛴다(BK-08). 이어서 9.12 — 감시·식별 프로토콜: ADS-B(1090ES·UAT)·Mode S·FLARM·Remote ID 메시지·ASTERIX로 간다. 이 장이 비행 제어 소프트웨어와 조종 링크의 규약을 다루었다면, 9.12은 기체가 공중 교통에 자신을 알리는 규약을 다룬다.