28.5.1.2 `flag_control_velocity_enabled`: 속도 제어 루프 진입 조건 및 로컬 프레임 매핑

28.5.1.2 flag_control_velocity_enabled: 속도 제어 루프 진입 조건 및 로컬 프레임 매핑

PX4-Autopilot의 다이내믹스 제어 계층에서 속도(Velocity) 제어는 위치 제어(어디로 갈 것인가)와 자세 제어(기체를 어떻게 기울일 것인가)를 이어주는 가장 핵심적인 “중간 매개(Middle-ware) 루프” 역할을 담당한다. vehicle_control_mode.msg에 포함된 flag_control_velocity_enabled 플래그는 기체가 3차원 공간 속도 벡터를 목표로 하여 가속도 지령을 생성하는 로직을 활성화할 권한을 부여한다.

본 절에서는 해당 속도 제어 플래그의 진입 조건과 위치 제어기 내부에서의 로컬 프레임(Local Frame) 속도 매핑 원리를 상세히 다룬다.

1. 개요 및 발동 조건(Activation Conditions)

속도 제어 루프가 켜지는 상황은 크게 두 가지로 분류될 수 있다.

  1. 위치 제어(Position Control)의 하위 종속 계층으로서의 활성화:
  • 앞선 절에서 보았듯, flag_control_position_enabled가 true이면 목표 위치를 향해 기체가 이동해야 하므로, 시스템(비행 모드 관리자)은 필연적으로 flag_control_velocity_enabled 역시 강제로 true로 설정한다.
  • 이 경우 속도 셋포인트(Setpoint)는 조종기 스틱이 아닌, 상위 위치 제어기(P-Controller)의 산출값이 된다.
  1. 독립적인 속도 제어 모드 (Velocity-only Control):
  • 오프보드(Offboard) 모드에서 ROS2 컴패니언 컴퓨터가 절대 위치 좌표가 아닌, “앞으로 2m/s, 우측으로 1m/s로 이동하라“는 순수 속도 셋포인트(trajectory_setpoint) 만을 퍼블리싱할 때 발동한다.
  • 일부 광학 거리 센서(Optical Flow) 기반의 실내 비행 환경에서는 전역적인 X, Y 위치 추정값(Position Validity)을 얻지 못하지만, 지면 대비 상대적인 이동 속도는 정밀하게 추정할 수 있다. 이때 PX4 커맨더는 Position 플래그는 false로 둔 채 Velocity 플래그만 단독으로 열어주어, ‘바람에 밀리지 않는(Drift-free)’ 속도 유지 비행을 조종사에게 제공할 수 있다.

2. 로컬 프레임(NED) 매핑 아키텍처

PX4의 다단 루프 제어기(mc_pos_control) 내부에서 연산되는 속도는 기본적으로 NED(North, East, Down) 규약에 따른 로컬 프레임(Local Frame) 을 기준으로 한다.

  • 기체 기준(Body Frame) vs 로컬 지구 기준(Local Frame): 조종사가 스틱을 밀면 이는 기수(Nose) 방향인 기체 기준(Body X, Y)의 커맨드로 인식되기가 쉽다. 그러나 바람이 불거나 기수가 틀어진 상태에서 절대 공간을 제어하기 위해서는 수학적 변환이 필요하다.

  • 좌표 변환(Coordinate Transformation):
    스틱 입력이나 오프보드 지령은 시스템 진입 즉시 편각(Yaw angle, \psi) 회전 매트릭스를 거쳐 로컬 NED 프레임 속도 지령(\mathbf{v}_{sp}^{NED})으로 사영(Mapping)된다.

    \begin{bmatrix} v_{sp, N} \\ v_{sp, E} \end{bmatrix} = \begin{bmatrix} \cos\psi & -\sin\psi \\ \sin\psi & \cos\psi \end{bmatrix} \begin{bmatrix} v_{sp, BodyX} \\ v_{sp, BodyY} \end{bmatrix}

결과적으로 속도 컨트롤러는 항상 북쪽(North), 동쪽(East)으로 몇 m/s로 이동할 것인가를 계산의 기준으로 삼는다.

