21.9.1.1.1. 하드웨어 초기화(rc.board_defaults) 이후 센서 앱 구동 시점 사이에 커스텀 모듈을 삽입하기 위한 스크립트 실행 순서(Order of Execution) 파악

rcS 부트 스크립트라는 거대한 폭포수 아래에서 물길의 방향을 조금씩 뒤틀어보는 상상을 해보자. 우리의 payload_autodrop 모듈을 실행시키는 명령어 단 한 줄을, 이 수천 줄의 rcS 코드 중 대체 어디쯤에 삽입해야 가장 완벽하게 데몬이 돌아갈까?

엔지니어링에서 ’순서(Order)’는 곧 생태계의 서열이다. 잘못된 시점에 데몬을 깨우면 커스터마이징 모듈은 즉사(Crash)하거나 벙어리가 된다.

1. 금지된 진입로 (Forbidden Zones)

• 진입 시도 1: 파일 시스템 마운트 직후 (관문 1 직후)
• 결과: ❌ 즉사 (Crash)
• 이유: 모듈은 시작되자마자 QGC 파라미터(목표 고도 등)를 읽으려고 덤벼들지만, 커널에서는 아직 param start 스크립트를 돌리지 않았다! 파라미터 서버가 죽어있으니 모듈은 메모리 폴트(Fault)를 내며 시스템 부팅 자체를 마비시킨다.
• 진입 시도 2: 파라미터 로딩 직후, 센서 초기화 이전 (관문 2와 3 사이)
• 결과: ❌ 벙어리 무한 대기 (Deadlock)
• 이유: 모듈이 무사히 파라미터를 읽고 FSM 루프를 구동했다. 하지만 FSM은 첫 번째 줄에서 _local_pos_sub.update()를 호출하며 uORB 버스에서 위치 데이터를 꺼내려 한다. 그러나 아직 rc.sensors 와 ekf2가 켜지지 않아 uORB 우체통에는 텅 빈 먼지만 날리고 있다.

2. 진정한 황금 시간대 (The Golden Window)

커스텀 모듈, 특히 센서 데이터를 **‘소비(Subscribe)’**하고 액추에이터 명령을 **‘발행(Publish)’**하는 하이 레벨(High-level) 컨트롤러 모듈이 입장해야 하는 가장 적절한 타이밍은, 이미 드론의 모든 감각(Sensor)과 사령부(Commander) 시스템이 완벽히 세팅을 끝마친 직후 이어야만 한다.

rcS 스크립트의 거의 맨 마지막 하단부를 보면 우리는 황금 시간대의 입구를 발견할 수 있다.

# [rcS 쉘 스크립트 맨 하단 부분 발췌]

# 1. 기체 고유의 하드웨어와 앱들을 세팅하는 스크립트 호출
. /etc/init.d/rc.autostart

# 2. 로깅 앱(SD 카드 기록) 시작
logger start

# 3. MAVLink 통신(GCS, 텔레메트리) 데몬 시작
mavlink start

# --- [여기가 바로 커스텀 컨트롤러 데몬들이 들어갈 황금 시간대!] ---

# (나중에 여기에 우리의 실행 코드를 넣게 된다)

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

# 부팅 완료를 알리는 환희의 멜로디 (빰-빰-빰!)
tone_alarm startup

위의 흐름을 보라. 센서, EKF, 로거, 그리고 통신 데몬(MAVLink) 모듈까지 전부 백그라운드에 안착했다.
이 시점이야말로 우리의 payload_autodrop 모듈이 start 명령을 외치며 무대에 등단해도, 파라미터 충돌이나 uORB 토픽 지연에 의한 어떤 부작용도 겪지 않는 완벽한 무균실 상태다.

하지만 실제 PX4 실무 개발에서 내가 만든 모듈 하나를 켜겠다고 저 신성불가침의 커널 코어 스크립트인 rcS 파일을 직접 수정(Hardcoding)하는 것은 죄악(Anti-pattern)으로 여겨진다. rcS는 수만 명의 오픈소스 개발자들이 사용하는 공통의 뼈대이기 때문이다.

그렇다면 rcS 파일의 소스 코드를 단 한 글자도 건드리지 않으면서, 어떻게 방금 우리가 찾아낸 저 ’황금 시간대’에 내 모듈의 실행 명령을 세련되게 주입(Inject)할 수 있을까?
PX4가 자랑하는 완벽한 기체 프로파일(Airframe Profile) 연동 아키텍처인 SYS_AUTOSTART의 마법을 21.9.2장에서 해부해 보도록 하자.