21.9.1.1. rcS 메인 스크립트 내 파라미터 로딩 및 마운트 프로세스

ROMFS/px4fmu_common/init.d/rcS 스크립트를 실제 소스 트리에 들어가 열어보면 쉘 스크립트(Shell Script) 문법으로 작성된 길고 험난한 코드들이 등장한다. 우리는 이 안에서 우리 모듈과 직결된 중요한 생명선 두 가지, **‘저장소 마운트(Mount)’**와 **‘파라미터(Parameter) 로딩’**이 일어나는 정확한 시점을 짚어내야 한다.

1. MTD 파티션과 SD 카드 마운트 (저장소의 개통)

전원이 들어오고 아주 기초적인 NuttX 커널 세팅이 끝나면, rcS 스크립트는 가장 먼저 내장 플래시 메모리(MTD 파티션)와 외장 마이크로 SD 카드를 파일 시스템에 마운트(mount)하려고 시도한다.

# [rcS 쉘 스크립트 발췌]
# Mount MTD 파티션 (파라미터가 저장되는 곳)
if ! mtd start; then
    echo "ERROR: MTD Mount failed!"
fi

# Mount SD Card (비행 로그와 커스텀 미션이 저장되는 곳)
if mount -t vfat /dev/mmcsd0 /fs/microsd; then
    # 마운트 성공!
    echo "[init] microSD mounted at /fs/microsd"
else
    # SD 카드가 없거나 포맷이 깨졌을 때
    tone_alarm merror # 삐빅! 하는 에러 경고음 발생
fi

내 모듈(payload_autodrop)이 만약 SD 카드에 자체적인 텍스트 형식의 배달 목적지 좌표록(Delivery Log)을 기록해야 하는 모듈이라면, 절대로 저 mount 명령어가 끝나기 전에 모듈을 실행시켜선 안 된다. SD 카드가 없는데 파일 쓰기(write)를 시도하다가 커널 패닉(Kernel Panic)을 일으키며 드론이 켜지지도 않는 끔찍한 버그를 만들게 된다.

2. 파라미터(Parameter) 백업과 로딩

PX4 아키텍처에서 가장 중요하게 여겨지는 두 번째 관문은 플래시 메모리(/fs/mtd_params)에 꽁꽁 언 채로 저장되어 있던 거대한 파라미터 묶음(BSON 포맷)을 RAM 제어기 통제하에 올려놓는 과정이다.

우리의 페이로드 모듈은 QGC에서 설정한 TARGET_ALT, DROP_SEC 파라미터 값을 기반으로 생사를 결정짓는다. 만약 이 파라미터 서버(Parameter Server) 데몬이 켜지기도 전에 내 모듈을 성급하게 실행시키면, 내 모듈은 TARGET_ALT를 찾지 못해 쓰레기 값(Garbage Value)이나 0으로 초기화해 버린다.

따라서 우리는 rcS 파일 안에서 다음의 마법 같은 명령어 한 줄이 지나가기를 끈질기게 기다려야 한다.

# [rcS 쉘 스크립트 발췌]
# 파라미터 데몬 시작 및 mtd 메모리에서 값 읽어오기
param start
param load /fs/mtd_params

이 param load 명령이 터미널을 무사히 통과하는 순간, 비로소 우리의 모듈은 안심하고 QGC 파라미터 값을 읽어 들일 수 있는 ’안전 구역(Safe Zone)’에 돌입하게 된다.

그렇다면 저장소 마운트도 끝났고 파라미터도 메모리에 다 올라왔으니, 이제 당장 우리의 페이로드 모듈을 실행(Daemonize)시켜 달라고 부트 스크립트에 한 줄 적어넣으면 될까?
아직 성급하다. 하드웨어 초기화와 센서 앱 구동 사이에 미묘하게 벌어져 있는 완벽한 틈새, “진정한 커스텀 모듈 삽입 시점(Order of Execution)“의 진실을 다음 21.9.1.1.1장에서 매의 눈으로 찾아보자.