30.6.3. 임무 수행 중 하드웨어 결함 감지(Failure Detection) 상태 머신과 비행 종료(Flight Termination) 서브루틴의 인터럽트 처리 우선순위

30.6.3. 임무 수행 중 하드웨어 결함 감지(Failure Detection) 상태 머신과 비행 종료(Flight Termination) 서브루틴의 인터럽트 처리 우선순위

자동 비행(Mission)을 수행 중인 드론은 GPS 단절이나 배터리 부족과 같은 ’소프트웨어적 극복 가능 에러(Recoverable Error)’를 넘어, 모터 화재, 프로펠러 피로 파괴, 혹은 제어면(Control Surface) 이탈과 같은 물리적인 **하드웨어 치명적 결함(Unrecoverable Hardware Failure)**에 직면할 수 있다.

이러한 상황에서는 RTL이나 고도 유지(Altitude Hold)와 같은 폴백(Fallback) 모드를 시도하는 것 자체가 추락 반경을 무분별하게 넓히거나 지상 인명에 대한 예초기(Blade) 위협을 가중시키는 2차 재난으로 이어질 수 있다. 본 장에서는 PX4-Autopilot의 내부 상태 머신(State Machine)이 어떻게 비가역적 하드웨어 결함을 감지하고, 모든 제어 인터럽트의 최상위 우선순위를 탈취하여 비행 종료(Flight Termination) 서브루틴을 즉각 발동하는지 시스템 아키텍처 관점에서 분석한다.

1. 하드웨어 결함 감지 (Failure Detector) 아키텍처

PX4에는 failure_detector라는 독립적인 데몬(Daemon) 모듈이 존재하며, 이는 vehicle_status 및 sensor_combined 토픽을 매우 빠른 주기로 구독하며 기체의 물리적 궤멸 징후를 판별한다. 이 모듈은 다음 3가지 핵심 감지기(Detector)로 구성된다.

1.1 롤/피치 자세 전복 (Attitude Failure)

자동 비행 중 기체가 뒤집히는 거꾸로 된 상태(Inverted)가 발생하면, 이는 명백히 물리적 파열(모터 1개 정지, 프로펠러 깨짐 등) 또는 복원 불가능한 난기류 타격에 기인한 것이다.

  • failure_detector는 EKF2가 추정하는 Roll/Pitch 각도가 파라미터 FD_FAIL_R 및 FD_FAIL_P (통상 60^\circ \sim 80^\circ) 임계치를 초과한 상태가 일정 시간(FD_FAIL_T 초) 이상 지속되는지 감시한다.
  • 일시적으로 1초간 훅 뒤집혔다 복구되는 어그레시브 메뉴버(Aggressive Maneuver)와 진짜 결함을 구분하기 위해 시간 기반의 로우패스 딜레이(Time-delay Window)를 둔다.

1.2 모터 및 ESC 통신 단절 (ESC Failure)

UAVCAN이나 DShot 텔레메트리 프로토콜을 사용하는 지능형 ESC(전자 변속기)가 장착된 경우, 모터의 회전수(RPM)가 0으로 떨어지거나, ESC 보드의 전류망 타버림(Burn-out)으로 센서 통신이 끊어지면 이를 하드웨어 결함으로 즉각 분류한다 (FD_OBS_ESC 파라미터 활성화 시).

1.3 외부 Failsafe 개입 (External Failure / PWM Failsafe)

별도의 하드웨어 워치독(Watchdog) 보드나 GCS, 혹은 컴패니언 컴퓨터 상의 AI 머신 비전(추락 감지 시스템)에서 MAVLink 커맨드나 특수 핀(Pin)을 통해 강제로 “결함” 깃발(Flag)을 하달할 경우다.

2. 상태 머신(State Machine) 상의 최상위 인터럽트 권한

failure_detector 모듈이 위의 3가지 징후 중 하나라도 사실로 확정(Flag = True)하면, 이 데이터는 vehicle_status.failure_detector_status 토픽을 타고 커맨더(commander.cpp)로 전송된다.

  • PX4 커맨더 아키텍처에서 하드웨어 결함 감지 인터럽트는 RC 조종 입력, 지오펜스(Geofence) 이탈, GPS 단절 등 그 어떤 Failsafe 폴백 이벤트보다 논리적 우선순위(Priority)가 압도적으로 높다.
  • 따라서 Mission 비행 좌표 이동 커맨드를 처리하느라 바쁘던 navigator 데몬의 쓰레드(Thread)는 강제로 셧다운(Shutdown) 되며 시스템의 모든 실행 컨텍스트(Execution Context)가 긴급 인터럽트 서비스 루틴(ISR) 격인 Flight Termination (비행 종료) 구문으로 제어권을 뺏기게 된다.
