Integrating Gimbal Cameras with ArduPilot and PX4 over MAVLink

On an ArduPilot or PX4 aircraft, the gimbal camera stops being a pilot accessory and becomes a mission-system component — pointed by waypoints, triggered by the autopilot and reporting angles back over MAVLink. Integration quality depends on the payload’s protocol support, not its optics.

• 3 tiersRC, MAVLink v2, vendor SDK
• v2Gimbal protocol to ask for
• Angle feedbackWhat geotagging needs
• Bench firstWhere conventions get found

The Control Paths Available

RC passthrough is the simplest: S.BUS or PWM channels mapped through the autopilot to the gimbal. The autopilot is a wire rather than a controller, and the pilot’s transmitter drives the payload. It works immediately and cannot do anything the pilot does not command.

MAVLink gimbal protocol v2 is the standardised path — angle control, operating modes and device discovery, all defined by the protocol rather than by the vendor. This is what lets an autopilot point the camera at a waypoint and know where it is pointing, and it is the tier most integrators should be asking for by name.

Vendor serial SDK gives full function access: zoom, tracking, palettes, recording — everything the payload can do rather than everything the protocol standardises. The interface comparison covers the electrical side of each.

Serious integrations combine MAVLink for pointing with SDK for camera functions. The autopilot owns where the camera looks, the companion computer owns what it does, and neither has to reimplement the other.

What to Verify Before Committing

Five items, and each has bitten someone at fleet scale.

Item	What to ask	Why it matters
Gimbal protocol version	Is MAVLink gimbal protocol v2 supported?	v1 lacks device discovery and clean mode handling
Angle feedback	Does the payload report actual angles back?	Geotagging and geolocation are impossible without it
Camera trigger path	MAVLink command, PWM, or SDK call?	Trigger latency breaks mapping overlap
Coordinate frames	How is mount orientation configured?	Wrong convention mirrors your pointing
Serial update rate	What rate limits apply on the link?	Busy links starve the gimbal stream

Ask for the protocol document before ordering — its existence and quality predict the whole integration, as supplier evaluation covers. The integration checklist covers the mechanical and electrical groundwork that has to be right before any of this matters.

Common Failure Modes

Mixed-up mount yaw conventions producing mirrored pointing. The payload and the autopilot disagree about which way is positive, so commanding right slews left. Trivial to fix once identified and genuinely confusing for an afternoon, because everything else works perfectly.

RC and MAVLink fighting for control authority. Two sources commanding the same axis with no defined arbitration produces a gimbal that twitches, drifts back, or ignores one input unpredictably. Establish the arbitration rules on the bench, not at altitude.

Trigger latency breaking mapping overlap. If the camera fires meaningfully after the autopilot asked, the photo is taken somewhere other than the planned station, and overlap degrades across the whole survey. Measure the actual delay rather than assuming it is negligible.

Telemetry rates starving the gimbal stream on busy links. A link already carrying attitude, GPS, battery and status has finite bandwidth, and gimbal messages are usually what gets dropped. The symptom looks like sluggish pointing and is really a bandwidth problem.

Geotagging and Geolocation

Angle feedback is the item most often skipped and most consequential for mission-system work. Without it the autopilot knows where the aircraft was and nothing about where the camera was pointed, which makes photo geotagging approximate and target geolocation impossible.

With angle feedback plus a rangefinder, the chain closes: aircraft position, gimbal pitch and yaw, and slant range resolve to a target coordinate. On LRF-equipped payloads the range output over the serial link can be consumed by a companion computer for exactly this — why an LRF belongs on your payload covers the chain and the geolocation error budget covers which term dominates.

Note that boresight alignment matters here too. The angles reported are gimbal angles; converting them into camera pointing assumes the camera axis and the gimbal reference are aligned, which is a factory property — see boresight alignment.

Planning the Integration

A sequence that avoids the expensive discoveries.

1. Confirm which control tier your mission actually needs before shopping — RC passthrough may be sufficient and is far quicker.
2. Request the protocol document and MAVLink support statement for the exact variant, not the product family.
3. Bench the gimbal against your autopilot firmware: commanded angle versus reported angle, across the full travel.
4. Establish arbitration behaviour with both RC and MAVLink active simultaneously.
5. Measure trigger latency and check mapping overlap on a short real survey before flying a large one.
6. Verify telemetry rates hold with the full mission message load, not on a quiet bench link.

AX Series gimbals and the integrated payloads expose S.BUS, PWM and serial control suitable for autopilot integration. Describe your stack — AX-200T, OP-90A and LX-9B configurations differ in what is exposed — and confirm the control path and documentation for your configuration before ordering.

Related reading

• Payload Firmware Architecture
• Target Geolocation Error Budget
• Gimbal Control Interfaces Compared
• UAV Payload Integration: MAVLink, UART, S.BUS and Ethernet
• UAV Payload Integration Checklist
• An Integrator’s Checklist for Evaluating Suppliers
• Why a Laser Rangefinder Belongs on Your UAV Payload
• Gimbal Troubleshooting
• AX-200T — 3-axis gimbal
• OP-90A — multi-sensor pod with ranging
• LX-9B — multi-sensor pod
• Pipeline Monitoring UAV Payloads

FAQ

Do UAVThermal payloads work with ArduPilot and PX4?

AX Series gimbals and the integrated payloads expose S.BUS, PWM and serial control suitable for autopilot integration. What is available differs by configuration, so tell our engineers your stack — autopilot, firmware version and whether a companion computer is involved — and they will confirm the control path and documentation for your specific configuration rather than for the product family.

Can the autopilot read the laser rangefinder?

On LRF-equipped payloads the range output over the serial link can be consumed by a companion computer for geolocation workflows. Whether the autopilot itself ingests it depends on your stack and how you route the message. The more common architecture is a companion computer combining range, gimbal angles and aircraft telemetry, since that is where the coordinate arithmetic naturally lives.

Which control tier should I start with?

Whichever the mission actually needs. RC passthrough is simplest and sufficient for pilot-directed work; MAVLink gimbal protocol v2 is right when waypoints should point the camera and angles need to come back for geotagging; the vendor SDK is required for zoom, tracking and camera settings under software control. Most serious integrations end up combining MAVLink for pointing with the SDK for camera functions.

Questions about the technology? Talk to our engineers — we reply within 2 business days.