21.2.1.1.1. `menuconfig CUSTOM_MODULES` 블록 생성을 통한 GCS 및 빌드 도구에서의 가시성 확보

21.2.1.1.1. menuconfig CUSTOM_MODULES 블록 생성을 통한 GCS 및 빌드 도구에서의 가시성 확보

PX4 모듈 개발에 있어서 Kconfig 파일은 단순히 C++ 컴파일러에게 “이 모듈을 빌드할 거냐 말 거냐“를 알려주는 온오프(On/Off) 스위치 그 이상의 의미를 갖는다. Kconfig 파일의 노드 이름은 펌웨어 바이너리 단계를 거쳐, 최종적으로는 QGroundControl(QGC) 같은 지상제어국(GCS) UI 화면에 표출되는 파라미터(Parameter) 검색 가시성까지 직결되기 때문이다.

1. menuconfig와 config의 결정적 차이

앞선 단원에서 잠깐 언급했듯, Kconfig 문법에서 모듈을 선언하는 가장 대표적인 예약어는 config와 menuconfig 두 가지가 있다.

# 방식 1: 단순 config (나쁜 예)
config MODULES_MY_APP
    bool "My Application"

# 방식 2: menuconfig (좋은 예)
menuconfig MODULES_MY_APP
    bool "My Application"

만약 여러분이 자신이 만든 my_app 패키지 안에 아주 복잡한 딥러닝 자율 비행 로직을 넣었고, 그 안에 ‘카메라 해상도’, ‘추론 주기(Hz)’, ‘장애물 회피 민감도’ 등 수많은 하위(Sub) 설정값들을 추가해야 한다고 가정해 보자.

  • 방식 1(config)을 사용하면 모든 하위 파라미터들이 빌드 시스템(menuconfig) 창에서 수평적인 리스트 형태로 너저분하게 펼쳐져, 다른 PX4 기본 모듈 설정값들과 뒤섞여 버린다.
  • 반면 방식 2(menuconfig)를 사용하면, My Application이라는 텍스트 옆에 반가운 화살표(--->)가 생성된다. 사용자가 메뉴에서 Enter 키를 누르면, 오직 내 모듈만을 위한 프라이빗한 서브 윈도우(Sub-window) 창으로 쏙 빨려 들어간다.

2. Kconfig 계층 구조가 GCS 파라미터 그룹으로 매핑되는 원리

PX4 빌드 시스템의 가장 우아한 점은, 이 Kconfig 트리 상의 계층 구조 분석이 단순히 make 도중 끝나는 것이 아니라 XML 파라미터 메타데이터 추출(Extraction) 과정으로 고스란히 이어진다는 것이다.

  1. 빌드 스크립트는 menuconfig MODULES_CUSTOM_APP 블록을 발견하면, 컴파일 타임에 parameters.xml 파일 안에 새로운 그룹 노드(Group Node)를 하나 파낸다.
  2. 그리고 그 아래에 속한 하위 C++ 파라미터들(예: CUSTOM_SPEED, CUSTOM_ALT)을 모두 이 부모 노드 밑으로 논리적으로 묶어준다.
  3. 펌웨어가 탑재된 픽스호크 보드가 GCS(QGroundControl)와 시리얼 통신을 맺는 순간, GCS는 보드로부터 이 XML 메타데이터를 통째로 다운로드받는다.
  4. 결과적으로 QGC의 ‘파라미터(Parameters)’ 탭을 열었을 때, 여러분의 자랑스러운 커스텀 앱 이름이 독립적인 대분류 카테고리(Category)로 떡하니 자리 잡게 된다.

초보 개발자들은 자신의 모듈을 켜기 위한 Kconfig 변수를 아무 폴더(src/modules/systemcmds/Kconfig 등) 파일 맨 끝에 대충 하드코딩으로 우겨넣기도 한다. 이렇게 되면 자신의 모듈 파리미터들이 ’시스템 커맨드’라는 엉뚱한 GCS 카테고리에 들어가 버려, 비행장에서 설정값을 찾지 못해 등줄기에 식은땀이 흐르는 참사를 겪게 된다.

여러분의 모듈이 독립적이고 당당한 시민권을 얻기 위해서는 반드시 나만의 독립된 menuconfig 블록을 만들고, 그 블록이 올바른 상위 Kconfig 카테고리에 링크되도록 가시성을 확보해야 한다. 가시성을 확보했다면, 이제 내 모듈이 특정 칩셋에서만 켜지도록 논리적 조건을 거는 depends on 지시어의 활용법을 이어지는 21.2.1.1.2 단원에서 짚고 넘어가자.