3. 속도 제어에서 가속도 지령으로의 변환 (PID Controller)

플래그가 켜져 속도 제어 루프(updateVelocityController())가 가동되면, 비례-적분-미분(PID) 연산이 본격적으로 시작된다.

  1. 오차 산출: 목표 로컬 속도(\mathbf{v}_{sp})와 EKF2가 추정한 현재 기체의 로컬 속도(\mathbf{v})의 차이를 구한다. (\mathbf{e}_v = \mathbf{v}_{sp} - \mathbf{v})
  2. PID 연산 (가속도 지령 도출):
    속도를 제어하기 위해서는 기체의 추진 시스템을 통해 ‘힘(Force)’, 즉 가속도를 발생시켜야 한다.

\mathbf{a}_{sp} = K_{p,vel} \mathbf{e}_v + K_{i,vel} \int \mathbf{e}_v \, dt + K_{d,vel} \frac{d\mathbf{e}_v}{dt} + \mathbf{a}_{ff}

  • 여기서 K_{p,vel}, K_{i,vel}, K_{d,vel}은 각각 파라미터 MPC_XY_VEL_P, MPC_XY_VEL_I, MPC_XY_VEL_D로 매핑되는 게인이다.
  • \mathbf{a}_{ff}는 가속도 피드포워드(Feed-forward) 텀으로 임무(Mission) 궤적 추종 시 급격한 코너링 성능을 높이는 데 쓰인다.
  1. 한계치 제한(Jerk & 가속도 Saturation): 산출된 가속도가 기체의 물리적 한계(MPC_ACC_HOR_MAX 등)를 넘지 않도록, 그리고 움직임이 버벅거리지 않도록 저크(Jerk, 가속도의 미분) 제한 알고리즘이 궤적 생성기(Trajectory Generator)와 연동되어 작동한다.

3. 하위 계층으로의 위임 (가속도 \rightarrow 자세 제어)

속도 루프가 종료되면, PX4 제어기는 “원하는 목적 속도를 달성하기 위해서는 3D 공간 상에 이만큼의 벡터 방향 가속도(\mathbf{a}_{sp})가 필요하다“라는 결론을 도출한다.

멀티로터의 물리적 구조 상 이 가속도(수평 방향의 힘)를 만들어내는 유일한 방법은 로터의 추력 벡터(Thrust Vector)를 원하는 방향으로 기울이는(Tilt) 것이다. 따라서 mc_pos_control 모듈 마지막 단락에서 역학 변환(Kinematic Conversion)을 거쳐 이 3D 가속도 지령을 기체의 목표 롤(Roll), 피치(Pitch) 각도(Attitude Setpoint) 및 추력(Thrust) 으로 변환하여 퍼블리싱한다.

이후 제어 권한은 하위 체인인 자세 제어기(mc_att_control)로 넘어가게 되며, 이를 위해 필연적으로 vehicle_control_mode.msg의 다음 플래그인 flag_control_attitude_enabled가 동반 활성화되어 있어야만 한다.

4. ArduPilot (Guided 모드)과의 비교

  • PX4-Autopilot (Offboard 속도 제어): 매우 일관된 MAVLink 스트림이나 ROS2 토픽 처리를 요구한다. vehicle_control_mode 내에 속도 플래그만 단독으로 켜져 있을 때, mc_pos_control은 P-Controller(위치 루프) 연산을 바이패스하고 PID-Controller(속도 루프) 내부로 직행하는 극도의 모듈화 된 아키텍처를 보여준다.
  • ArduPilot (Guided 모드 - 속도 제어 타겟): 지상 관제소(GCS)에서 MAVLink의 SET_POSITION_TARGET_LOCAL_NED 메시지를 받아 속도 커맨드로 변환한 후, mode_guided.cpp가 속도 컨트롤러인 pos_control->set_desired_velocity_xy() 계층을 순차적으로 호출하여 제어 객체의 속성값을 갱신해나가는 방식이다. C++ 객체의 결합도(Coupling) 측면에서 PX4에 비해 비교적 강게 결합되어 있다.