19.7. 커스텀 모듈 빌드 설정 및 SITL(Software-In-The-Loop) 테스트

19.1 단원부터 19.6 단원까지, 우리는 PX4 uORB 미들웨어의 가장 어둡고 깊은 심연 파일 시스템(VFS) 속을 기어 다니며, 단일 스레드 퍼블리셔부터 시작해 C++ 객체 지향 WorkQueue 이벤트 콜백 구독자, 그리고 다중 인스턴스(Multi-instance) 핫스왑 페일세이프 아키텍처까지 섭렵해 냈다. 코드상으로는 이미 전 세계 상위 1% 엔지니어들만이 이해할 수 있는 최고급 드론 코어 데몬 로직을 완벽하게 주조(Casting)해 낸 것이다.

하지만 아무리 경이롭고 거대한 C++ 모듈 스크립트를 수백 장 짜놓았다 한들, 그것이 PX4 펌웨어 운영체제의 컴파일 트리(Compile Tree) 시스템 톱니바퀴 안에 올바르게 결속(Linking)되지 않는다면 한낱 에디터 속 텍스트 쓰레기에 불과하다.
픽스호크라는 엄격한 실시간 운영체제(RTOS) 생태계는, 외부 잡상인이 자신이 짠 코드를 메인 커널 빌드(Build) 파이프라인에 얹기 위해서는 아주 엄격하고 냉혹한 ‘빌드 체인 라이센싱(Build Chain Licensing)’ 서류 절차를 거치도록 강제하고 있다.

이제 19.7 통합 단원에서는 우리가 피땀 흘려 코딩한 그 px4_uorb_example이라는 커스텀 스크립트 덩어리를, 어떻게 PX4의 거대한 CMake 컴파일러 망에 쑤셔 넣어 영구적인 바이너리(Binary) 실행 파일로 뽑아낼 것인가를 다루게 된다.

나아가 하드웨어 실물 기체(Pixhawk Board)를 불태워 먹기 전에, 오직 당신의 리눅스(Linux) PC 내부에 시뮬레이션 가상 픽스호크 보드와 가상 커널을 띄워(SITL: Software-In-The-Loop), 내가 만든 데몬을 가상의 공용 VFS에 실시간으로 던져놓고 1000Hz 주파수가 제대로 나오는지, 타임아웃 코어 덤프(Core Dump) 추락 에러가 나는지를 자비 없이 검증해 내는 가상 시뮬레이션 통합 테스트(SITL Testing)의 모든 전진 기지를 완벽히 구축해 낼 것이다.

이 단원을 꿰뚫고 나면 당신은 비로소 코드만 짜는 학부생 프로그래머를 넘어서서, 리눅스 커널 빌드 시스템(CMake)과 소프트웨어 통합 검증 시뮬레이터를 자유자재로 다루며 기체를 공중에 띄우기 전 100% 무결점을 수학적으로 검사해 내는 진정한 ’항공 우주 시스템 아키텍트’로 진화하게 될 것이다.