28.6.3. 수직이착륙기(VTOL): 듀얼 펌웨어 아키텍처 융합 및 천이(Transition) 모드 관리

28.6.3. 수직이착륙기(VTOL): 듀얼 펌웨어 아키텍처 융합 및 천이(Transition) 모드 관리

틸트로터(Tiltrotor), 쿼드플레인(Quadplane), 테일시터(Tailsitter) 등으로 대표되는 수직이착륙기(VTOL, Vertical Take-Off and Landing)는 현대 무인항공기 산업에서 가장 혁신적이고 파급력이 큰 플랫폼이다. 이는 멀티로터의 제자리 호버링(Hovering) 이착륙 능력과 고정익의 고속/장거리 순항 효율성을 하나의 기체 안에서 모두 구현할 수 있기 때문이다.

그러나 시스템 제어 공학 관점에서 VTOL은 극악의 난이도를 자랑한다. 물리적으로 정반대의 역학(저속 추력 편향 vs 고속 양력 의존)을 가진 두 개의 시스템을 하나의 마이크로컨트롤러 위에서 동시에 제어해야 하기 때문이다. PX4-Autopilot은 이 난제를 타개하기 위해 듀얼 펌웨어 아키텍처(Dual Firmware Architecture) 에 기반한 유기적 융합(Fusion) 제어 모델을 도입했다. 본 절에서는 VTOL의 근본적인 모드 아키텍처와 천이(Transition) 모드의 관리 체계를 심층적으로 탐구한다.

1. 듀얼 펌웨어 아키텍처와 vtol_att_control 모듈

PX4 시스템은 VTOL 기체를 제어하기 위해 전혀 새로운 제어기를 바닥부터 짜는 대신, 이미 수만 시간의 비행 테스트를 통해 검증된 기존의 멀티로터(MC) 제어기와 고정익(FW) 제어기를 그대로 재사용(Reuse)하는 천재적인 아키텍처를 선택했다.

운영 체제(NuttX) 상에서 VTOL 기체가 부팅되면, PX4는 물밑에서 멀티로터용 위치/자세 제어기(mc_pos_control, mc_att_control)와 고정익용 위치/자세 제어기(fw_pos_control_l1, fw_att_control) 4개의 모듈 데몬(Daemon)을 동시에 띄운다.

이 4개의 모듈은 기체에 달린 센서 데이터를 바탕으로 각자 자신이 통제권자라 착각하며 “가상 출력(Virtual Actuator Output)“을 맹렬히 뿜어낸다. 여기서 오케스트라의 지휘자로 등장하는 것이 바로 vtol_att_control (VTOL Attitude Controller) 모듈이다.

  • vtol_att_control은 MC 제어기가 생성한 엑추에이터 목표값(Actuator Controls 0)과 FW 제어기가 생성한 엑추에이터 목표값(Actuator Controls 1)을 동시에 가로챈 뒤(Intercept), 기체의 현재 상태(State)에 따라 그 출력의 가중치를 믹싱(Mixing)하거나 차단하여 최종적으로 물리적인 모터(ESC)와 서보 모터(Servo)로 신호를 라우팅(Routing)한다.

이러한 모듈형 융합 아키텍처 덕분에, 멀티로터의 정지가 비행 기술이나 TECS 기반 고정익 순항 기술이 발전할 때마다 VTOL은 그 혜택을 코드 수정 없이 그대로 누릴 수 있게 되었다.

2. VTOL 비행 모드(Flight Mode)의 3가지 대분류 (State Machine)

지휘자인 vtol_att_control 모듈은 내부적으로 시스템 상태를 크게 세 가지의 논리적 모드(Mode)로 분류하여 통제한다. 이 상태 변수는 uORB 토픽 vehicle_status.msg 내의 vehicle_type 필드와 is_vtol_transition 플래그로 캡슐화되어 시스템 전역으로 전파된다.

2.1 멀티로터 모드 (Rotary Wing Mode, MC)

  • 상태: 이착륙 및 저속 호버링 시
  • 제어권 매핑: 멀티로터 제어기(PID)의 출력이 100% 반영된다. 고정익 제어기의 출력은 무시되거나 에일러론/엘리베이터 서보 모터를 중립으로 굳히는 데만 락킹(Locking)된다. 이 상태에서 기체는 역학적으로 무거운 멀티콥터와 완벽히 동일하다.

2.2 고정익 모드 (Fixed Wing Mode, FW)

  • 상태: 대기속도가 충분히 확보된 고속 순항 시
  • 제어권 매핑: 고정익 제어기(TECS)의 출력이 100% 반영된다. 양력이 기체를 띄우고 있으므로, 멀티로터 전용 리프트 모터(Lift Motor)들은 완전히 정지(Disarmed 상태와 유사)한다. (단, 푸셔(Pusher)나 틸트로터의 경우 추력용 전방 모터 1~2개는 TECS의 스로틀 명령에 의해 회전한다.)

