28.2.4.1. `vehicle_control_mode.msg` 기반의 제어 권한 위임 체계

28.2.4.1. vehicle_control_mode.msg 기반의 제어 권한 위임 체계

PX4의 최고 사령탑 데몬인 Commander 모듈이 의사결정을 내리고 하위 제어기 모듈(Flight Mode Manager, 자세 제어기, 속도 제어기 등)들에게 병력을 통제하도록 하달하는 가장 전술적인 명령어가 바로 vehicle_control_mode.msg 토픽이다.

앞서 살펴본 vehicle_status 토픽이 “지금 너의 상태는 자동 웨이포인트(Auto Mission) 모드다“라는 거시적 직위(Position)를 부여하는 추상적 임명장이라면, vehicle_control_mode 토픽은 그 임명장을 받은 하급 장교에게 “너는 현재 조종기 스틱을 읽을 권한이 없고, 고도를 마음대로 제어할 권한만 있다“고 세세한 액션 레벨의 스위치를 켜고 꺼주는 실무 권한(Authority) 위임장에 비유할 수 있다.

1. vehicle_control_mode.msg의 참/거짓 플래그 부울(Bool) 구조체

vehicle_control_mode uORB 메시지 구조체 파일을 열어보면, 복잡한 실수(Float) 연산이나 다차원 행렬 데이터는 단 하나도 찾아볼 수 없다. 오직 true 혹은 false 값만을 가지는 수십 개의 bool 타입 플래그(Flag)들이 스위치 패널처럼 빼곡하게 나열되어 있다.

대표적인 제어 권한 위임 플래그들은 다음과 같다:

  • flag_control_manual_enabled: 조종사의 RC 스틱이나 조이스틱 물리 입력을 연산에 허용할 것인가?
  • flag_control_auto_enabled: 컴퓨터(GCS 미션이나 컴패니언 비전 센서)가 내리는 자동화 궤적 명령을 따를 것인가?
  • flag_control_rates_enabled: 기체의 3축 회전 각속도(Roll/Pitch/Yaw Rate) 제어 루프를 가동할 것인가?
  • flag_control_attitude_enabled: 기체의 3차원 절대 자세(Attitude 쿼터니언) 제어 루프를 가동할 것인가?
  • flag_control_velocity_enabled: 기체의 3차원 선형 속도(m/s) 제어 루프를 가동할 것인가?
  • flag_control_position_enabled: 기체의 3차원 절대 위치(Position) 제어 루프를 가동할 것인가?

2. Commander의 권한 배분과 FMM의 순응 체계

방구석에서 파일럿이 조종기 토글을 ’Position Mode(위치 유지 모드)’로 틱! 하고 내리면 어떤 식으로 이 부울 플래그들이 세팅될까?

  1. Commander의 매핑(Mapping): Commander 데몬은 nav_state = POSITION 이라는 요구사항을 접수하면, 자신의 내부에 하드코딩된 규칙 테이블을 뒤진다. “포지션 모드이므로 조종기 스틱을 먹게 해줘야 하고(flag_control_manual_enabled = true), 조종사가 스틱을 놓았을 때는 그 자리에 멈춰 서 있도록 속도와 위치 제어기를 켜줘야겠군(flag_control_velocity_enabled = true, flag_control_position_enabled = true).” 이렇게 수십 개의 스위치 단자들을 조합하여 vehicle_control_mode 토픽으로 한방에 퍼블리시(Publish)한다.
  2. FMM의 권한 심사 통과: Flight Mode Manager (FMM) 데몬은 깨어나서 이 권한 위임장을 열어본다. FMM 내부의 FlightTaskManualPosition (수동 위치 제어) 객체는 자신이 계산을 시작하기 앞서 이 권한 플래그들을 검열한다. 만약 어찌 된 영문인지 flag_control_position_enabled 가 false로 상부에서 막혀 내려왔다면, FMM은 “나는 위치를 산출하는 태스크인데, 상부에서 위치 제어 권한 스위치를 꺼놨네? 그럼 난 아무 계산도 안 하고 리턴할게.” 하며 제어 산출을 보이콧해버린다.

3. 계층적 제어 아키텍처의 디커플링(Decoupling) 마법

이토록 깐깐하게 수십 개의 부울(bool) 플래그를 두어 권한을 쪼개놓은 PX4 아키텍처의 가장 위대한 성취는 **루프 모듈 간의 완벽한 디커플링(Decoupling)**이다.

  • Ardupilot의 모놀리식 한계:
    과거 Ardupilot의 mode.cpp 코드 덩어리는 하나의 함수 안에서 위치도 계산하고 속도도 조절하고 각도도 비틀며 모터 출력을 관장했다. 하나의 C++ 덩어리 안에서 코드가 엉켜있어 어느 한 곳이 고장나면 드론 전체가 통째로 추락했다.
  • PX4의 독립적 파이프라인 방어막:
    vehicle_control_mode 플래그 위임 시스템 하에서, 만약 사용자가 ’Acro(수동 곡예) 모드’를 켰다고 가정하자. Commander는 오직 각속도(flag_control_rates_enabled)만 true로 주고 윗단 비행 모드(FMM)의 위치/속도 플래그는 모두 false로 잠가버린다.
    이 경우, 하단의 mc_rate_control(각속도 제어 데몬)은 쌩쌩하게 모터 출력을 내보내지만, 상단의 무거운 FMM 데몬이나 mc_pos_control(위치 제어 데몬)은 자신이 받은 권한(flag_..._position/velocity)이 false임을 확인하고 CPU 사이클을 즉시 슬립(Sleep) 반환시키며 휴업에 들어간다.

결과적으로 조종사가 아크로(Acro) 묘기를 부리며 미친 듯이 드론을 뒤집을 때, 최상단 FMM에서 버그가 터지든 위치 센서가 폭발하든 간에 시스템 아키텍처상으로 각속도 제어 파이프라인과 완벽히 격리(Isolation)되어 있으므로 기체는 절대 추락하지 않고 기초 생존 물리법칙에 의해 파일럿의 손가락 입력을 든든하게 추종할 수 있게 된다.