28.6.2.1. TECS(Total Energy Control System)와 Flight Mode 간의 데이터 교환 추상화 한계성 분석

28.6.2.1. TECS(Total Energy Control System)와 Flight Mode 간의 데이터 교환 추상화 한계성 분석

고정익의 에너지 결합 제어(Coupled Control)를 수학적으로 완벽하게 풀어낸 TECS(Total Energy Control System)는 PX4-Autopilot 고정익 제어의 가장 큰 자랑거리다. 하지만, 완벽해 보이는 이 시스템도 소프트웨어 아키텍처 관점—특히 다양한 비행 모드(Flight Mode)에서 생성된 제어 목표(Setpoint)를 TECS라는 단일 엔진에 주입하는 ‘인터페이스(Interface)’ 계층—에서는 몇 가지 뚜렷한 추상화(Abstraction) 한계를 노출한다.

본 절에서는 “어느 모드에서 개발하건간에 고도와 속도 셋포인트만 넘기면 알아서 날아간다“는 이상적인 추상화가, 실제 비행 역학과 맞물리면서 왜 완벽하게 코드로 구현될 수 없는지, 그 구멍들과 데이터 교환의 병목점들을 아키텍처 레벨에서 분석한다.

1. 이상적 추상화 모델의 붕괴

PX4의 비행 모드 구조는 다형성(Polymorphism)을 기반으로 한 객체 지향 설계를 따른다. 즉, FlightTask라는 상위 클래스를 상속받아 AutoMapper, ManualPosition, Orbit 등의 태스크 모듈이 각각 자신의 목적에 맞게 독립적으로 구동된다.

가장 이상적인 추상화 모델이라면, 이들 모든 Flight Task가 복잡한 물리 계산은 전혀 모른 채, 단지 목표 고도(h_{sp}) 와 목표 속도(v_{sp}) 두 개의 실수값(Float) 묶음만 던져주면, 백엔드인 TECS가 이를 받아 완벽히 비행해 주어야 마땅하다.

하지만 다음과 같은 예외 상황들이 발생하면서 이 인터페이스의 순수성이 무너진다.

1.1 하강 궤적의 충돌 (지형 추종 문제)

RTL(복귀)이나 착륙(Land) 모드 시 기체는 일정한 각도(Glide Slope)로 지면을 향해 급강하해야 한다. 이때

  • 모듈 측(Flight Mode): “초당 3m/s 속도로 하강하면서 고도를 깎아라.(목표)”
  • TECS 측: “위치 에너지를 운동 에너지로 바꾸라는 뜻이군. 스로틀을 끄고 피치를 내린다.”

그런데 만약 맞바람이나 강한 하강 기류를 맞아서, 물리적인 최대 강하율 제약(Maximum Sink Rate)을 넘어버릴 위기에 처하면 어떻게 될까?
TECS 내부에는 이 경우 기체를 살리기 위해 어쩔 수 없이 스로틀을 켜고(또는 끄고) 기수를 억지로 들어(Pitch Up) 속도를 잃으면서까지 고도를 맞추려는 하위 보호 로직이 발동한다.
이렇게 되면 Flight Mode 단에서 애써 미적분에 기반하여 정교하게 그려놓은 ’고스트 궤적(Virtual Trajectory)’은 TECS 내부 로직에 의해 완전히 무시당(Override)해 버려, 상위 클래스의 제어 의도가 백엔드에서 묵살되는 데이터 단절(Incoherency)이 빈번히 발생한다.

2. 추가 메타데이터 채널의 통로 확보 (The Hack)

결국 순수하게 “고도와 속도” 두 개만 주고받아서는 이기적인 TECS 짐승을 통제할 수 없음을 깨달은 PX4 개발진은, vehicle_local_position_setpoint 토픽 안에 TECS 전용의 특수 메타데이터 해킹(Hack) 필드들을 덕지덕지 추가하여 데이터 교환 통로를 넓히게 되었다.

