28.5.3. 모드 상태 브로드캐스팅 및 GCS(Ground Control Station) 피드백 체계

28.5.3. 모드 상태 브로드캐스팅 및 GCS(Ground Control Station) 피드백 체계

픽스호크 내부에서 vehicle_control_mode 플래그 조립을 통해 치열하게 비행 상태를 결정하고 나면, 이 상태는 필연적으로 외부 관찰자—특히 조종을 담당하는 지상 통제소(GCS; Ground Control Station)나 컴패니언 컴퓨터—에게 실시간으로 공유되어야 한다. 기체가 현재 무슨 모드에 진입해 있고 어떤 상태인지 모르면 조종사는 기체 탈취(예: GPS Fail 시 수동 제어로 복귀) 타이밍을 놓치게 되며, QGroundControl(QGC)과 같은 UI는 올바른 텔레메트리 화면을 그려낼 수 없다.

본 절에서는 PX4-Autopilot이 내부 토픽(uORB)의 비행 모드를 어떠한 방식으로 MAVLink 프로토콜을 거쳐 외부로 브로드캐스팅(Broadcasting)하는지, 그 피드백 체계의 전반적인 아키텍처를 분석한다.

1. 개요: 상태 관리의 중앙화 (The Commander Module)

앞선 장들에서 언급된 제어 플래그(flag_control_position_enabled 등)는 다단 계층의 실행 스위치 역할을 하지만, 모드 이름표 그 자체는 아니다. 이 방대한 비트맵 상태를 종합하여 현재 기체의 공식적인 항법 상태(Navigation State) 를 규정하는 중앙 관제탑이 바로 커맨더 모듈(Commander Module) 이다.

  1. 상태 식별: 커맨더는 스위치 맵, 배터리 상태, EKF2의 GPS 및 비전 추정치 유효성을 종합 평가하여 현재 기체의 단일 상태를 결정한다. (예: NAVIGATION_STATE_POSITION, NAVIGATION_STATE_OFFBOARD)
  2. uORB 발행: 결정된 상태는 vehicle_status.msg 토픽 안에 nav_state 라는 멤버 변수 형태로 저장되어 퍼블리싱된다.
  3. MAVLink 변환 대기: 이 토픽은 곧이어 기체 밖으로 데이터를 송출할 책임이 있는 MAVLink 스트리밍 모듈(mavlink_messages.cpp) 이 서브스크라이브(Subscribe)하게 된다.

2. 모드 브로드캐스팅 파이프라인 (The Feedback Loop)

PX4 내부의 nav_state가 지상 관제소 화면의 “Position Mode“라는 글자로 나타나기까지는 다음과 같은 변환 스트림(Stream) 과정이 일어난다.

2.1 1단계: MAVLink 모듈 수신 및 변환

텔레메트리 송신을 담당하는 mavlink 앱의 백그라운드 태스크는 1Hz 단위로(기본 Heartbeat 송신 주기) vehicle_status 토픽을 읽어 들인다.
내부 구조체인 vehicle_status_s 의 nav_state 값은 PX4 고유의 열거형(enum) 정수이다. 그러나 MAVLink는 오픈소스 상호 운용성을 지향하는 범용 프로토콜이므로, 이 PX4 고유 번호를 그대로 쏠 수는 없다.

따라서 스트리밍 모듈은 이 nav_state 값을 MAVLink 메시지 스펙(MAVLink Specification)에 공식적으로 정의된 HEARTBEAT 메시지의 custom_mode 와 base_mode 필드로 인코딩(Encoding) 하는 과정을 거친다.

2.2 2단계: HEARTBEAT 메시지를 통한 광역 전파(Broadcasting)

HEARTBEAT 메시지는 MAVLink 네트워크 상에 존재하는 모든 노드(GCS, 안테나 트래커, ROS2 노드 등)를 향해 1초마다 무조건 브로드캐스팅되는 가장 핵심적인 “생존 및 상태 신고서“이다.

  • Message ID: #0
  • 기체의 무장 상태(Armed/Disarmed)와 함께 인코딩된 custom_mode 필드가 실려 지상으로 무선(Radio) 송출된다.

2.3 3단계: QGroundControl (GCS) 측 디코딩(Decoding)

QGC는 시리얼이나 UDP 채널을 통해 날아온 HEARTBEAT 패킷을 파싱(Parsing)한다.
QGC 내부의 PX4FirmwarePlugin.cc 소스코드 안에는 MAVLink의 custom_mode 필드를 다시 사람이 읽을 수 있는 ASCII 문자열(예: "Position", "Hold", "Mission")로 역변환(Decoding)하는 딕셔너리(Dictionary) 매핑 테이블이 존재한다.

이렇게 역변환된 문자열이 최종적으로 QGC 상단 중앙 플라이트 디스플레이(Flight Display) 툴바에 노란색 또는 녹색 글씨로 띄워지며, 조종사에게 기체의 현재 모드 상태를 시각적인 형태로 피드백(Feedback)한다.

3. 피드백 지연율(Latency)과 신뢰성 문제

모드 상태가 이렇게 멀티 홉(Multi-Hop) 과정을 거쳐 화면에 출력되기 때문에 시스템 아키텍트는 지연(Latency) 문제를 반드시 숙지해야 한다.

  • Heartbeat 주파수 제약: 기본적으로 모드 브로드캐스팅은 HEARTBEAT 에 얹혀 가므로 1초에 한 번만 전파된다. 조종사가 조종기 스위치를 토글(Toggle)하여 모드를 변경했어도 QGC 화면이 “Position“에서 “Manual“로 바뀌는 데에는 최장 1초의 시각적 랙(Lag)이 발생할 수 있다.
  • ACK 중심의 상태 보장 기법: COMMAND_LONG (모드 변경 명시적 MAVLink 호출)과 같은 양방향 프로토콜에서는 QGC가 모드 변경을 ’요청’한 경우 픽스호크가 상태 전환을 시도한 뒤 COMMAND_ACK를 즉각적으로 리턴한다. QGC는 이 ACK(응답)를 즉시 수신하여 성공(Result: Accepted)을 확인하면, 정규 Heartbeat가 도달하기 전이라도 즉시 UI 문자열을 선반영하여 갱신함으로써 조종사의 시각적 랙을 최소화하는 피드백 보상 기법을 사용한다.

4. ArduPilot과의 브로드캐스팅 차이 (MAVLink 철학)

모드 상태를 외부로 퍼블리싱한다는 개념은 동일하지만 세부적인 매핑에서 약간의 표준화 방향성이 다르다.

  • PX4 (Custom Mode 인코딩 최적화): base_mode 비트 마스크에 Arm/Disarm 등 일반론적 상태 패러다임을 담고, 모드와 결부된 고도로 특화된 상태(예: Offboard, Takeoff, Land 등)를 32비트짜리 custom_mode 공간 안에 서브 모드(Sub-mode) 계층화 방식으로 압축하여 담아낸다 (다음 절에서 상술).
  • ArduPilot: 초창기부터 발전해 온 관행 상 custom_mode 공간 전체를 1차원적인 열거형(Enum: 0=Stabilize, 1=Acro, 2=AltHold, 3=Auto 등)으로 단순 맵핑하여 쓰는 경향이 짙다.

PX4의 방식은 계층이 존재하여 인코딩/디코딩 과정이 상대적으로 복잡하지만, 모드가 수십 가지로 팽창하는 현대 자율주행 연구 상황에서 비트 확장성(Extensibility) 면에서 더 견고한 아키텍처를 제공한다.