Mission-driven gimbal control: PITCHYAW ignored because primary control stays 0/0 — has anyone solved this?

PX4 Autopilot
1

TL;DR: MAVLink v2 gimbal works perfectly under manual QGC control, but a mission DO_GIMBAL_MANAGER_PITCHYAW never moves the gimbal. Bench testing shows the reason: during the mission, gimbal primary control stays 0/0, so the manager ignores the mission’s pitch command. Has anyone gotten autonomous mission gimbal control working on PX4, and how did you get the mission to hold control authority?

Setup

  • Autopilot: Holybro Pixhawk 6X, PX4 v1.17
  • Gimbal: Gremsy Pixy LR (firmware 7.8.7), MAVLink v2 gimbal device, component ID 154. Gremsy confirmed it implements only the Gimbal Device interface (no onboard manager), so PX4 is the manager.
  • Camera/trigger: AirPixel TAG-E (shares TELEM2 via the gimbal’s MAVLink forwarding)
  • GCS: QGroundControl on Herelink
  • Connection: Gimbal direct on TELEM2

Relevant params:

  • MNT_MODE_IN = 4 (MAVLink gimbal protocol v2)
  • MNT_MODE_OUT = 2 (MAVLink v2)
  • MNT_MAV_SYSID = 1, MNT_MAV_COMPID = 154
  • MAV_1_CONFIG = 102 (TELEM2), MAV_1_MODE = 10 (Gimbal), MAV_1_FORWARD = 1
  • MIS_COMMAND_TOUT raised to allow slew time

What works

  • Manual control from QGC works flawlessly. Click “Acquire Control” → primary control becomes 255/190 → drag pitch to -90° → gimbal tilts down and holds.
  • Device discovery is healthy. gimbal status reports gimbal device compid found: 154, Input: Mavlink (Gimbal V2), Output: MAVLink gimbal protocol v2.
  • Streaming is correct. mavlink status streams shows, on the gimbal instance: AUTOPILOT_STATE_FOR_GIMBAL_DEVICE @ 20 Hz and GIMBAL_DEVICE_SET_ATTITUDE @ 20 Hz.

What fails

A mission with DO_GIMBAL_MANAGER_CONFIGURE (params -2, -2, -1, -1, 0, 0, 154 — “set self in control”) followed by DO_GIMBAL_MANAGER_PITCHYAW (-90, NaN, NaN, NaN, 0, 0, 154) does not move the gimbal.

Bench test that isolates the cause (no flight, no SD card)

  1. In QGC, Acquire Control → gimbal status shows Primary control: 255/190 → drag to -90° → gimbal moves. :white_check_mark: (device/link/pitch all good)
  2. Release control → gimbal status shows Primary control: 0/0. :white_check_mark:
  3. With control at 0/0, run the mission (takeoff → CONFIGURE → PITCHYAW -90 → hold → RTL). During the gimbal step: gimbal does NOT move, and gimbal status shows Primary control still 0/0 throughout. :cross_mark:

So the mission’s CONFIGURE never actually claims control — authority stays 0/0 — and the subsequent PITCHYAW is (correctly, per spec) ignored because the commanding component isn’t “in control.” The output block shows quaternion: [nan nan nan nan] at rest, consistent with “no authorized setpoint.”

What I’ve already checked / ruled out

  • Not the device, wiring, or firmware — manual control proves the full PX4→Gremsy path works; Gremsy is on their latest firmware (7.8.7) and confirmed device-only behavior at 154.
  • Not the pitch value — -90° is what manual control uses successfully.
  • Not streaming — AUTOPILOT_STATE_FOR_GIMBAL_DEVICE and GIMBAL_DEVICE_SET_ATTITUDE are both streaming at 20 Hz on the gimbal port.
  • Not SD-card/log dropouts — the bench test reads gimbal status live, so this is independent of logging.

I’m aware the PX4 mission-mode docs note that DO_GIMBAL_MANAGER_PITCHYAW / DO_GIMBAL_MANAGER_CONFIGURE are “parsed but not necessarily acted on.” That seems to match what I’m seeing — the mission CONFIGURE is parsed but doesn’t establish control authority.

Questions for the community

  1. Has anyone gotten autonomous mission-driven gimbal control (v2) actually working on PX4? If so, what made the mission hold primary control?
  2. Does a mission DO_GIMBAL_MANAGER_CONFIGURE reliably claim control on your setup, or is it a no-op? (i.e., does your gimbal status show 1/1 during a mission?)
  3. Is there a parameter or mechanism to make the autopilot the default/standing gimbal controller so primary control isn’t 0/0 at rest?
  4. Could QGC (Herelink) acquiring control on connect and then releasing to 0/0 be leaving no standing controller for the mission? Anyone worked around GCS acquire/release behavior?
  5. If the mission path genuinely can’t hold authority, is the accepted approach to command the gimbal from a companion computer that holds control, rather than via mission items?

Any confirmation, logs, param sets, or “here’s what I had to change” would be hugely appreciated. Happy to share full logs, gimbal status output, and mavlink status streams.

Thanks!