2.3 천이 모드 (Transition Mode)

  • 상태: MC \rightarrow FW (전방 천이) 또는 FW \rightarrow MC (후방 천이) 로 넘어가는 수 초간의 찰나.
  • 제어권 매핑: 두 제어기의 출력이 공존 및 충돌하는 카오스(Chaos) 상태다.
    vtol_att_control은 이 순간에 타임라인(Timer) 및 대기속도(Airspeed) 센서 피드백에 따라 MC 출력과 FW 출력 간의 블렌딩(Blending) 웨이트(Weight) 곡선을 지수적/선형적으로 계산하여 양쪽 모터를 동시에 돌린다. 이때 기체 하드웨어의 종류(틸트로터, 쿼드플레인, 테일시터)에 따라 이 믹싱 클래스의 자식 구현체(Sub-class)가 파생되어 각기 다른 수학적 결합(Coupling) 공식을 제공한다.

3. 기체 유형별(VTOL Type) 천이 아키텍처의 분화 (Polymorphism)

VTOL은 하드웨어가 비행 궤적을 전환하는 방식에 따라 물리적 역학이 크게 다르기 때문에, PX4는 VtolType이라는 추상 클래스(Abstract Class)를 두고 세 가지 자식 클래스를 파생시켰다.

  1. Standard VTOL (쿼드플레인 형태): 가장 제어하기 쉽다. 위로 띄우는 호버 모터 4개와 앞으로 밀어주는 푸셔(Pusher) 모터 1개가 물리적으로 완벽히 독립되어 있다. 천이 과정에서 푸셔 모터를 켜서 대기속도를 올리고, 속도가 도달하면 호버 모터를 끄기만 하면 된다.
  2. Tiltrotor VTOL (틸트로터 형태): 역학적으로 가장 정교하다. 전방 모터 2개가 이륙 시에는 위를 보다가, 천이 과정에서 서보 모터에 의해 90도 앞으로 꺾인다(Tilt). 꺾어지는 0~90도 중간 과정에서 모터의 추력 벡터가 수평(전진력)과 수직(부양력)으로 분할(Cosine/Sine)되어 작용하므로, 이를 보상하기 위해 MC 제어기의 멀티플라이어(Multiplier) 게인값이 틸트 각도에 맞춰 실시간으로 변조(Modulation)되어야 한다.
  3. Tailsitter VTOL (테일시터 형태): 모터의 방향은 고정되어 있지만 기체 전체 몸체가 하늘을 보다가(MC 모드) 수평으로 90도 누워버리는(FW 모드) 형태다. 상태 머신이 90도 피치 축 회전을 겪으며 요(Yaw) 축과 롤(Roll) 축의 좌표계가 서로 스왑(Swap)되는 치명적인 오일러 각(Euler Angle) 짐벌 락(Gimbal Lock) 위험이 발생하므로, 제어 모듈 단에서 철저하게 쿼터니언(Quaternion) 퓨전(Fusion) 보상을 거쳐야 한다.

4. ArduPilot (ArduPlane)과의 VTOL 아키텍처 비교

VTOL의 복합적인 모드 제어에 대하여 PX4와 ArduPilot 생태계는 역사적으로 다른 발전 경로를 걸어왔다.

  • ArduPilot (단일 펌웨어 확장형 - QuadPlane 아키텍처): 초창기 평범한 고정익 펌웨어였던 ArduPlane 코드베이스 안에 멀티로터의 모터 제어 라이브러리를 통째로 이식(Import)해버렸다. 즉, 메인 루프를 관장하는 것은 고정익 제어기(Plane)이며, 이륙이나 천이가 필요할 때만 그 안에 하위 종속된 쿼드 제어기(Copter)를 잠시 서브루틴으로 호출하여 “빌려 쓰는” 개념에 가깝다. 이를 ArduPilot에서는 통칭 QuadPlane 시스템이라 부른다.
  • PX4 (독립 모듈 브로커형 - VTOL 데몬): 앞서 살펴본 바와 같이, PX4는 MC 펌웨어와 FW 펌웨어를 평등한 개체의 프로세스로 마주 보게 두고, 제3의 중재자(vtol_att_control)가 스위치 역할을 하는 다중 프로세스(Multi-process) 융합 구조를 택했다.

이는 아키텍처의 우열을 가리기보다는 설계 철학의 차이다. PX4의 접근 방식은 각 모듈(MC, FW) 코드의 오리지널리티와 독립성을 유지하는 객체 지향적(OOP) 깔끔함을 극대화했지만, 모듈 간 메시지를 주고받는 uORB 통신 오버헤드와 동기화(Synchronization) 이슈라는 부작용을 관리해야 하는 모드 아키텍처상의 새로운 도전 과제를 낳기도 했다.