21.9.2.1. `ROMFS/px4fmu_common/init.d/rc.mc_apps` 내 조건부 실행 로직 구성

21.9.2.1. ROMFS/px4fmu_common/init.d/rc.mc_apps 내 조건부 실행 로직 구성

우리의 페이로드 드론은 프로펠러가 4~8개 달린 멀티콥터(Multicopter) 베이스다.
따라서 rcS 메인 스크립트를 직접 건드리는 대신, rcS가 중간에 호출하는 멀티콥터 전용 앱 구동 스크립트인 rc.mc_apps 파일의 꼬리 부분에 우리 모듈의 이름을 찔러 넣는 것이 가장 우아한 설계다.

만약 고정익(Fixed-wing) 비행기에 우리 모듈을 달고 싶었다면 rc.fw_apps 파일을, 수직이착륙기(VTOL)에 달고 싶었다면 rc.vtol_apps 파일을 수정해야 할 것이다.

1. 파라미터 기반의 분기문(Branching) 설계

rc.mc_apps 스크립트를 열기 전에, QGroundControl을 통해 CUSTOM_APP_EN 파라미터를 하나 뚫어 놓았다고 가정하자 (파라미터 정의 파일 수정은 21.2장에서 배웠다). 조종사가 이 체크박스를 On(1)으로 두면 우리 모듈이 켜지고, Off(0)로 두면 꺼져야 한다.

안타깝게도 NuttX의 쉘(Shell) 환경인 NSH(NuttShell) 스크립트는 우리가 쓰던 리눅스의 bash 쉘과는 문법이 미묘하게 다르며 매우 가볍고 통제되어 있다. 리눅스처럼 강력한 if [ "$VAR" == "1" ] 같은 문법 대신, PX4가 지원하는 내부 명령어인 param compare 유틸리티를 활용해야만 극한의 안정성을 도모할 수 있다.

2. rc.mc_apps 하단 구조체 주입

소스 코드 트리의 ROMFS/px4fmu_common/init.d/rc.mc_apps 파일을 열어 가장 밑바닥, 즉 기본 멀티콥터 앱들(지형 추적기능 vmount, 충돌 방지 collision_prevention 등)의 구동 명령어가 끝나는 바로 밑에 아래의 코드를 정성스레 심어준다.

# [rc.mc_apps 스크립트 하단부]

# ... 기존 PX4 멀티콥터 앱들 구동 구간 ...

vmount start
collision_prevention start

# ------------------------------------------------------------------
# [커스텀 모듈] 페이로드 자동 투하 제어기 (Payload Auto Drop)
# ------------------------------------------------------------------

# CUSTOM_APP_EN 파라미터 값이 1(활성화)인지 커널 유틸리티로 비교한다.
# 값이 1과 일치하면 if 블록 안으로 진입한다.
if param compare CUSTOM_APP_EN 1
then
    echo "Starting Custom Payload Auto Drop Module..."
    # 우리의 C++ 데몬을 백그라운드로 띄우는 핵심 명령어!
    payload_autodrop start
fi

# ------------------------------------------------------------------

# rc.mc_apps 스크립트 종료

이 4줄짜리 스크립트는 실로 혁명적이다.

  1. param compare 커맨드는 플래시 메모리 보관소에서 CUSTOM_APP_EN 파라미터 값을 초고속으로 긁어와 1이라는 정수와 매칭을 시도한다.
  2. 만약 일반적인 촬영용 드론이라 이 값이 0으로 되어있다면, if 블록은 즉시 스킵(Skip)되어 버리며 RAM과 CPU 자원을 1byte도 낭비하지 않는다.
  3. 값이 1이라면, 부팅 화면(Serial Console)에 “Starting Custom…“이라는 로그 한 줄을 멋지게 띄워주며 우리의 payload_autodrop start 명령어를 커널에 던진다!

이제 우리의 모듈은 PX4 공식 모듈들과 어깨를 나란히 하며, 드론의 전원을 뽑거나 강제로 payload_autodrop stop 명령어를 치기 전까지 영원히 Run() 루프를 돌며 조종사의 스위치 명령을 기다리는 **진정한 데몬(Daemon)**이 되었다.

하지만, 부팅(Start)이 완벽하다고 끝이 아니다. 만약 누군가 모듈을 강제로 끄거나, 펌웨어 업데이트를 위해 픽스호크 보드가 소프트 셧다운(Shutdown)에 들어갈 때 우리의 모듈이 메모리를 토해내지 못하고 버티면 어떻게 될까?
데몬의 생로병사를 관장하는 마지막 퍼즐, “안전한 시스템 셧다운(Shutdown) 대응 로직“을 21.9.3장에서 완벽하게 정리하며 이 기나긴 커스텀 모듈 개발의 여정을 마무리 짓자.