28.1.1.2. 사용자 입력(User Intent) 모델링 및 정규화(Normalization) 프로세스
비행 제어 시스템 아키텍처에서 조종사라는 존재가 쥐고 있는 RC 조종기(Radio Control)의 스틱은 하드웨어적으로 단순히 1000us에서 2000us 사이의 펄스폭 변조(PWM) 신호를 발생시키는 가변 저항(Potentiometer)에 불과하다.
이러한 파편화되고 기계적인 아날로그 신호를 비행 제어 스택 중간 계층이 온전히 이해할 수 있는 수학적 동역학 변수로 통역하기 위해서는, 그 사이에 인간의 마음(User Intent)을 기계 독립적으로 추상화하는 정규화(Normalization) 프로세스가 반드시 선행되어야 한다.
1. User Intent 추상화 아키텍처의 당위성
순정 PX4-Autopilot은 수많은 종류의 브랜드(Futaba, FrSky, Spektrum, TBS 등)에서 파편적으로 생산되는 RC 수신기의 다채로운 물리적 프로토콜(SBUS, DSM, CRSF)을 모두 백그라운드에서 지원한다.
만약 하위 제어기 로직이 이러한 송수신기의 하드웨어 특성값(PWM 1500us 중앙 영점 등)을 직접 참조하도록 코딩되어 있다면, 하드웨어가 조금만 수치적으로 틀어지거나 교체될 때마다 제어 코드를 통째로 뜯어고치는 소프트웨어적 재앙이 발생할 것이다.
더 나아가, 최신 자율비행 시스템에서는 비동기적으로 텔레메트리(Telemetry)를 통해 유입되는 MAVLink 조이스틱 원격 제어 명령 패킷(MANUAL_CONTROL)이나 모바일 앱(QGroundControl) 화면의 가상 스틱 데이터조차 물리적 조종기와 완벽히 동일한 체중의 스레드 방식으로 취급되어야만 한다.
이를 위해 PX4 시스템은 존재하는 모든 조종 매체의 물리적 및 논리적 1차원 입력값을 단일한 데이터 규격(Topology)인 manual_control_setpoint uORB 토픽 템플릿 하나로 강제 매핑(Mapping)시켜 통합해 낸다.
2. 정규화(Normalization) 축척 모델과 수식 메커니즘
manual_control_setpoint.msg 토픽 패킷 내부 메모리 구조를 런타임에 열어보면 이전 단계 하드웨어의 Raw PWM 펄스값은 이미 완벽히 소멸되어 흔적도 존재하지 않는다.
대신, 수학적으로 정규화된 4개의 비행 역학적 축(Axis) 변수가 다음과 같이 [-1.0, 1.0]의 플로팅 포인트(Float) 벡터 공간으로 이상적 추상화되어 존재한다.
- Roll (
y): -1.0 (최대 좌측 타각 지시) ~ 1.0 (최대 우측 타각 지시) - Pitch (
x): -1.0 (최대 하향 타각/전진 지시) ~ 1.0 (최대 상향 타각/후진 지시) - Yaw (
r): -1.0 (최대 좌측 회전율 지시) ~ 1.0 (최대 우측 회전율 지시) - Throttle (
z): -1.0 (최소 추력/하강) ~ 1.0 (최대 추력/상승). 단, Altitude 나 Position 같이 고도 중앙 유지가 지원되는 모드 로직이 삽입되면, 스프링 스틱이 놓이는 중앙점이 0.0을 마킹하게 된다.
2.1 정규화 캘리브레이션과 선형 보간 사상(Mapping)
조종기 캘리브레이션 단계(QGroundControl 셋업 마법사 활용)에서 영구 저장소에 기록된 각 채널의 RCx_MIN, RCx_MAX, RCx_TRIM (스틱 물리적 중앙 텐션값) 파라미터가 램(RAM) 영역에 상주한다.
센서가 실시간으로 수신하는 원시 데이터 input_rc 값을 파싱 변환 루프 단을 통과시킬 때, 이 파라미터 기반 선형 보간(Linear Interpolation) 함수를 태움으로써 모든 무질서한 입력 범위들을 [-1.0, 1.0] 정규화 구간의 고정 벡터 공간으로 압축 사상시킨다.
3. User Intent 파이프라인 흐름도 분석
flowchart LR
%% 물리적 입력 장치
Hardware_RC(RC 수신기 하드웨어 \n SBUS / CRSF)
GCS_Joy(GCS 물리 조이스틱 \n MAVLink)
Companion(Companion Computer \n ROS2 / OFFBOARD)
%% 파서 모듈 구역 (어댑터 패턴)
subgraph Input Parsing & Normalization
RC_Input[rc_input 드라이버 모듈 \n 파라미터 캘리브레이션 선형 보간]
MAV_Input[mavlink_receiver 데몬 \n 매핑 매트릭스 변환 맵 적용]
end
%% 중앙 정규화 단일 토픽
Normalized_Intent(( manual_control_setpoint \n [-1.0, 1.0] 차원 토픽 ))
%% 비행 모드로의 전달체 단위
Flight_Mode(Flight Mode Manager \n 특정 FlightTask 작동 구간)
%% 흐름 연결망 시각화
Hardware_RC --> RC_Input
GCS_Joy --> MAV_Input
Companion -.->|FlightTask 우회 직접 좌표명령 하달| Flight_Mode
RC_Input -->|Nomarlize & Scale| Normalized_Intent
MAV_Input -->|Nomarlize & Scale| Normalized_Intent
Normalized_Intent -->|"사용자의 방향성 의지 (Pure Intent)"| Flight_Mode
Flight_Mode --> |동력학적 위치/속성 램핑 스케일링| TARGET[trajectory_setpoint]
4. 중간 완충 버퍼(Buffer)로서의 아키텍처적 의의
결과적으로 Flight Mode 모듈은 지금 들어오고 있는 조종 신호 패킷이 2.4GHz 주파수 RC 안테나를 타고 들어왔는지, 아니면 LTE 모뎀을 넘어온 MAVLink 가상 조이스틱 데이터 스트림인지 출처(Source) 정보를 묻지도, 따질 필요도 스택 상에서 완전히 사라진다.
그저 중간 버퍼인 manual_control_setpoint 큐(Queue)에 고스란히 쌓여있는 [-1.0, 1.0] 사이의 수학적으로 깨끗한 Float 실수 행렬만을 읽어 들여서, 자신이 현재 담당하고 있는 제어 모드의 특성(예컨대 파라미터로 최대 속도 상한선이 5m/s가 지정된 모드 시스템이라면 이 1.0 벡터 공간을 5m/s로 곱셈 매핑 수행)에 맞추어 trajectory_setpoint의 순수 제어 타겟 구조로 이중 변환(Double Translation)하기만 하면 되는 것이다.
이처럼 무질서하고 거친 물리 입력(Raw Error Data)을 수학적으로 단정히 정돈된 추상 의도(User Intent)로 정규화해 내는 아키텍처적 미들웨어 장치가 코어 단에 존재함으로 인해, 조종기를 놓았을 때의 정지 안정감(Center Hovering Deadband)과, 급격한 턴 기동 시 비행의 쫀득한 조향성(Handling Qualities)을 결정짓는 스틱 엑스포넨셜 곡선(Exponential Curve) 필터링 등의 복잡한 인간 공학적(Ergonomic) 수학 처리가 백엔드 로직에 파편화되지 않고 일원화된 파이프라인 구간 안에서 매우 신뢰할 수 있게(Reliably) 수행될 수 있다.