28.6. 기체 동역학 유형별(Vehicle Specific) 모드 아키텍처 분화

28.6. 기체 동역학 유형별(Vehicle Specific) 모드 아키텍처 분화

비행 제어 소프트웨어가 단순히 프로펠러 4개를 굴리는 장난감을 넘어 산업용 “오토파일럿(Autopilot)“으로 불리기 위해서는, 멀티로터(드론)뿐만 아니라 고정익(비행기), 헬리콥터, 지상 자율주행차(Rover), 잠수함, 그리고 수직이착륙기(VTOL)까지 모두 품을 수 있는 범용성을 갖추어야 한다.

PX4-Autopilot은 이처럼 각기 다른 역학적 특성을 가진 기체(Vehicle Specific Dynamics)들을 제어하기 위해, 비행 모드 관리자(Flight Mode Manager)의 논리적 모드 체계는 하나로 통일하되, 실제 하부 제어기(Controller) 구동 아키텍처는 기체 유형별로 완전히 분리(Decoupling)하는 전략을 취하고 있다. 본 절에서는 이러한 기종별 아키텍처의 분화 패러다임을 살펴본다.

1. 개요: 단일 오토파일럿, 다중 모델(Multi-Model) 지원

앞선 장들에서 살펴본 바와 같이, 조종사의 조종기나 지상 관제소(GCS)에서 전달되는 “Position 모드를 켜라”, “Mission 모드를 실행하라“와 같은 논리적 상태 천이 지시와 플래그 스위칭(vehicle_control_mode)은 기체 종류에 상관없이 공통 모듈인 커맨더(Commander) 모듈을 통해 일원화되어 처리된다.

하지만 “위치 제어(Position Control) 모드“라는 논리적 요구사항 하나를 만족시키기 위해 실제로 모터를 어떻게 믹싱할 것인가에 대한 답변은 기체의 동역학 모델마다 천차만별이다.

  • 멀티로터: 원하는 방향으로 기체를 살짝 ‘기울이고(Tilt)’, 전체 추력을 올려서 미끄러지듯 이동한다. (언더액추에이티드, 전방위 이동 가능)
  • 고정익: 무조건 끊임없이 앞으로 전진(Forward Flight)해야만 추락을 면할 수 있으므로, 목적지로 선회하기 위해 기체를 ’뱅킹(Banking)’하고 고도를 높이기 위해 피치(Pitch)를 들어 올려 양력을 발생시킨다. (최소 속도 제약 궤적 비행)
  • VTOL (수직이착륙기): 이착륙 시에는 멀티로터처럼 굴다가, 하늘 위에서는 고정익처럼 글라이딩한다. (하이브리드 모드 믹싱)

따라서 PX4 시스템은 상위의 “비행 모드(Flight Mode)” 와 하위의 “제어기(Controller App)” 를 소프트웨어적으로 철저하게 분리시켰다.

2. 모드 추상화(Mode Abstraction)와 제어기 분기 아키텍처

기체 프레임(Airframe) 설정에 따라 PX4는 부팅(Startup) 스크립트(rcS 시스템) 단계에서 어떤 제어기 앱(모듈)들을 백그라운드 태스크로 띄울지 결정한다.

각 제어기 앱들은 동일한 vehicle_control_mode 토픽을 라디오 방송처럼 수신하지만, 기체 유형별로 필요한 플래그만 취사선택하여 각자의 방식으로 해석(Parse)한다.

2.1 멀티로터(MC) 제어 스택

  • 메인 프로세스: mc_pos_control (위치/속도 제어), mc_att_control (자세 제어), mc_rate_control (각속도 제어)
  • 아키텍처 특징: X, Y, Z축이 서로 강하게 독립적인 P-PID 다단 루프(Cascade Loop)를 탄다.
  • 모드 해석: Position 모드 수신 시 3D 공간 상의 XYZ 오차를 벡터 기반 속도 명령으로 직관적으로 맵핑한다.

