21.9.1. ROMFS/init.d 부트 스크립트 실행 트리(Execution Tree) 분석
비행기 조종석에 앉아 엔진 시동을 거는 체크리스트(Checklist) 영상들을 본 적이 있을 것이다. 조종사의 손길이 닿아야 하는 스위치의 순서는 목숨과 직결되어 있기에 매우 엄격하고 순차적이다.
픽스호크 보드에 전기를 먹이는 순간, 내부에 깔린 NuttX 운영체제도 어김없이 이 무자비한 ’부팅 체크리스트’를 집어 든다. 이 체크리스트가 보관된 서류철이 바로 PX4 소스코드 트리의 심장부인 ROMFS/px4fmu_common/init.d 폴더다.
1. 세상의 시작, rcS (Run Command System)
init.d 폴더에는 마치 외계어처럼 쓰인 수백 개의 텍스트 파일들이 빼곡히 들어차 있다. 하지만 그 무질서함 속에서도 유일하게 운영체제가 맨 처음 찾아내어 실행시키는 ‘창세기 알파(Alpha)’ 스크립트가 존재하는데, 그 파일의 이름이 바로 rcS 이다.
이 rcS (Run Command System) 스크립트는 약 1,000줄이 넘어가는 어마어마한 길이를 자랑하며, 픽스호크가 부팅되는 첫 0.1초부터 5초까지의 모든 운명을 손에 쥐고 있다. 이 스크립트는 혼자서 모든 일을 처리하지 않고, 특정 시점마다 곁가지(Child Scripts)로 뻗어 나가며 드론의 파츠들을 하나씩 조립해 나가는 거대한 실행 트리(Execution Tree)를 형성한다.
2. 시스템 부팅의 4대 관문
개발자가 rcS 파일의 소스를 열어보면, 대략적으로 다음과 같은 거대한 4단계의 관문으로 흐름이 갈라져 내려간다는 것을 알 수 있다. 이 흐름을 이해하는 것은 백혈구(Custom Module)를 어느 혈관(Script Point)에 주사할 것인지 결정하는 기초 해부학이다.
- 관문 1: 기계적 깨어남 (OS Level)
- 가장 먼저 운영체제의 환경 변수들(Environment Variables)이 세팅된다.
- SD 카드가 꽂혀있는지 찔러보고,
mount명령을 통해 마이크로 SD 카드의 파일시스템(/fs/microsd)을 커널에 부착한다. 만약 SD 카드가 없거나 물리적으로 부서져 있다면, PX4는 시그니처 폴백 경고음(비프음)을 뿜어낸다.
- 관문 2: 나의 정체성 탐식 (Board & Parameter Level)
rc.board_defaults스크립트를 호출하여 내가 지금 픽스호크 4(Pixhawk 4)인지, 픽스레이서(Pixracer)인지 보드의 정체성을 자각한다.- 이후 가장 중요한 파라미터(Parameters) 값들을 플래시 메모리 보관소(
/fs/mtd_params)에서 읽어온다. 이것을 읽어오지 못하면 드론은 자신이 몇 미터짜리 드론인지, 투하 고도를 몇 미터로 해야 하는지도 모르는 바보가 된다.
- 관문 3: 감각의 각성 (Sensors Level)
rc.sensors스크립트를 거칠게 호출한다!- 보드에 납땜 되어 있는 I2C, SPI 버스를 타고 전류를 흘려보내 자이로 센서, 가속도계, 지자기 센서들의 전원을 켠다.
- uORB 버스에 가장 먼저
sensor_gyro,sensor_accel토픽들이 미친 듯이 발행(Publishing)되기 시작하는 시점이 타오른다.
- 관문 4: 사령부와 수뇌부의 집결 (Apps & Controllers Level)
- 드디어 EKF 필터(
ekf2_main)가 구동되어 센서 데이터를 위치 데이터로 정제하기 시작한다. - 자세 제어기(
mc_att_control), 위치 제어기(mc_pos_control) 데몬들이 속속 메모리에 올라온다. - 이 관문을 통과하면, 비로소 드론은 언제든지 이륙할 수 있는 완전무결한 백그라운드 구동 상태(Daemonized State)가 된다.
3. 질문: 내 모듈은 대체 이 트리의 어디에 끼워 넣어야 할까?
우리의 payload_autodrop 모듈은 반드시 저 4대 관문 중에서 특정 시점 이후에 위치해야 한다.
만약 모듈을 너무 일찍(관문 1 직후 등) 실행시켜버리면 어떤 대참사가 벌어질까? 이 치명적인 실행 순서(Order of Execution)의 타당성을 따지는 디버깅 시나리오를 다음 21.9.1.1장에서 샅샅이 파헤쳐보겠다.