PX4는 소비자용 드론부터 산업 및 연구 플랫폼에 이르기까지 광범위한 응용 분야를 위해 설계된 전문가 수준의 오픈소스 오토파일럿 소프트웨어입니다. PX4의 핵심 아키텍처는 고도의 모듈성 및 확장성, POSIX 호환 API를 통한 이식성, 그리고 견고성과 성능의 기반이 되는 반응형 비동기 설계를 특징으로 합니다. 본 보고서는 PX4의 구조를 심층적으로 분석하여 개발자, 시스템 통합자 및 연구자에게 기초적인 기술 참조 자료를 제공하는 것을 목표로 합니다. PX4의 구조는 크게 두 가지 핵심 요소로 나뉩니다. 첫째는 운영체제 추상화, 드라이버, 그리고 uORB 통신 버스를 책임지는 기반 계층인 미들웨어(Middleware)이며, 둘째는 추정기, 제어기, 항법 로직을 포함하는 지능 계층인 비행 스택(Flight Stack)입니다. 본 보고서는 시스템의 각 구성 요소와 그 상호작용을 해체하여 PX4의 강력함과 유연성을 가능하게 하는 설계 철학을 명확히 밝힐 것입니다.
이 장에서는 PX4 구조의 다른 모든 측면에 영향을 미치는 근본적인 설계 철학을 확립합니다. 이는 단순히 구성 요소를 나열하는 것을 넘어, 시스템이 왜 이런 방식으로 구축되었는지를 분석합니다.
PX4의 주요 아키텍처 구분은 시스템을 미들웨어(Middleware)와 비행 스택(Flight Stack)이라는 두 개의 뚜렷한 계층으로 나누는 것입니다. 이러한 분리는 PX4의 적응성을 뒷받침하는 초석입니다.
미들웨어는 범용 로보틱스 계층입니다. 그 책임은 비행에 국한되지 않으며, 모든 자율 로봇의 기반이 됩니다. 여기에는 장치 드라이버, 내부/외부 통신 프로토콜, 그리고 운영체제 추상화 계층이 포함됩니다. 미들웨어는 비행 로직이 구축될 안정적이고 하드웨어에 구애받지 않는 플랫폼을 제공합니다.
반면, 비행 스택은 유도, 항법, 제어(GNC, Guidance, Navigation, and Control) 알고리즘의 특화된 집합입니다. 여기에는 멀티콥터, 고정익, 수직이착륙기(VTOL) 등 다양한 기체 유형을 위한 “항공 지능”이 포함되어 있습니다. 상태 추정 및 제어 법칙이 구현되는 곳이 바로 이 계층입니다.
이러한 두 계층의 분리는 단순한 조직적 편의를 넘어선 심오한 전략적 결정입니다. 일반적인 로보틱스 기능(미들웨어)과 기체별 비행 로직(비행 스택)을 엄격하게 분리함으로써 PX4는 비할 데 없는 유연성을 확보합니다. 예를 들어, 개발자는 센서 드라이버나 MAVLink 통신 모듈(미들웨어의 일부)의 코드를 단 한 줄도 변경하지 않고 비행 스택에 있는 멀티콥터 자세 제어기를 완전히 교체할 수 있습니다. 반대로, 하드웨어 제조업체는 미들웨어 내에 새로운 드라이버를 구현하여 새로운 비행 컨트롤러 보드에 PX4를 이식할 수 있으며, 이 과정에서 성숙하고 비행 테스트를 거친 전체 GNC 알고리즘 제품군을 즉시 활용할 수 있습니다. 이 전략적 분리는 PX4가 다양한 하드웨어를 폭넓게 지원하고, 로버나 보트와 같은 비항공 기체에도 적용될 수 있는 핵심적인 원동력입니다. 이는 최고 수준의 아키텍처에서 “관심사 분리(separation of concerns)” 원칙을 구현한 것입니다.
전체 시스템은 반응형(reactive)으로 설계되었으며, 이는 이벤트 기반으로 작동하고 새로운 데이터가 사용 가능해지면 즉시 업데이트된다는 것을 의미합니다. 이는 동기식, 순차적 처리 모델과는 대조적입니다.
모든 기능은 독립적인 프로그램이나 스레드인 자급자족형, 교체 가능한 모듈로 분할됩니다. 이것이 바로 모듈성의 본질이며, 컴포넌트를 개별적으로 개발, 테스트 및 교체할 수 있게 합니다. 이러한 모듈 간의 통신은 uORB 버스를 통한 비동기 메시지 전달(asynchronous message passing)을 통해서만 처리됩니다(3장에서 자세히 설명). 이 비동기성은 우선순위가 높은 작업이 낮은 우선순위의 작업에 의해 차단되는 것을 방지하므로 실시간 시스템에 매우 중요합니다.
이 아키텍처는 시스템이 다양한 작업 부하를 원활하게 처리할 수 있게 하며, 심지어 런타임에 모듈을 교체하거나 재시작하는 것까지 허용합니다.
이러한 기술적 설계 철학을 가능하게 하는 중요한 비기술적 요소는 바로 허용적인 BSD 3-clause 라이선스입니다. 이 라이선스는 상업적 참여를 장려하는 전략적 선택입니다. “교체 및 재사용 가능한 컴포넌트”에 대한 문서의 강조점은 “레고 블록” 설계 철학을 시사합니다. 허용적인 BSD 라이선스는 이러한 기술적 설계를 실행 가능한 상업적 생태계로 전환시키는 중요한 촉매제 역할을 합니다. 기업은 오픈소스 PX4 코어 시스템(“베이스 플레이트”와 표준 “블록”)을 기반으로 자체적인 고부가가치 독점 “특수 블록”(예: 맞춤형 컴퓨터 비전 모듈, 고급 임무 계획 알고리즘)을 개발할 수 있습니다. 그런 다음 통합된 제품을 판매하면서도 독점 컴포넌트의 소스 코드를 공개할 법적 의무가 없습니다. 이는 강력한 비즈니스 모델이며, 카피레프트(GPL) 라이선스를 사용하는 ArduPilot과 같은 프로젝트와의 근본적인 차별점입니다. 모듈식 아키텍처와 허용적 라이선스 간의 이러한 시너지는 상업적 R&D와 산업 채택을 직접적으로 촉진하며, PX4를 단순한 완제품이 아닌 유연한 플랫폼으로 자리매김하게 합니다.
PX4는 효율성을 위해 단일 공유 메모리 주소 공간 내에서 실행되는 모듈을 위해 두 가지 뚜렷한 실행 컨텍스트를 제공합니다.
두 가지 실행 모델의 존재는 임의적인 것이 아니라, 성능과 리소스 소비 사이의 고전적인 임베디드 시스템 트레이드오프에 대한 신중하게 고려된 해결책입니다. PX4의 수백 개 모듈 각각에 대해 전용 스택을 가진 태스크를 생성하는 것은 일반적인 마이크로컨트롤러의 RAM 측면에서 엄청나게 비효율적일 것입니다. 작업 큐 모델은 우아하고 메모리 효율적인 타협안입니다. 이는 수십 개의 작고 덜 자주 실행되는 모듈을 단일 작업자 스레드에 의해 직렬로 “큐에 넣고” 실행되도록 하여, 스택을 공유하고 메모리 오버헤드를 최소화합니다. 따라서 시스템 설계자는 가장 중요한 컴포넌트(추정기 및 제어기와 같은)에 대해서는 리소스 집약적인 “태스크” 모델을 신중하게 사용하고, 나머지 대다수의 기능은 작업 큐에 위임할 수 있습니다. 이 이중 계층 시스템은 모듈성의 필요성과 제한된 하드웨어의 현실 사이에서 균형을 맞추는, 임베디드 리소스 관리에 대한 깊고 실용적인 이해를 보여줍니다.
이 장에서는 PX4를 이식 가능하고 하드웨어에 구애받지 않게 만드는 기반 계층을 상세히 설명하며, POSIX 표준의 전략적 사용에 초점을 맞춥니다.
PX4의 핵심 설계 요구사항은 POSIX 호환 애플리케이션 프로그래밍 인터페이스(API)와 실시간 스케줄링(예: FIFO)의 한 형태를 제공하는 호스트 운영체제입니다. 이것이 이식성을 위한 가장 중요한 단일 결정입니다.
이를 통해 PX4는 다음과 같은 다양한 운영체제에서 실행될 수 있습니다.
이 POSIX 계층은 시스템의 주요 하드웨어 추상화 계층(HAL) 역할을 합니다. 이는 커널, 타이머, 장치 I/O의 저수준 세부 사항을 추상화합니다. 궁극적인 이점은 비행 스택의 동일한 고수준 애플리케이션 코드를 시뮬레이션을 위해 강력한 Linux 데스크톱에서 컴파일 및 실행한 다음, 기능적 변경 없이 리소스가 제한된 비행 컨트롤러에 배포할 수 있다는 것입니다.
PX4가 단지 HAL을 가지고 있는 것이 아니라, 그 HAL이 바로 POSIX 표준이라는 점은 심오한 아키텍처적 선택입니다. 독점적이고 도메인에 특화된 하드웨어 API를 발명하는 대신, 프로젝트 창립자들은 안정적이고 잘 문서화된 산업 표준 인터페이스를 활용했습니다. 이 결정은 엄청난 긍정적 파급 효과를 낳았습니다. 첫째, 이미 Unix/Linux 프로그래밍 패러다임에 익숙한 거대한 개발자 커뮤니티에 프로젝트를 즉시 접근 가능하게 만들었습니다. 둘째, 표준화되고 고도로 최적화된 C/C++ 컴파일러 및 개발 도구(예: GDB)를 최소한의 수정으로 사용할 수 있게 했습니다. 셋째, 견고한 테스트와 시뮬레이션에 매우 귀중한 “한 번 작성하면 어디서든 실행되는(write once, run anywhere)” 패러다임을 가능하게 했습니다. 넷째, 다른 핵심 구성 요소의 설계를 결정했습니다. 드라이버 모델이 가상 파일 시스템의 문자 장치로 나타나고, uORB 메시징 시스템이 파일 I/O를 모방하는 것은 모두 POSIX 모델을 준수한 직접적인 결과입니다. POSIX의 사용은 사소한 구현 세부 사항이 아니라, PX4의 전체적이고 유연하며 이식 가능한 구조가 기반을 둔 중심 기둥입니다.
Pixhawk 시리즈와 같은 대다수의 전용 비행 컨트롤러에서 PX4는 NuttX RTOS 위에서 실행됩니다. NuttX는 엄격한 POSIX 호환성, 작은 메모리 풋프린트, 실시간 스케줄링 기능으로 인해 임베디드 애플리케이션에 이상적인 운영체제로 선택되었습니다.
PX4는 하드웨어 주변 장치가 가상 파일 시스템 내의 문자 장치(character devices)(예: /dev/spi1, /dev/ttyS2)로 시스템에 노출되는 표준 NuttX 드라이버 모델을 활용합니다. 이를 통해 애플리케이션은 open(), close(), read(), write(), ioctl()과 같은 표준 POSIX 파일 연산을 사용하여 하드웨어와 상호 작용할 수 있습니다. 일반적인 PX4 드라이버는 NuttX 셸(NSH)에서 시작할 수 있는 모듈로 구조화되어 있으며, 해당 문자 장치를 등록합니다.
실시간 성능을 유지하기 위해, 장시간 실행되는 코드는 절대로 인터럽트 서비스 루틴(ISR) 내에서 직접 실행되지 않습니다. PX4는 NuttX가 제공하는 “상위 절반(Top Half)” / “하위 절반(Bottom Half)” 인터럽트 처리 모델을 엄격하게 준수합니다. “상위 절반”(실제 ISR)은 하드웨어 레지스터에서 값을 읽는 것과 같은 최소한의 작업을 수행한 다음, 지연된 처리를 위해 “하위 절반”을 스케줄링합니다.
이 스케줄링은 NuttX 작업 큐(Work Queues)를 사용하여 수행됩니다. ISR은 전용 고우선순위 작업 큐(HPWORK)에 작업 항목을 배치합니다. 그러면 별도의 고우선순위 작업자 스레드가 스케줄러에 의해 선점될 수 있는 일반 스레드 컨텍스트에서 드라이버의 주요 로직(“하위 절반”)을 실행합니다. 이것이 고주파 센서 드라이버가 시스템 안정성을 저해하지 않고 작동할 수 있게 하는 근본적인 메커니즘입니다.
PX4는 단순히 NuttX 위에서 실행되는 애플리케이션이 아니라, 두 시스템이 깊고 공생적으로 얽혀 있습니다. PX4의 고수준 아키텍처는 NuttX 커널의 고유한 기능을 활용하도록 특별히 설계되었습니다. NuttX의 POSIX 호환 문자 드라이버 모델은 PX4 모듈이 일관된 파일 기반 API를 사용하여 하드웨어와 상호 작용할 수 있게 하는 핵심입니다. NuttX 작업 큐는 PX4의 전체 비동기식, 비차단 드라이버 아키텍처를 가능하게 하는 필수 메커니즘입니다. 더욱이, PX4의 uORB 메시징 시스템은 NuttX 가상 파일 시스템을 직접적이고 영리하게 사용하여 /obj/ 아래에 문자 장치 집합으로 구현됩니다. NuttX를 비-POSIX RTOS로 간단히 교체하는 것은 PX4 미들웨어의 근본적이고 대대적인 재설계 없이는 불가능할 것입니다. 이는 단순한 계층화가 아닌 공진화적 관계를 보여줍니다.
이 장에서는 PX4의 모듈식 아키텍처가 하나의 응집력 있는 전체로 기능하게 하는 핵심적인 내부 통신 버스를 해부합니다.
uORB(micro Object Request Broker)는 모든 스레드 간 및 프로세스 간 통신에 사용되는 PX4의 내부 비동기 발행-구독(publish-subscribe) 메시징 API입니다.1
이 모델은 데이터 생산자와 소비자를 완전히 분리합니다. IMU 드라이버는 누가 사용할지 전혀 모르는 상태에서 sensor_gyro 데이터를 발행합니다. 자세 제어기는 어떤 특정 드라이버가 데이터를 생성했는지 전혀 모르는 상태에서 sensor_gyro를 구독합니다. 이것이 시스템 모듈성의 기본입니다.
uORB는 프로세스 간에 비용이 많이 드는 데이터 복사를 피하므로 매우 효율적인 공유 메모리 모델을 기반으로 합니다.
핵심 구현 세부 사항으로, NuttX에서 uORB 토픽은 가상 파일 시스템의 /obj/ 디렉토리에 있는 가상 장치 노드(문자 장치)로 표현됩니다. 토픽 핸들은 사실상 가상 파일입니다. 이를 통해 모듈은 read(), write(), ioctl()과 같은 표준 POSIX 파일 연산을 사용하여 토픽과 상호 작용할 수 있습니다. 결정적으로, 구독자는 poll()을 사용하여 네트워크 소켓이나 직렬 포트와 마찬가지로 여러 토픽(및 실제 장치 드라이버)을 동시에 대기할 수 있습니다.
메시지 데이터 구조는 msg/ 디렉토리에 있는 간단한 .msg 파일에 정의됩니다. 이 파일들은 빌드 시스템에 의해 필요한 C/C++ 헤더 파일과 직렬화 코드를 자동으로 생성하는 데 사용됩니다. 모든 .msg 정의에는 uint64_t timestamp 필드가 필수로 포함되어야 하며, 이는 로거와 EKF2에서의 시간 동기화 데이터 융합에 매우 중요합니다.
새로운 토픽을 추가하는 과정은 간단합니다: 1) .msg 파일을 생성합니다. 2) msg/CMakeLists.txt에 파일을 추가합니다. 3) C++ 코드에서 orb_advertise() 및 orb_subscribe() API를 사용합니다.1
파일 기반 구현은 비할 데 없는 디버깅 기능을 제공합니다. 개발자는 MAVLink 원격 측정 링크를 통해서도 시스템의 셸(NSH)에 연결하여 간단한 명령줄 도구를 사용하여 실시간 데이터 흐름을 검사할 수 있습니다.
ls /obj: 현재 광고된 모든 uORB 토픽을 나열합니다.listener <topic_name> [count]: 특정 토픽에 게시되는 메시지의 내용을 실시간으로 덤프합니다.uorb top: 모든 토픽의 동적인 top과 유사한 뷰를 제공하여 게시 빈도, 구독자 수 및 큐 크기를 보여줍니다.uORB를 POSIX API 위에 파일과 유사한 노드를 사용하여 구현하기로 한 결정은 개발자 중심 설계의 걸작입니다. 이는 “IPC 메시지”라는 추상적인 소프트웨어 엔지니어링 개념을 표준적이고 익숙한 명령줄 도구를 사용하여 나열하고, 읽고, 모니터링할 수 있는 구체적인 실체로 변환합니다. 이는 시스템의 내부 데이터 흐름이 투명하고 자체 문서화된다는 심오한 의미를 가집니다. 제어 루프를 이해하려는 새로운 개발자는 복잡한 코드 경로를 추적할 필요 없이, 단순히 uorb top을 실행하여 중요한 데이터 스트림, 그 빈도, 소비자에 대한 실시간 “지도”를 얻을 수 있습니다. 이는 디버깅 및 시스템 분석에 대한 인지적 부담을 극적으로 줄여줍니다. 이것은 파일 시스템 호출 계층에서 발생하는 미미한 성능 저하를 감수하는 대신, 시스템 관찰 가능성, 디버깅 용이성 및 개발자 생산성에서 막대한 이득을 얻기 위한 의도적인 아키텍처적 트레이드오프입니다.
이 장에서는 기반이 되는 미들웨어에서 벗어나 비행에 특화된 알고리즘으로 이동하여, 이들이 어떻게 구조화되고 uORB를 통해 상호 작용하는지 분석합니다.
비행 스택은 함께 작동하는 세 가지 주요 논리 블록으로 구성됩니다:
sensor_gyro, sensor_accel, vehicle_gps_position)의 원시 센서 데이터를 융합하여 기체의 상태에 대한 견고하고 일관된 추정치를 생성합니다. 그 출력은 vehicle_odometry 및 vehicle_attitude와 같은 토픽에 게시됩니다.trajectory_setpoint 토픽에 게시됩니다.trajectory_setpoint를 실제 모터 및 서보 명령으로 변환하는 모듈 집합입니다. 이는 계단식 제어 구조를 통해 달성됩니다.PX4는 특히 멀티콥터에 대해 고전적인 계단식 제어 아키텍처(cascaded control architecture)를 사용합니다. 이것은 외부의 느린 루프의 출력이 내부의 빠른 루프의 입력 설정값으로 사용되는 중첩된 루프의 연속입니다. 이 구조는 uORB를 통해 통신하는 독립적인 모듈 체인으로 구현됩니다.
mc_pos_control 모듈은 trajectory_setpoint와 vehicle_odometry를 구독합니다. 원하는 위치를 추정된 위치와 비교하고 간격을 좁히는 데 필요한 목표 속도를 계산합니다. 이 목표 속도는 다음 루프의 입력이 됩니다.mc_pos_control 내)는 목표 속도를 추정된 속도와 비교합니다. 그 출력은 목표 가속도입니다. 이 가속도는 목표 자세(기울기 각도)와 집합적인 추력 값으로 변환됩니다. 이들은 vehicle_attitude_setpoint uORB 토픽에 게시됩니다.mc_att_control 모듈은 vehicle_attitude_setpoint와 vehicle_odometry를 구독합니다. 목표 자세 쿼터니언을 추정된 자세와 비교하고 이를 달성하는 데 필요한 각속도를 계산합니다. 이 목표 각속도는 vehicle_rates_setpoint 토픽에 게시됩니다.mc_att_control 내)가 가장 빠릅니다. vehicle_rates_setpoint의 목표 각속도를 vehicle_angular_velocity의 추정된 각속도와 비교하고 최종 수정 토크를 계산합니다. 이 토크는 개별 모터 명령(예: PWM 값)으로 변환하여 actuator_outputs 토픽에 게시하는 믹서(Mixer)로 전달됩니다.계단식 루프는 표준 제어 시스템 패턴이지만, PX4에서의 구현 방식이 아키텍처적으로 우아하게 만듭니다. 계단의 각 단계는 다음 단계와 uORB 토픽을 통해서만 통신하는 논리적으로 분리된 모듈(또는 모듈 내 함수)입니다. 이는 명확한 “책임의 연쇄”를 만듭니다. 위치 제어기의 유일한 임무는 속도를 명령하는 것이며, 쿼터니언이나 모터에 대한 지식은 없습니다. 자세 제어기의 유일한 임무는 쿼터니언을 추적하는 것이며, GPS나 웨이포인트에는 관심이 없습니다. 이러한 uORB 매개 분리는 개별 제어 루프를 부작용 없이 독립적으로 조정, 테스트 또는 완전히 교체할 수 있게 합니다. 연구자는 새로운 비선형 자세 제어기를 개발하고, 자신의 새 모듈이 vehicle_attitude_setpoint를 올바르게 구독하고 vehicle_rates_setpoint에 게시하도록 보장함으로써 간단히 통합할 수 있습니다. 이것은 모듈식 철학이 실제로 작동하는 강력한 시연입니다.
| 루프 단계 (Loop Stage) | 주 모듈 (Primary Module) | 주요 입력 uORB 토픽 (Key Input uORB Topic(s)) | 주요 출력 uORB 토픽 (Key Output uORB Topic) |
|---|---|---|---|
| 위치 제어 (Position Control) | mc_pos_control |
trajectory_setpoint, vehicle_odometry |
(내부적으로 속도 설정값 생성) |
| 속도 제어 (Velocity Control) | mc_pos_control |
(내부 속도 설정값), vehicle_odometry |
vehicle_attitude_setpoint |
| 자세 제어 (Attitude Control) | mc_att_control |
vehicle_attitude_setpoint, vehicle_odometry |
vehicle_rates_setpoint |
| 각속도 제어 (Rate Control) | mc_att_control |
vehicle_rates_setpoint, vehicle_angular_velocity |
actuator_controls |
| 작동 (Actuation) | Mixer / Actuators | actuator_controls |
actuator_outputs |
추정 및 제어 라이브러리(ECL, Estimation and Control Library)와 그 주요 알고리즘인 확장 칼만 필터(EKF2, Extended Kalman Filter)는 PX4의 기본이자 권장되는 상태 추정기입니다. 이는 주로 Paul Riseborough에 의해 개발된 매우 복잡하고 견고한 시스템입니다.
EKF2는 기체의 상태를 포괄적으로 설명하는 24개 상태 벡터를 추정합니다.
| 상태 인덱스 | 설명 | 단위 |
|---|---|---|
| 0-3 | 자세 쿼터니언 (NED에서 Body 프레임으로의 회전) | - |
| 4-6 | 속도 (북, 동, 하) | m/s |
| 7-9 | 위치 (북, 동, 하) | m |
| 10-12 | 자이로스코프 바이어스 (X, Y, Z) | rad/s |
| 13-15 | 가속도계 바이어스 (X, Y, Z) | m/s² |
| 16-18 | 지구 자기장 (북, 동, 하) | Gauss |
| 19-21 | 기체 프레임 자기장 바이어스 (X, Y, Z) | Gauss |
| 22-23 | 바람 속도 (북, 동) | m/s |
표의 내용은 S96, S120, S124를 기반으로 구성되었습니다.
EKF2_AID_MASK 파라미터는 개발자가 GPS, 비전 위치, 비전 요(yaw), 광학 흐름과 같은 특정 보조 소스의 융합을 활성화 또는 비활성화할 수 있게 하는 마스터 제어 스위치 역할을 하는 비트마스크입니다. 이를 통해 EKF를 GPS가 없는 실내 비행과 같은 다양한 운영 환경에 맞게 조정할 수 있습니다.견고성을 보장하기 위한 EKF2의 가장 강력한 기능 중 하나는 여러 EKF 인스턴스를 병렬로 실행하는 능력입니다. 이는 EKF2_MULTI_IMU 및 EKF2_MULTI_MAG 파라미터를 통해 구성됩니다. 예를 들어, EKF2_MULTI_IMU = 3으로 설정하면 보드에 있는 서로 다른 물리적 IMU 센서를 각각 사용하는 세 개의 완전한 EKF 필터가 인스턴스화됩니다.
별도의 “EKF 선택기” 로직이 각 EKF 인스턴스의 상태와 일관성(이노베이션 검사를 통해)을 지속적으로 모니터링합니다. 한 인스턴스가 크게 발산하기 시작하면(센서 결함 가능성을 나타냄), 선택기는 주 상태 추정치를 더 건강한 인스턴스로 원활하게 전환하여 비행 중 높은 수준의 센서 결함 허용성을 제공합니다.
EKF2의 내부 아키텍처는 전체 PX4 프로젝트의 설계 철학을 완벽하게 축소한 것입니다. 첫째, GPS, 비전, 바로미터와 같은 다양한 센서 융합 소스는 EKF2_AID_MASK와 같은 파라미터를 통해 동적으로 활성화 또는 비활성화할 수 있는 모듈식 컴포넌트로 취급되며, 이는 PX4 모듈이 Kconfig에 의해 관리되는 방식을 반영합니다. 둘째, FIFO 버퍼를 사용한 “지연된 융합 시간 지평”은 uORB의 비동기 메시지 전달 특성과 직접적으로 유사합니다. 이는 서로 다른 속도와 지연 시간으로 도착하는 데이터 소스를 처리하도록 처음부터 설계되었습니다. 셋째, 다중 인스턴스 기능은 안전과 견고성에 대한 시스템의 초점을 궁극적으로 표현합니다. 이는 센서가 작동한다고 가정하는 것이 아니라, 센서의 고장을 견딜 수 있도록 설계되었습니다. EKF2는 단순한 필터가 아니라, 모듈성, 비동기성, 견고성이라는 핵심 PX4 원칙을 구현하는 자체 모니터링, 결함 허용 추정 시스템입니다.
이 장에서는 자급자족적인 PX4 시스템이 지상국 및 동반 컴퓨터를 포함한 외부 세계와 어떻게 통신하는지 설명합니다.
MAVLink는 비행 컨트롤러 외부의 모든 통신을 위한 사실상의 표준이자 경량 메시징 프로토콜입니다.2
이는 몇 가지 핵심 개념을 기반으로 합니다:
HEARTBEAT, ATTITUDE). 저대역폭 무선 링크를 통한 사용을 위해 경량으로 설계되었습니다.COMMAND_LONG을 사용하고 수신 및 실행을 보장하기 위해 COMMAND_ACK를 기다리는 명령 프로토콜(Command Protocol)입니다.common.xml 다이얼렉트를 사용합니다.mavlink 모듈은 내부 uORB 메시지 버스와 외부 MAVLink 프로토콜 간의 양방향 브리지 역할을 하는 중요한 소프트웨어 컴포넌트입니다.
mavlink 모듈은 내부 uORB 토픽 목록(예: vehicle_attitude, battery_status)을 구독합니다. 새로운 uORB 메시지가 수신되면 데이터를 해당 MAVLink 메시지 형식으로 직렬화하여 구성된 직렬 또는 UDP 링크를 통해 전송합니다. 이러한 나가는 데이터 피드는 “스트림(streams)”으로 알려져 있습니다.MavlinkReceiver 스레드는 들어오는 MAVLink 데이터를 수신 대기합니다. MAVLink 메시지(예: SET_MODE 명령 또는 동반 컴퓨터의 VISION_POSITION_ESTIMATE 메시지)가 수신되면 구문 분석되고 데이터는 다른 PX4 모듈이 소비하고 조치를 취할 수 있도록 적절한 내부 uORB 토픽(예: vehicle_command 또는 vehicle_visual_odometry)에 게시됩니다.PX4는 여러 개의 독립적인 통신 채널을 동시에 관리하기 위해 추상적인 MAVLink 인스턴스(일반적으로 0, 1, 2) 개념을 사용합니다. 사용자는 MAV_0_CONFIG = TELEM1과 같은 파라미터를 사용하여 MAVLink 인스턴스를 물리적 직렬 포트에 할당합니다.
그런 다음 해당 채널의 동작은 해당 인스턴스 파라미터를 사용하여 구성됩니다:
MAV_0_MODE: 특정 사용 사례(예: GCS, 동반 컴퓨터용 Onboard, OSD, Gimbal)에 대한 기본 스트림 및 속도 집합을 설정합니다.MAV_0_RATE: 링크 포화를 피하기 위해 최대 데이터 속도를 B/s 단위로 설정합니다.MAV_0_FORWARD: 이 인스턴스에서 수신된 MAVLink 패킷을 다른 인스턴스로 전달하도록 활성화하여 GCS가 비행 컨트롤러를 “통해” 다른 포트의 주변 장치와 통신할 수 있도록 합니다.mavlink 모듈은 단순한 데이터 변환기 이상입니다. 이는 차량 안팎으로의 정보 흐름을 정밀하게 제어하는 정교하고 구성 가능한 게이트웨이 역할을 합니다. “스트림”과 “모드”의 개념은 핵심 제어 메커니즘입니다. 모드를 선택함으로써 개발자는 어떤 내부 uORB 토픽이 외부 세계에 어떤 빈도로 노출될지를 결정하는 사전 정의된 “방화벽 규칙 집합”을 선택하는 것입니다. 이는 대역폭이 제한된 원격 측정 링크에서 대역폭을 관리하는 데 매우 중요합니다. 이 모듈은 고주파, 고대역폭의 내부 uORB 버스를 잠재적으로 더 느리고 신뢰성이 낮은 외부 통신 링크로부터 효과적으로 격리합니다. 이는 트래픽 셰이퍼이자 보안 게이트웨이 역할을 하여, 차량의 핵심 운영이 외부 통신 문제로 인해 중단되지 않도록 보장합니다.
이 장에서는 개발자가 PX4 소스 코드를 컴파일하고 특정 하드웨어 및 애플리케이션에 맞게 조정할 수 있는 툴체인과 프로세스를 탐구합니다.
PX4는 기본적으로 크로스 플랫폼 빌드 시스템 생성기로 CMake를 사용하며, 일반적인 작업을 위해 사용자 친화적인 Make 명령어 래퍼를 제공합니다. 개발자는 일반적으로 make px4_fmu-v5_default와 같은 간단한 make 명령을 호출합니다.
이 make 타겟은 올바른 툴체인과 보드별 정의 파일로 더 복잡한 cmake 프로세스를 구성하고 실행하는 약어이며, 그 뒤에 Ninja나 Make와 같은 백엔드를 사용한 실제 컴파일이 이어집니다. 빌드 타겟은 VENDOR_MODEL_VARIANT라는 표준화된 명명 규칙을 따릅니다(예: px4_fmu-v5_default 또는 holybro_pixhawk6c_default).
PX4는 Linux 커널의 강력한 구성 시스템인 Kconfig를 활용하여 특정 펌웨어 빌드에 어떤 소프트웨어 컴포넌트(모듈, 드라이버, 라이브러리)가 포함될지 관리합니다.
구성 옵션(Kconfig 언어에서는 종종 “심볼”이라고 함, 예: DRIVERS_UAVCAN_V1)은 소스 트리 전체에 분산된 Kconfig 파일에 유형, 종속성 및 도움말 텍스트와 함께 정의됩니다. 특정 보드의 기본 구성은 .px4board 파일(예: boards/px4/fmu-v5/default.px4board)에 정의됩니다. 이 파일은 본질적으로 해당 빌드에 대해 활성화(y) 또는 비활성화(n)되도록 설정된 Kconfig 심볼 목록입니다.
개발자는 make <target> boardconfig(텍스트 기반) 또는 make <target> boardguiconfig(GUI 기반)를 실행하여 메뉴 기반 인터페이스를 통해 이 구성을 대화식으로 수정할 수 있습니다. 이러한 도구는 종종 menuconfig라고 통칭됩니다.
CMake와 Kconfig의 조합은 펌웨어의 “유전 공학”이라고 할 수 있는 매우 정교한 시스템을 제공합니다. Kconfig는 PX4 코드베이스에서 사용 가능한 모든 기능, 모듈 및 드라이버의 전체 “유전자 풀”을 정의합니다. 보드별 .px4board 파일은 특정 하드웨어 타겟의 “게놈” 역할을 하여 이러한 “유전자” 중 어느 것이 발현될지(즉, 컴파일되어 최종 바이너리에 포함될지) 지정합니다. menuconfig 도구는 “유전자 편집기” 역할을 하여 개발자가 기능을 활성화하거나 비활성화하여 사용자 정의 변형을 쉽게 만들 수 있도록 합니다. 이 시스템은 수백 개의 드라이버와 모듈을 지원하는 프로젝트의 엄청난 복잡성을 관리하는 핵심입니다. 이를 통해 PX4는 불필요한 기능을 비활성화하여 리소스가 제한된 보드를 위한 고도로 최적화된 경량 펌웨어를 생산하는 동시에, 강력한 보드를 위한 기능이 풍부한 펌웨어를 구축할 수 있으며, 이 모든 것이 단일 통합 소스 코드 저장소에서 가능합니다.
보드 지원 패키지(BSP, Board Support Package)는 boards/VENDOR/MODEL/ 디렉토리에 위치하며, 특정 하드웨어 타겟을 지원하는 데 필요한 모든 파일의 모음입니다.
완전한 BSP에는 다음이 포함됩니다:
nuttx-config/): MCU 핀 매핑 및 클럭 설정을 위한 board.h와 NuttX OS 수준 기능 선택을 위한 defconfig를 포함합니다.src/): PX4 수준 하드웨어 정의를 위한 board_config.h를 포함합니다.default.px4board 파일.init/): 보드별 초기화 스크립트.시스템 시작은 일련의 NSH 셸 스크립트에 의해 조정됩니다. 주 진입점은 부팅 시 실행되는 init.d/rcS입니다. rcS는 rc.sensors를 포함한 다양한 다른 스크립트를 호출합니다. 이 스크립트는 핵심 센서 드라이버를 시작하는 역할을 합니다. 공통 주변 장치를 위한 일반적인 ROMFS/px4fmu_common/init.d/rc.sensors가 있으며, 특정 하드웨어에 존재하는 특정 IMU, 기압계, 자력계 세트를 시작하는 boards/px4/fmu-v5/init/rc.board_sensors와 같은 보드별 재정의 스크립트가 있습니다.
이 마지막 장에서는 PX4의 아키텍처를 드론 생태계의 더 넓은 맥락에 위치시키고, 주요 대안과 비교하며 Dronecode 재단 내에서의 위치를 설명합니다.
이 섹션에서는 두 가지 주요 오픈소스 오토파일럿을 비판적으로 비교하며, 서로 다른 설계 철학이 아키텍처에 어떻게 나타나는지에 초점을 맞춥니다.
수집된 연구는 두 프로젝트 간의 근본적인 철학적 차이를 보여줍니다. PX4는 프레임워크로 설계되었습니다. 견고하고 잘 정의된 구조(POSIX, uORB, 모듈)와 도구 세트를 제공하지만, 개발자나 연구자가 그 위에 특정하고 맞춤화된 솔루션을 구축할 것을 기대합니다. 가장 큰 강점은 유연성, 이식성, 그리고 깨끗한 디자인입니다. ArduPilot은 성숙한 애플리케이션처럼 설계되었습니다. 방대하고 비행 검증된 기능 세트와 일반적인 기체 유형에 대한 고도로 최적화된 성능을 제공합니다. 가장 큰 강점은 기능의 깊이와 즉시 사용 가능한 비행 성능입니다. 이것은 어느 것이 “더 낫다”는 문제가 아니라, 대상 고객과 목표의 명확한 차이입니다. PX4의 BSD 라이선스와 프레임워크와 같은 아키텍처는 유연하고 깨끗한 플랫폼을 기반으로 구축해야 하는 상업 회사, 스타트업 및 학술 연구자에게 매력적입니다. ArduPilot의 GPL 라이선스와 애플리케이션과 같은 성숙도는 표준 기체 유형에 대해 절대적으로 최고의 비행 성능을 원하고 그 크고 활동적인 사용자 커뮤니티를 가치 있게 여기는 취미 사용자 및 운영자에게 매력적입니다.
| 아키텍처 측면 | PX4 | ArduPilot |
|---|---|---|
| 핵심 철학 | 모듈식, 이식 가능한 로보틱스 프레임워크. 맞춤형 솔루션을 위한 “툴킷”. | 성숙하고 기능이 풍부하며 고성능인 오토파일럿 애플리케이션. |
| 라이선스 | BSD 3-Clause (허용적, 상업 친화적). | GPLv3 (카피레프트, 파생물 공개 의무). |
| 주요 대상 | 상업 기업, 연구자, 개발자. | 취미 사용자, 전문 운영자, 커뮤니티. |
| 제어 시스템 설계 | 일반 믹서 시스템, 새로운 기체에 대한 빠른 프로토타이핑 용이, 간단한 PID 루프. | 고도로 정교하고 기체에 특화된 제어 알고리즘, 우수한 비행 성능. |
| 하드웨어 추상화 | POSIX API를 통한 엄격한 추상화, 높은 이식성. | 자체 AP_HAL 계층, 다양한 하드웨어 지원에 중점. |
| 개발/릴리스 주기 | 빠른 릴리스 주기, 때로는 매일 릴리스. | 더 길고 엄격한 테스트 주기, 베타 테스트를 거친 안정적인 릴리스. |
PX4는 Linux 재단이 관리하는 벤더 중립적인 비영리 단체인 드론코드 재단(Dronecode Foundation)이 주관하는 초석 프로젝트입니다. 이 재단은 드론 개발을 위한 완전한 엔드투엔드 오픈소스 스택을 만드는 긴밀하게 통합된 프로젝트의 생태계를 육성합니다. 주요 동반 프로젝트는 다음과 같습니다:
본 보고서는 PX4의 아키텍처적 강점을 종합적으로 분석했습니다. POSIX API를 통한 비할 데 없는 이식성, uORB 메시징 버스에 의해 가능해진 견고하고 유연한 모듈성, EKF2를 통한 고급 및 결함 허용 상태 추정, 그리고 고도로 사용자 정의 가능한 펌웨어 빌드 시스템이 그것입니다.
프로젝트를 정의하는 핵심적인 아키텍처적 트레이드오프는 명확합니다: 베어메탈 최적화 대신 표준화된 추상화 계층(POSIX)을 의도적으로 선택한 것, 그리고 모놀리식 애플리케이션 대신 유연한 프레임워크를 제공하는 철학입니다.
미래 개발 동향으로는 ROS 2/DDS와의 심화된 통합(이는 uORB/MAVLink 브리지 개념을 직접 기반으로 함)과, 더욱 복잡한 기체 및 애플리케이션을 지원하기 위한 상태 추정 및 제어 알고리즘의 지속적인 진화를 전망할 수 있습니다. PX4의 아키텍처는 이러한 미래의 도전을 수용할 수 있는 견고하고 확장 가능한 기반을 제공합니다.
| uORB Messaging | PX4 Guide (main), accessed July 3, 2025, https://docs.px4.io/main/en/middleware/uorb.html |
| MAVLink Messaging | PX4 Guide (main) - PX4 docs, accessed July 3, 2025, https://docs.px4.io/main/en/mavlink/index.html |