### 0.0.1 PX4-Autopilot 및 Ardupilot의 GPS 소프트웨어 철학 비교

오픈소스 무인기 생태계를 양분하고 있는 PX4-Autopilot과 Ardupilot은 겉보기에는 비슷한 비행 성능을 제공하지만, 내부 소프트웨어 아키텍처를 들여다보면 설계 철학(Design Philosophy)의 근본적인 차이가 존재한다. 특히 외부 센서인 GPS 데이터를 취득하고, 파싱(Parsing)하고, 융합(Fusion)하여 제어 루프에 전달하기까지의 여정은 두 프레임워크가 추구하는 핵심 가치—**‘독립된 모듈 간의 느슨한 결합(Loosely Coupled)’**이냐, **‘단일체(Monolithic) 라이브러리의 강력한 통합’**이냐—를 극명하게 보여준다.

본 절에서는 GPS 소프트웨어 스택을 중심으로 두 오픈소스 진영의 뼈대가 어떻게 다르게 설계되어 있는지 비교 분석한다.

0.1 프로세스 격리 vs 단일 스레드 루프 (Process Isolation vs Monolithic Loop)

가장 눈에 띄는 차이점은 센서 드라이버를 운영체제 단에서 어떻게 취급하느냐에 있다.

PX4의 독립 모듈주의: PX4는 철저한 마이크로서비스(Microservices) 아키텍처를 지향한다. gps 드라이버 풀은 메인 제어 루프와 완전히 분리된 별도의 독립된 태스크(Task) 혹은 스레드(Thread)로 백그라운드에서 동작한다. GPS 드라이버가 파싱 중 예기치 못한 에러로 크래시(Crash)가 나더라도, 비행 제어기(Position Controller) 태스크는 전혀 영향을 받지 않고 계속 구동된다. 이는 유닉스(Unix)의 철학과 맞닿아 있다.
Ardupilot의 라이브러리 통합: 반면 Ardupilot은 전통적으로 거대한 단일 스케줄러 위에서 돌아가는 모놀리식(Monolithic) 성향이 강하다. AP_GPS 라는 백엔드 라이브러리를 통해 메인 비행 루프(Main Loop)의 스케줄러가 정해진 시간 주기로 GPS 포트를 폴링(Polling)하여 데이터를 긁어오는 방식이 주를 이룬다. 하드웨어 추상화(HAL) 레벨에서는 분리되어 있으나, 상위 로직에서는 스레드 격리성이 PX4만큼 엄격하지 않다.

0.2 IPC(Inter-Process Communication): uORB vs 객체 직접 참조

센서에서 읽어들인 데이터를 비행 알고리즘으로 어떻게 택배 배송할 것인가의 문제다.

PX4의 Pub/Sub 메신저 (uORB): 전술했듯 PX4는 uORB라는 강력한 비동기 메시지 버스(Asynchronous Message Bus) 시스템을 사용한다. GPS 드라이버는 그저 sensor_gps 토픽을 허공에 외치기만(Publish) 할 뿐, 누가 가져가는지 알 필요가 없다. EKF2 모듈은 이 메시지가 배달 오면 그제서야 깨어나(Wake-up) 구독(Subscribe)한다. 두 모듈은 서로의 메모리 주소조차 모르는 완벽한 블라인드 인터페이스(Blind Interface) 를 유지한다.
Ardupilot의 프론트엔드/백엔드 객체 참조: Ardupilot은 AP_GPS 프론트엔드 클래스가 여러 개의 백엔드 인스턴스(보드에 꽂힌 개별 GPS들)를 관리한다. 메인 제어 코드나 EKF3 필터는 이 AP_GPS 클래스의 퍼블릭(Public) 메서드(get_location(), get_velocity() 등)를 직접 호출하여 메모리 내의 변수 값을 읽어간다. 이는 C++ 객체 지향 프로그래밍(OOP)의 고전적인 방식으로, 직관적이고 호출 속도가 빠르지만 모듈 간 결합도(Coupling)는 높은 편이다.

0.3 센서 융합의 주체: 위치(Where)의 차이

다중 GPS 데이터의 블렌딩(Blending)과 스위칭(Switching) 로직이 소스 코드의 어느 계층에 위치하는가도 중요한 관전 포인트다.

PX4: EKF 내부(또는 센서 허브)로의 위임: PX4는 GPS 드라이버 계층에서는 아무런 데이터 가공이나 선택을 하지 않는다. 드라이버는 그저 들어온 데이터를 uORB로 쏘아 올릴 뿐이다. 두 개 이상의 GPS 데이터를 누가 더 신뢰할 것인지(가중 평균), 언제 버릴 것인지(스위칭)에 대한 고도의 판단은 모두 EKF2 라는 센서 융합 전문 모듈이 전담(Monopoly)한다.
Ardupilot: 센서 라이브러리(AP_GPS) 내의 1차 필터링: Ardupilot은 AP_GPS 라이브러리 프론트엔드 내부 자체적으로 블렌딩(GPS_TYPE=2) 및 오토 스위칭 로직이 탄탄하게 구현되어 있다. 즉, 하위 센서 드라이버 단에서 이미 ‘최적의 GPS(Primary)’ 하나를 선별하거나 두 데이터를 섞은 뒤, 깔끔하게 정리된 하나의 정답만을 EKF3로 올려보내는 방식을 선호한다.

요약하자면, PX4는 센서를 단순한 바보(Dumb) 데이터 공급자로 취급하고 중앙의 EKF에게 과부하에 가까운 막강한 권력을 몰아주는 형태라면, Ardupilot은 각 센서 라이브러리가 어느 정도 스마트(Smart)한 1차 판단을 내린 뒤 필터에게 잘 정제된 요리 재료를 넘겨주는 형태라 할 수 있다. 어느 아키텍처가 더 우월하다기보다는, 코드의 유지보수성과 실시간성(Real-time)을 철학적으로 어떻게 해석하느냐의 유서 깊은 논쟁의 산물이다.