28.6.3.3. 대기속도 센서 고장 시 VTOL 천이 중단(Abort) 및 MC 모드 강제 복귀(Fallback) 안전 루틴

28.6.3.3. 대기속도 센서 고장 시 VTOL 천이 중단(Abort) 및 MC 모드 강제 복귀(Fallback) 안전 루틴

수직이착륙기(VTOL)가 멀티로터(MC) 모드에서 고정익(FW) 모드로 변환하는 ‘전방 천이(Front Transition)’ 과정에서 기체의 생명줄을 쥐고 있는 단 하나의 센서는 바로 대기속도 센서(Airspeed Sensor, 피토관) 다. 날개에 충분한 양력이 발생했는지를 판단할 수 있는 유일한 지표가 기체 표면을 스치고 지나가는 공기의 흐름(동압, Dynamic Pressure)이기 때문이다.

하지만 야외 비행 환경에서 피토관은 벌레가 끼거나, 물방울이 맺히고 결빙(Icing)되는 등 고장률이 매우 높은 센서 중 하나다. PX4-Autopilot은 이 치명적 단일 고장점(Single Point of Failure)을 극복하고 기체의 추락을 막기 위해 VTOL 천이 중단(Transition Abort) 및 멀티로터 강제 복귀(Fallback) 라는 페일세이프(Failsafe) 메커니즘을 핵심 코어 루틴에 내장하고 있다.

1. 대기속도 센서 고장(Airspeed Failure) 판단 체계

천이 과정 중 대기속도 센서의 이상 유무를 판단하는 주체는 센서 드라이버 단이 아니라, commander 모듈의 하위 감시자인 AirspeedValidator 및 EKF(Estimator) 상태 검증기다.

PX4 시스템은 단순히 센서의 통신 단절(I2C Error)뿐만 아니라, 데이터의 신뢰성 훼손을 다음과 같은 분기로 감지해 낸다.

  1. 하드웨어 타임아웃: 피토관 드라이버에서 uORB 메시지 업데이트가 1000ms 이상 멈췄을 때.
  2. 혁신 오차(Innovation Error) 폭발: GPS가 측정한 대지 속도(Ground Speed)와 피토관이 측정한 대기 속도의 차이에 바람(Wind State) 추정치를 더했을 때, 그 수학적 오차가 EKF 허용 임계치(EKF2_TAS_GATE)를 한참 벗어나는 현상이 지속될 때. (예: 튜브가 막혀서 센서가 계속 0을 가리키는 경우)
  3. 데이터 스틱 현상(Stuck Data): 센서 값이 노이즈 없이 비정상적으로 완전한 상수(Constant)로 멈춰 있는 퍼센티지 에러 로직.

이러한 조건 중 하나라도 발동하면 EKF는 즉각 estimator_status.msg 내의 대기속도 유효성 플래그를 뽑아버린다(airspeed_valid = false).

2. 천이 중단 (Transition Abort) 조건과 타임아웃 메커니즘

전방 천이를 시작하여 푸셔(Pusher) 모터를 켜고 앞으로 달려 나가는 도중, 위의 이유로 센서 데이터가 죽어버리면 vtol_att_control은 맹인이 된 거나 다름없다. 기체의 속도가 양력을 낼 만큼 올랐는지(VT_ARSP_TRANS 초과 여부) 영영 알 수 없기 때문이다.

이때 PX4의 메인 상태 머신(commander.cpp)은 두 가지 트랙으로 천이 중단(Abort)을 압박해 들어간다.

2.1 대기속도 무효(Invalid)에 의한 즉각 중단

천이 중 airspeed_valid 플래그가 false로 변하는 것을 감지한 순간, 시스템은 더 이상 앞이 보이지 않는 상태를 유지하는 것이 위험하다고 판단하여 즉각적으로 현재 진행 중인 이행 단계를 멈춘다.

2.2 시간 초과(Timeout)에 의한 블라인드 중단