graph TD
    A[임무(Mission) 수행 중] --> B{Failure Detector 데몬 회전체 이상 감지 <br>(자세 전복 등)}
    B -->|Flag = False| C[정상 임무 계속]
    B -->|Flag = True| D[커맨더: 최상위 인터럽트 발송]
    D --> E[모든 하위 제어기(Pos/Att/Rate) 및 <br>Navigator 권한 즉각 박탈]
    E --> F{CBRK_FLIGHTTERM 파라미터 검사}
    F -->|활성화(차단)| G[에러만 띄우고 회복 노력 진행 <br>(개발자 디버깅 모드)]
    F -->|비활성화(정상)| H[비행 종료(Flight Termination) 서브루틴 진입]

3. 비행 종료 (Flight Termination) 서브루틴 프로세스

비행 종료(RTL이나 Land와는 완전히 다른 개념) 서브루틴이 발동되면 기체 파손을 각오하더라도 생명과 재산을 지키는 것을 최우선으로 삼는 하드웨어 데드(Hardware Dead) 셧다운 로직이 전개된다.

  1. 액추에이터 무장 해제 (Instant Disarm):
    비행 중임에도 불구하고 백그라운드의 시동 상태 머신을 우회하여(Bypass) 주 전원 분배 보드(FMU/IO)를 향해 직접 모터 PWM ‘0’ (또는 하한선) 신호를 쏴버린다. 이는 망가진 채로 모터가 계속 돌아가며 기체가 땅 위에서 미친 듯이 굴러다니는 이른바 “치킨 댄스(Chicken Dance)“를 물리적으로 봉쇄하기 위함이다.
  2. 낙하산(Parachute) 트리거:
    COM_FLT_TERM_ACT 파라미터가 낙하산 전개로 설정되어 있다면, 모터 전원을 끊음과 동시에 IO 보드의 특정 핀(PWM AUX)을 High로 올려 구명 낙하산의 사출 화약(Pyrotechnic charge)이나 릴리즈 서보(Servo)를 격발시킨다. (모터 전원이 먼저 끊어지지 않으면 낙하산 줄이 프로펠러에 감기는 대형 사고가 발생하므로 이 순서는 나노초 단위로 엄격히 보장된다.)
  3. 텔레메트리 블랙박스 고정: ULog 플래그에 ‘CRASH/FLIGHT TERMINATION’ 태그를 강박하고, 기체가 땅에 떨어져 박살나기 전까지의 메모리 버퍼를 SD카드에 강제로 써내려(Flush) 사고 원인 분석의 단서를 보존 시도한다.

4. Ardupilot ‘Crash Check’ 와의 설계 차이

  • Ardupilot도 FS_CRASH_CHECK 모듈을 통해 비슷한 기능을 제공하나, 파라미터 체계가 상대적으로 분절화되어 있다.
  • PX4는 CBRK_FLIGHTTERM (비행 종료 기능 서킷 브레이커)이라는 특수한 디버깅용 안전핀(Safety Pin) 파라미터를 제공한다. 개발실에서 기체를 마구 뒤집으며 테스트할 때 시동이 꺼지는 현상을 방지하기 위해 이 안전 파라미터 하나만 변경하면 전체 서브루틴이 바이패스(Bypass)되도록 계층화 설계가 잘 되어 있어, 연구원들의 하드웨어 통합 시뮬레이션(HIL/HITL) 장벽을 낮추는 철학을 엿볼 수 있다.

5. 요약: 로봇 윤리와 다중 방어 시스템

임무 중 발동되는 Failure Detection과 비행 종료 상태 머신은 드론이 더 이상 하늘을 나는 새가 아니라 제어 불능의 쇳덩이 폭탄(Projectile)으로 돌변했음을 인정하는 항공 윤리적 소프트웨어 백도어(Ethical Backdoor)다. 그 어떤 훌륭한 궤적 로직(RTL, NPFG)도 ‘자세 제어 루프가 영원히 깨진 물리적 이단아’ 앞에서는 무용지물이므로, PX4의 최상위 인터럽트 우선순위 설계는 수십 번의 추락 사고 빅데이터 위에서 쓰여진 피의 규정(Blood rule)이자 가장 위대한 Failsafe로 평가받는다.