2.2 고정익(FW) 제어 스택

  • 메인 프로세스: fw_pos_control_l1 (위치 경로 제어), fw_att_control (자세 제어) 또는 tecs (전체 에너지 제어 모듈)
  • 아키텍처 특징: 속도(Throttle)와 고도(Pitch) 제어가 중력 단위를 매개로 강하게 결합(Coupled)되어 있다.
  • 모드 해석: Position/Mission 모드 수신 시 점(Point) 이동이 아니라 L1 항법(L1 Navigation) 알고리즘을 사용하여 웨이포인트를 부드럽게 감싸 도는 곡선형 선회 궤적 및 에너지 보존 하강/상승 목표를 도출한다.

2.3 수직이착륙기(VTOL) 제어 스택

  • 메인 프로세스: vtol_att_control 모듈이 MC 제어기와 FW 제어기 사이에 샌드위치처럼 끼어든다.
  • 아키텍처 특징: 현재 기체가 멀티콥터 모드인지, 천이(Transition) 중인지, 고정익 모드인지에 따라 두 제어기가 뱉어내는 모터 토크 및 서보 제어량(Actuator Setpoint)의 가중치(Weight Blend) 를 실시간으로 믹싱한다.

3. Position/Mission 모드의 해석 차이 (UML적 관점)

조종기에서 Position 모드 스위치를 조작했을 때, 시스템 레벨에서 일어나는 반응 체계를 비교하면 그 차이가 극명하게 드러난다.

  1. 멀티로터 (공중에 정지할 수 있음): 조종 스틱을 모두 놓으면 기체는 바람을 버티며 “특정 GPS 좌표와 고도에 브레이크를 걸고 정지(Hold)“한다. 즉 멀티로터에게 Position 모드란 목표 거점을 향한 3D 벡터 이동 및 동적 잠금(Dynamic Lock)을 의미한다.
  2. 고정익 (공중에 정지할 수 없음): 조종 스틱을 놓으면 기체는 현재의 고도와 중심 좌표 부근을 “빙글빙글 선회 비행(Loitering)“한다. 고정익에게 Position 모드(Loiter 반경)는 점이 아니라 비행기를 띄워놓기 위한 수십 미터 반경의 유지 원형 궤적(Circular Trajectory)을 의미한다.

이러한 물리적 차이로 인해, Commander는 flag_control_position_enabled 플래그를 올려주기만 할 뿐 그에 따른 ’선회 궤적’을 만들지, ’정지 벡터’를 돌릴지의 설계 지분(Design Concern)은 각 기체별 위치 제어기(mc_pos_control vs fw_pos_control_l1)의 C++ 소스 코드 고유 영역으로 유연하게 위탁되는 설계 패턴을 보여준다.

4. ArduPilot과의 아키텍처 비교 (Copter vs Plane)

  • ArduPilot (모놀리식 분리 구조): 전통적으로 소스 코드 저장소(Repository) 레벨에서부터 프로젝트가 ArduCopter, ArduPlane, APMrover2 등의 바이너리(펌웨어 이미지)로 완전히 격리 분할되어 진화해 왔다. 각 모드 시스템(mode_*.cpp)은 기체 특성에 맞게 완전히 하드코딩된 별도의 클래스 상속 체계를 가진다.
  • PX4 (통합 uORB 버스 구조): 단일한 핵심 코어(Core OS & Flight Mode Manager & Commander) 위에서 기종별 제어기 프로세스만 교체 탑재(Plug-and-play) 방식으로 돌려쓰는 진정한 통합 펌웨어(Unified Firmware) 환경을 제공한다. 모드 철학과 메시지 버스를 고유화시킨 덕에, 새로운 형태의 커스텀 드론(예: 틸트 로터, 자전거 형태의 로봇 등)을 만들 때 기존의 최상위 모드 관리 코드를 건드릴 필요 없이 오직 제어기 모델링 믹서(Mixer)만 새롭게 끼워 넣으면 되는 아키텍처의 우수성을 확보하였다.