피토관 수치가 간당간당하게 살아있어 에러 판정은 면했지만, 값이 측정 범위를 벗어나거나 낮게 깔리면서 기체가 아무리 푸셔를 세게 쳐도 목표 천이 속도에 도달하지 “못하는 체” 하는 경우다.
이때는 타임아웃 파라미터(VT_TRANS_TIMEOUT, 기본값 약 15~20초)가 최후의 보루 역할을 한다. 전방 천이가 시작된 지 지정된 시간이 경과했는데도 대기속도가 목표치를 뚫지 못하면, commander는 기체의 공기역학적 구조에 심각한 저항(예: 페이로드의 항력 초과)이 생겼거나 센서 이상으로 간주하고 강제로 타임아웃 에러를 발생시킨다.

3. MC 모드 강제 복귀 (Fallback to Multicopter) 구조

천이 중단 판정이 내려진 순간, vtol_att_control 모듈 내의 코드는 비상 복구 시퀀스(Emergency Recovery Sequence)로 점프한다. 그 핵심 원칙은 “고정익 비행을 즉시 포기하고 가장 확실하게 물리적으로 안전한 상태로 기체를 묶어두는 것” 이다. 그 안전한 상태가 바로 프로펠러의 강제 추력으로 기체를 붙잡는 ’멀티로터(MC) 모드’다.

  1. 동력 스위치 스냅 (Snap Action):
    가동 중이던 고정익 푸셔 모터(weight_fw)를 즉각적으로 차단(0.0)한다.
  2. MC 가중치 롤백 (Weight Rollback):
    줄이고 있던 호버링 모터의 출력(weight_mc)을 즉시 1.0 (100% 개입)으로 복원시킨다.
  3. 상태 강제 이관 (State Overwrite):
    is_vtol_transition 플래그를 false로 내리고, 시스템의 vehicle_type을 VEHICLE_TYPE_ROTARY_WING(멀티로터)으로 강제 덮어쓴다.
  4. 페일세이프 내비게이션 진입:
    천이를 실패했으므로 기체는 원래 하려던 Mission(계획된 비행)을 중단해야 한다. commander는 파라미터 COM_SPOOLUP_TIME 등의 보호 조건과 함께, 안전장치 로직(Failsafe State Machine)을 가동하여 기체를 그 자리에 머물게 하는 Loiter(Hold) 모드나 이륙지로 돌아오는 Return(RTL) 모드로 강제 천이시킨다.
    이때의 귀환은 오버라이드 기능이 적용된 멀티로터 형태의 느린 비행(또는 쿼드 복귀 모드) 으로 진행된다.

4. ArduPilot의 천이 실패 루틴과의 차이점 탐구

센서 고장이나 타임아웃에 대처하는 본연의 방어 로직은 PX4와 ArduPilot(QuadPlane)이 큰 틀에서 맥락을 같이 한다. 기체를 살리기 위해 콥터 모드로 돌아간다는 대명제는 동일하다.

하지만 ArduPilot에서는 센서리스 천이(Sensorless Transition, Airspeed sensor 없이 오직 GPS Ground speed에만 의존하여 천이하는 모드) 기능 확장이 상업용 VTOL의 요청에 따라 상당히 정교하게 파라미터화(ARSPD_USE=0, ARSPD_TYPE=0 조합 시)되어 있다. 바람을 역산출해 대기속도를 추정하는 합성 스피드(Synthetic Airspeed) 알고리즘 의존도가 상대적으로 높다.

반면, PX4-Autopilot은 원론적인 파라미터 기본값(Default) 상태에서 “진짜 피토관이 죽으면 고정익 룰렛을 돌리지 않고 단칼에 MC 모드로 돌아와 랜딩을 준비하라“는 안전 우선의 학술적/보수적 하드코딩 경향이 아키텍처 상 조금 더 짙게 배어있다. 최근 버전에서는 FW_ARSP_MODE 등을 통해 무센서 제어를 옵션으로 풀고 있으나, 여전히 천이 구간만큼은 물리 센서의 무결성이 가장 강력한 방어기제로 작동한다.