### 0.0.1 드라이버 계층 차이: PX4의 독립 모듈(NuttX Task) 방식과 Ardupilot의 라이브러리(AP_RangeFinder, AP_OpticalFlow) 통합 방식 비교

거리 센서(Rangefinder)와 옵티컬 플로우(Optical Flow) 드라이버를 커널 계층에서 끌어올리는 방식은 두 비행 제어 스택의 뼈대를 가장 극명하게 보여준다.

Ardupilot의 라이브러리(Library) 통합 방식

Ardupilot의 소스 코드를 열어보면 libraries/AP_RangeFinder 및 AP_OpticalFlow 디렉터리에 각 하드웨어 제조사별 백엔드 드라이버(Backend C++ Class)들이 거대한 상속 트리 형태로 모여 있다.

• 동기식(Synchronous) 단일 루프 폴링: Ardupilot은 메인 스케줄러(Main Loop) 루틴 안에서 해당 센서 객체의 update() 메서드를 주기적으로 직접 호출한다. 센서 하나가 I2C 통신 중 타임아웃 지연(Hang/Timeout)에 걸리거나 스파이크 노이즈에 의해 드라이버가 교착 상태(Deadlock)에 빠지면, 메인 비행 제어 루프 전체가 위험한 지연(Latency)의 늪에 빠질 치명적 확률이 존재한다.
• 통신 오버헤드의 최소화: 반면, 메인 루프가 라이브러리를 직접 호출하므로 센서 데이터를 가져오기 위한 스레드 간 컨텍스트 스위칭(IPC)이나 메시지 큐 통달 비용이 제로(0)에 가깝다. 극한의 메모리 타이밍 효율성을 갖는다.

PX4-Autopilot의 독립 모듈(NuttX Task) 분산 방식

반대로 PX4는 철저하게 분산 통제 구역을 설정한다. 펌웨어 시작 시 스동 스크립트(rc.sensors)에 의해 각 센서 제조사의 드라이버(예: tfmini, px4flow)가 독립적인 배경 프로세스, 즉 NuttX OS의 고립된 Task(Thread) 로 start 명령어와 함께 실행된다.

• uORB 메시징 버스를 통한 비동기(Asynchronous) 소통: 독립 프로세스로 살아가는 센서 드라이버는 자체적인 work_queue 와 타이머에 의해서만 구동되며, 데이터를 긁어올 때마다 distance_sensor 와 optical_flow 라는 통일된 uORB 프로토콜 메시지로 바이트 스트림을 던져 놓고(Publish) 사라진다.
• 결함 격리(Fault Isolation) 생존성: 만약 특정 저가형 LiDAR 센서가 낙뢰나 전자파(EMI) 쇼트로 인해 뻗어버려 해당 드라이버 Task가 크래시(Crash)되더라도, PX4 생태계의 신경줄인 uORB 데이터 파이프만 응답을 멈출 뿐 비행을 관장하는 다른 핵심 메인 스케줄러 루프(px4io, ekf2, mc_pos_control)는 단 1ms 의 지연 손실 없이 멀쩡하게 돌아간다. 이는 항공 우주 분야의 모듈 이중화 격리 철학을 고스란히 이식한 것이다.
• 단점은 명확하다. 드라이버가 uORB 토픽을 Publish 하고, 수신기인 sensors 모듈이나 ekf2 가 Subscribe 하기까지 필연적인 IPC 지연 시간과 메모리 카피 오버헤드(Overhead)를 수반한다는 점이다.