2.1 특수 설정 필드 (Configuration Overrides)

모드 관리자(Flight Mode Manager)는 단순히 궤적 스칼라만 던지는 게 아니라, TECS 내부의 상수 파라미터까지 실시간 통신으로 조작할 수 있는 백도어를 갖는다.

  • tecs_throt_min, tecs_throt_max: 특정 순간(예: Land 플레어 시점)에 모터 스로틀의 하한/상한선을 강제로 설정.
  • tecs_pitch_min, tecs_pitch_max: 특정 동작 시 기수의 상하 피칭 각도를 제한.

2.2 비행 모드 플래그의 하향 전달 (Down-casting)

추상화의 한계를 보여주는 가장 단적인 예가 모드 정보의 하향 전달이다. 객체 지향 원칙에 의하면, 백엔드 제어기(TECS)는 현재 자신을 누가 부르고 있는지(어떤 모드인지) 알아서는 안 되며, 오직 주어진 숫자에만 맹목적으로 복종해야 한다. (Decoupling의 원칙)

그러나 실제 PX4 소스 상에서 TECS 모듈 내부 깊숙한 곳에는 다음과 같은 코드가 박혀있다.

// TECS.cpp 내부 어딘가...
if (flight_mode == Mode::TAKEOFF) {
    // 이륙 상황일 때만 특별히 운동 에너지(속도) 제약 조건을 완전히 무시하고
    // 무조건 최대 스로틀을 치면서 위치 에너지(피치 업)를 확보하라.
    _pitch_sp = _pitch_max;
}

TECS 스스로가 현재 자율 주행의 State(이륙인지, 착륙인지, 순항인지)를 엿듣어 내부 알고리즘 분기를 타는 것이다. 이것은 완벽한 추상화의 실패이자 강한 구조적 결합(Tight Coupling)을 의미한다.

3. 추상화 한계에 대한 아키텍처적 변론

왜 이런 지저분한 연결고리들이 남게 되었을까? 그 근본 원인은 “TECS가 다루는 중력과 공기 역학(Aerodynamics)이라는 실체가, 소프트웨어의 논리적 모드보다 훨씬 더 강압적이기 때문“이다.

멀티로터의 제어(위치 도달)는 100% 모터 rpm이라는 인위적 힘으로 창조된다. 반면 고정익의 비행은 기체의 관성, 날개의 받음각, 그리고 주변 공기 밀도가 만들어내는 자연 현상(Natural Phugoid Mode)과의 협상이다.

이륙(Takeoff) 상황에서 이륙 속도가 채 확보되기도 전에 “이 궤적을 철저히 따라가라“는 상위 모드의 명령을 맹목적으로 따르다 보면 여지없이 스톨(Stall)로 추락한다. 따라서 TECS는 단순한 수식 계산기를 넘어, 기체를 살려야한다는 본능이 이식된 상태 인식 생존 머신(Context-aware Survival Machine) 으로 스스로 진화할 수밖에 없었다.

4. 결론 및 고도화 방향

결국 현재 PX4 고정익 시스템에서, Flight Mode Manager(상위)와 TECS(하위) 간의 데이터 교환 인터페이스는 완전한 블랙박스(Black-box) 추상화를 이루지 못하고, 여과 없이 서로의 내부 상태를 들여다보는 회색 지대(Gray Zone)를 남겨두고 있다.

차세대 PX4 아키텍처 개선 논의에서는 이러한 한계를 타파하기 위해, NMPC(Nonlinear Model Predictive Control, 비선형 모델 예측 제어)와 최적 제어기법을 도입하여, 모드 관리자가 던지는 것이 ’명령값’이 아닌 철저히 수식화된 비용 함수(Cost Function) 의 가중치 배열이 되도록 인터페이스를 완전 전면 재설계하려는 움직임이 학계를 중심으로 연구되고 있다.