28.3.2.3. 특수 기동 및 비상 태스크 아키텍처

수동 조종(FlightTaskManual 트리)이나 점과 선을 따라가는 자율 미션(FlightTaskAuto 트리) 외에도, 현대의 드론은 특정 피사체를 감시하며 빙글빙글 도는 상업용 촬영 기동이나 벼락을 맞아 GPS가 끊겼을 때 살아남기 위한 생존 기동 등 정형화되지 않은 비행을 수행해야 한다.

이러한 **특수 기동(Special Maneuvers) 및 비상 태스크(Failsafe Tasks)**들은 앞서 설명한 두 거대 상속 체계에 편입시키기엔 그 목적과 쓰이는 수학 단위가 너무 판이하게 다르다. 따라서 이들은 FlightTask 기저 클래스 바로 아래에 독자적인 상속 브랜치(Branch)를 틀고 자신만의 생태계를 구축하고 있다.

1. 정형화된 선(Line)을 거부하는 비선형 궤적 (Non-linear Trajectories)

대표적인 특수 기동인 오빗(Orbit, 원방향 비행) 모드를 생각해 보자. 드론은 특정 좌표(Center)를 바라보며 파라미터로 주어진 반경(Radius)을 유지한 채 빙글빙글 돌아야 한다.

만약 이 원운동 알고리즘을 기존 FlightTaskAutoMapper에 억지로 끼워 넣는다면 어떻게 될까? 원을 아주 무수히 많은 다각형 웨이포인트(수백 개의 점)로 쪼개어 미션 아이템으로 밀어 넣어야 할 것이다. 이는 메모리 낭비일 뿐만 아니라, 버퍼링 제어 지연 때문에 완벽하게 둥근 원을 그리지 못하고 덜컹거리는 폴리곤(Polygon) 궤적이 연출될 가능성이 높다.

따라서 PX4 설계자들은 이 특수 기동들을 별개의 FlightTaskOrbit 같은 독립된 자식 클래스로 분리시켰다. 이 클래스의 update() 함수 내부에는 웨이포인트 처리가 완전히 삭제되어 있으며, 대신 매 타임스텝마다 구심 가속도(Centripetal Acceleration, a = v^2/r) 공식과 삼각함수를 직접 연산하여 기체의 X, Y 속도 벡터를 매끄러운 360도 원호 궤적에 실시간으로 접선(Tangent) 매핑하는 독자적인 수식이 탑재되어 있다.

2. 모든 제약(Constraints)을 무시하는 비상 권한 (Failsafe Authority)

비상 모드(Failsafe Mode)는 아키텍처적으로 더욱 격리되어야 할 이유가 명확하다.

정상적인 비행 모드(Position이나 Mission 등) 트리 안에는 기압계 오차가 크거나 GPS 위성 개수가 6개 이하로 떨어지면 “현재 상태를 신뢰할 수 없으니 안전을 위해 궤적 산출을 중단하고 에러(false)를 뱉어라!“라는 수많은 if문 제약 조건들이 촘촘하게 걸려 있다. 이를 ’Safety Check’라고 부른다.

하지만 폭우로 센서가 침수되거나 GCS 통신이 완전히 끊긴 진짜 위기 상황에서, 시스템이 최후의 보루로 꺼내든 FlightTaskFailsafe 객체마저 똑같은 안전 조건 검사를 하다가 “아 GPS가 구려서 비행을 못하겠네요(false)“라고 산출을 멈춰버리면 드론은 그대로 땅에 처박히게 된다.

• 맹목적 하강(Blind Descent):
  이 독립된 비상 태스크 클래스는 GPS 품질이 쓰레기 값이어도, 자기장 센서가 완전히 미쳐 날뛰어도 그러한 경고들을 모두 무시(Bypass)하도록 설계되어 있다.
• 미니멀리즘 수학:
  이들의 update() 수식은 놀라울 만큼 단순하다. 어차피 X, Y축 위치 제어는 이미 통제 불능이므로 손을 놓고(바람에 흘러가게 내버려 두고), 오직 살아남은 기압계 센서 하나에만 의존하여 Z축 스로틀을 미세하게 깎아가며 땅에 충돌할 때까지 고도만 맹목적으로 내리는(Open-loop Descent) 로직 하나만이 처절하게 돌아갈 뿐이다.

이러한 특수 목적 클래스들의 철저한 분리 독립은, 평상시에는 극한의 정밀도와 안전 검사를 요구하는 까다로운 알고리즘(Main Branch)을 유지하면서도, 메인 센서 시스템이 붕괴했을 때 즉시 최악의 조잡한 센서 데이터라도 끌어모아 생존을 도모하는 유연성(Fallback Capability)을 PX4 FMM 프레임워크에 부여한다.