21.3.3. 시뮬레이션 환경(SITL) 컴파일 및 로깅 테스트

성공적으로 컴파일될 것 같은 멋진 파싱 루프와 제어 로직을 다 짜고 났다면, 이제 실제로 코드를 돌려볼 차례다. 하지만 드론 개발자라면 절대 자기가 갓 짠 따끈따끈한 C++ 모듈을 컴파일하자마자 진짜 픽스호크 하드웨어에 욱여넣고 프로펠러를 돌리지 않는다.

자칫 포인터 에러로 펌웨어가 패닉(Panic)에 빠져 모터가 미쳐 날뛴다면, 300만 원짜리 기체 추락은 둘째치고 여러분의 손가락이나 두개골이 무사하지 못할 수 있기 때문이다.

이러한 유혈 사태를 막기 위해 PX4 아키텍처는 **SITL(Software In The Loop)**이라는 완벽하고 우아한 가상 비행 테스트 베드를 제공한다.

1. SITL의 철학: 내 노트북이 픽스호크가 되다

SITL의 개념은 간단하다.
픽스호크 하드웨어(ARM 칩셋, 센서칩, PWM 핀)를 타겟으로 삼아 크로스 컴파일(Cross-compile)하던 기존의 빌드 체계를 살짝 비틀어, **“지금 코딩을 하고 있는 내 리눅스(또는 macOS) 노트북 자체를 픽스호크 보드라고 간주하고 컴파일해라”**라고 명령하는 것이다.

이 철학이 제대로 동작하기 위해 PX4는 다음 두 가지 가짜(Mock) 환경을 완벽하게 모사(Simulation)해 낸다.

1. 가짜 운영체제 (Fake OS): 내 노트북의 우분투(Ubuntu) 리눅스가 픽스호크의 NuttX 커널인 척 연기한다. PX4의 하드웨어 추상화 계층(HAL) 코드들이 NuttX API 대신 리눅스의 POSIX API(예: pthreads)를 매핑하여 호출하게끔 스위칭된다.
2. 가짜 센서 및 모터 (Fake Hardware): 실제 IMU나 GPS 칩셋이 없으므로, PX4는 UDP 네트워크를 열어 JMAVSim, Gazebo 등과 같은 3D 물리 시뮬레이터 프로그램과 결탁한다. 시뮬레이터가 만들어낸 가짜 자이로(Gyro) 데이터가 네트워크를 타고 들어오면, PX4 펌웨어는 마치 실제 센서에서 데이터를 읽어 들인 것처럼 속아 넘어가 필터링과 제어를 수행한다.

2. 가장 안전한 ‘Hello World’ 실행기

SITL의 가장 큰 축복은 ’물리적인 안전함’뿐만이 아니다. 내장된 개발 환경(IDE) 덕분에 **로깅(Logging)과 디버깅(Debugging)**이 극도로 편해진다는 점이다.

실제 기체에 올려서 테스트할 때는 C++ 코드 안의 PX4_INFO("Hello %s", name) 문구를 터미널로 받아보거나, 비행 로깅 시스템(.ulg 파일)을 SD 카드로 빼내 확인하기가 여간 번거로운 것이 아니다. 메모리 크래시가 나면 그저 어디서 죽었는지 감과 기도벽에 의존해야 한다.

하지만 SITL 모드로 코드를 돌리게 되면:

1. 실시간 콘솔 덤프: PX4_INFO, PX4_ERR 계열의 매크로 로그가 가상 NSH 터미널 밑의 우분투 bash 터미널 창에 형형색색으로 실시간으로 찍힌다. 디버깅 프린트를 마음껏 찍어볼 수 있다.
2. 코어 덤프(Core Dump)와 GDB: 모듈이 널 포인터 참조로 뻗어버리면, 기체가 추락하는 대신 리눅스 OS가 친절하게 Segmentation fault (core dumped) 메시지를 띄워준다. 우리는 개발자용 GDB(GNU Debugger)를 붙여 정확히 어느 파일의 몇 번째 줄에서 크래시가 났는지 편안하게 추적할 수 있다.

그렇다면 구체적으로 make px4_sitl jmavsim 이라는 거창한 명령어를 쳤을 때, 내 리눅스의 CPU 스레드들이 как(어떻게) 픽스호크의 심장을 연기하는 걸까? 다음 단원(21.3.3.1)에서 메인 루프를 관통하는 구체적인 실행 컨텍스트(Execution Context)를 들여다보자.