13.6.1. 비행 전(Pre-flight) RTK 상태 검증을 위한 커맨드라인 인터페이스(CLI) 디버깅

13.6.1. 비행 전(Pre-flight) RTK 상태 검증을 위한 커맨드라인 인터페이스(CLI) 디버깅

수백 수천만 원에 달하는 고가의 산업용 기체(Industrial UAV) 배터리를 꽂고 스로틀(Throttle)을 올리기 전, 가장 두려운 순간은 조종사 화면상에 “RTK GPS Position Invalid” 혹은 “Nav Fail“이라는 짧지만 소름 돋는 에러 메시지가 떴을 때이다. 이때 지상 관제 시스템(QGroundControl)이 제공하는 미려한 2D/3D 지도(Map) 스크린과 커다란 초록색/빨간색 상태 아이콘만 쳐다봐서는 절대로 근본적인 원인을 파악할 수 없다.

드론 시스템 안쪽에서 하드웨어 센서들(u-blox 칩셋 포함)과 PX4 비행 제어 스택 펌웨어는 끊임없이 무수한 저수준(Low-level) 숫자들과 디버깅 로그를 내뱉고 있기 때문이다. 본 절에서는 기체가 이륙을 거부하는 바로 그 긴장된 순간, QGC의 숨겨진 백도어 인터페이스인 MAVLink Console을 열고 비행 제어기의 운영체제(NuttX 커널) 터미널 셸(Shell)인 NSH (NuttShell) 속으로 직접 진입하여, 실시간으로 uORB 시스템 내부 변수를 검열하고 센서 상태를 해부(Dissection)하는 명령줄 인터페이스(CLI) 기반 실시간 디버깅의 철학과 필수 타격 기법들을 체계적으로 정립한다.

1. QGC의 GUI 한계와 NSH(NuttShell)의 절대적 권력

QGC와 같은 훌륭한 관제 UI는 엄청나게 방대한 비행 상황을 조종사가 한눈에(Glanceable) 인간 공학적으로(Ergonomic) 인지할 수 있도록, 이면에 흐르는 수천 개의 시스템 변수들을 강제로 축약하고 마스킹(Masking)하여 보여준다. 즉, QGC 상단 헤더에 “GPS 3D Lock“이라고 떴다 하더라도 이 정보는 MAVLink의 수많은 패킷 속 SYS_STATUS의 한 비트(Bit)가 번역된 결과 창구에 불과하다.

하지만 개발자와 엔지니어의 세계로 들어가면 다음과 같은 무자비한 심층 지표가 필요하다.

  • 위성 7개를 잡았는데 노이즈(SNR) 수치가 폭망(Drop)하여 EKF2 필터가 고의로 무시하고 있는가?
  • QGC에서 보낸 RTCMv3 데이터 100 패킷 중 무선 노이즈로 인해 CRC가 깨져 버린(Failed) 찌꺼기가 몇 개인지, 이로 인한 ‘Float’ 추락 상태 때문인지?
  • u-blox 칩이 ephemeris(천체력) 캐싱에 지연이 스파이크를 때리는가?

이러한 생생한 시스템 건강 문진을 수행할 수 있는 청진기는 오로지 FC(비행 제어기) 하드웨어에 내장된 디버깅 시리얼 포트(Debug Port) 혹은 QGroundControl 의 MAVLink Console을 통해 직접 타이핑(Typing)으로 접속하는 NuttX 셸(NuttShell, NSH) 뿐이다. NSH는 리눅스의 bash 와 비슷하여 파일 시스템을 볼 수 있고(/fs/microsd), 로드된 커널 모듈(드라이버)의 인스턴스를 직접 정지(Stop)시키거나 상태(Status)를 덤프(Dump)할 수 있는 무한대의 슈퍼유저(Root) 권한을 지닌다.

2. CLI 디버깅의 핵심 타겟팅: ’추측’에서 ’확인’으로

현장의 추운 필드(Field)에서 노트북 하나로 디버깅을 시도할 때, 당황하지 않고 올바른 커맨드를 입력하는 것이 디버깅 속도의 핵심이다. 직관에 의한 추측을 물리적인 수치 확인으로 증명하기 위한 대표적인 진입 프로세스는 다음과 같다.

  1. 하드웨어 드라이버 수준의 덤프(Dump)
    가장 먼저 u-blox GPS 하드웨어 자체가 텔레메트리 보드레이트 통신을 제대로 수행하는지, 에러가 스터터링(Stuttering)을 일으키지 않는지 gps status 류의 커맨드를 때려 드라이버 내부의 C++ 클래스 전역 변수(Accumulator)를 화면에 쏟아내게 한다.
  2. 미들웨어(uORB) 라우팅 흐름 체킹(Sniffing)
    하드웨어 드라이버가 살아있다면, 이 드라이버가 추출해낸 값(예: 위치, 속도 분산값)이 PX4-Autopilot의 심장부(EKF2)로 무사히 넘어갔는지 확인해야 한다. listener 커맨드를 활용해 특정 토픽(Topic) 덩어리를 소스 코드의 C 구조체 형태 그대로 터미널에 프린트(Print)하여 눈으로 스니핑(Sniffing)한다.
  3. OS 태스크(Task) 스레드 점유율 감시
    명령어 top 을 통해 백그라운드에서 동작 중인 프로세스들이 데드락(Deadlock)에 빠졌거나 CPU 클럭(Tick) 점유율을 비정상적으로 갉아먹고 있는지, 스택 잔여량(Stack margin)이 넘쳐 스택 오버플로우 폭발 직전인지 모니터링한다.

3. 요약: 터미널의 투박함 뒤에 숨겨진 구조물

비행 로그 파일(.ulg)을 열어보는 사후 약방문(Post-mortem) 방식은 기체가 땅에 떨어져 산산이 조각난 뒤에야 이유를 알려주는 잔인한 검시관(Coroner)이라면, MAVLink Console과 NSH를 활용한 이 커맨드라인 인터페이스 디버깅 기법은 시동 전 생사에 갈림길에 선 기체 시스템의 맥박을 실시간으로 짚어내는 외과의사의 메스(Scalpel)와 같다.

이후의 하위 절들에서는 이 NSH 콘솔 위에서 가장 빈번하게, 그리고 가장 뼈아픈 RTK GPS 오류들을 찾아내기 위해 반드시 타이핑해야 할 핵심 명령어(gps status, listener vehicle_gps_position)와, 그 화면 출력 수치(Raw Data)들이 암시하는 C++ 소스 코드 레벨의 기술적 원소들을 한 줄씩 심층 매핑하여 해부할 것이다.