Walk a fleet operator's hangar and count the vendor stacks. A pair of PX4-based fixed-wing surveillance platforms. A multirotor quadcopter running ArduPilot with a vendor-proprietary mission planner bolted on. Two Skydio X10s with locked-down autonomy stacks the operator cannot touch. Three DJI Matrice 350 RTKs whose flight controller is a black box. A ground robot speaking ROS 2 with rosbridge for the operator interface. A TAK server that the SAR team's tablets are talking to. A network of fixed thermal cameras the facility security contractor installed. Six payload cameras of three different vendors with three different gimbal protocols.
This is the actual installed base. Not the homogeneous fleet the integration slides assume.
Every coordination platform that ships needs an answer to this. Most of them give the wrong answer. The wrong answer is "standardize on our stack." The wrong answer takes various forms — replace your existing autonomy, run all your missions through our planner, swap your radios for our radios — but the structural property is the same: the coordination layer is asking the operator to abandon working hardware that the operator chose for specific reasons, and that the operator has trained crews around.
The right answer is an adapter-pattern architecture. The coordination layer sits above the vendor stacks, integrates with them at well-defined protocol boundaries, and does not replace the autonomy each vendor ships. That positioning matters because no fleet operator is going to standardize on a single vendor, and no operator should be forced to choose between best-of-breed hardware and coherent operations.
This post is about what that adapter pattern actually looks like in production, what it does and doesn't claim, and why this is the only architecture that survives contact with the real installed base.
What a bridge is, and isn't
In an adapter-pattern coordination architecture, every supported platform stack is integrated through a bridge. The bridge is a thin, well-typed translation layer that maps the platform's native telemetry, command, and state surface into the coordination platform's shared semantic representation. The bridge is not a rewrite of the autonomy. It is not a replacement of the flight controller. It is not a parallel command path that competes with the vendor's own.
A bridge for PX4 listens to MAVLink heartbeats from the flight controller, decodes velocity, heading, battery telemetry, and per-cell voltage from the standard MAVLink message families (HEARTBEAT, GLOBAL_POSITION_INT, BATTERY_STATUS, ATTITUDE), enriches that telemetry with platform-aware semantic claims (this asset is healthy, this asset is in cruise, this asset has 38 minutes of endurance under current load), and writes those claims into the shared field. When the coordination platform wants this asset to assume a role — cover sector C, hold at altitude 120m AGL, hand off contact to the next scout in 6 minutes — the bridge translates that role into the MAVLink command sequence the flight controller expects.
The flight controller does its job. The vendor's stack does its job. The bridge translates between vendor semantics and coordination semantics. What the bridge contributes is not autonomy. It is shared meaning.
ArduPilot is integrated the same way, with the small but real differences ArduPilot's MAVLink dialect requires. The two MAVLink-family adapters can share most of the implementation because both stacks converge on the same wire protocol, with the platform-specific overlays handled at the bridge boundary. The operator doesn't have to know which adapter is running for which asset. The coordination platform doesn't care which autonomy is underneath. Both are abstractions that the bridge resolves.
ROS 2 and rosbridge: when the asset isn't a UAV
The architecture matters more outside the air domain. Ground robots, manipulator arms, autonomous mobile robots, humanoids — the heterogeneous-fleet thesis only works if all of these can join the same coordination substrate as the drones.
ROS 2 is the standard middleware for most modern ground robotics, and the rosbridge JSON-over-WebSocket protocol is the standard bridge to and from non-ROS systems. A coordination platform that wants to integrate ground assets does it by speaking rosbridge to each robot's ROS 2 stack — subscribing to the robot's relevant topics (position, joint state, battery, current task), publishing to the robot's command topics (assigned task, allocated role, safety constraint), and translating between the robot's domain vocabulary and the shared field's vocabulary.
Notice what does not happen. The robot's manufacturer-supplied motion planner is not replaced. The robot's safety stack is not bypassed. The robot's vendor-specific calibration is not touched. The bridge maps the robot's command surface into the coordination layer's role-allocation system; the robot continues to execute its motion using the autonomy it shipped with.
This is what makes the platform genuinely vendor-agnostic, rather than just claiming to be. The vendor of the robot keeps writing the autonomy. The fleet operator keeps choosing the best robot for the task. The coordination platform adds the layer that lets those robots work as a coherent system without forcing any of them to be the same kind of robot.
TAK and the defense integration story
For defense and public-safety customers, the TAK ecosystem is the ground truth of operational tooling. ATAK on Android, WinTAK on Windows, iTAK on iOS, TAK Server at the team and detachment level. The protocol is Cursor on Target (CoT). The vocabulary is already standardized across coalition operators. Any coordination platform that wants to be deployed for defense customers needs to be a first-class CoT producer and consumer — not an adjacent app the operator has to switch out of TAK to use.
The bridge here translates between the shared semantic field and CoT messages. When the field carries a high-confidence claim — threat box at coordinates X, two tracks visible, no engagement authorized — the bridge emits the corresponding CoT message to the TAK server, where it appears on every TAK client in the network at the standard operational symbology. When a TAK operator marks a region as a no-go zone or an objective, the bridge ingests that CoT message and writes the corresponding constraint into the shared field, where every coordinated asset will respect it.
This is how the coordination platform plugs into the operational tooling the joint force is already using. No new app for the operator to learn. No second tablet. No duplicate situational picture. The shared field becomes the canonical operational picture, and TAK becomes one of the views into it.
What about vendor stacks the coordination platform can't bridge
There will always be some stacks the coordination platform can't bridge — either because the vendor explicitly locks the autonomy (Skydio's enterprise SDK is more open than its consumer products, but still constrained), or because the platform is too new for a bridge to exist yet, or because the operator has a one-off legacy system the bridge would never be worth building for.
The honest answer is that those assets participate at the sensor-only tier. The coordination platform can receive their telemetry, treat them as observers in the shared field, and route their observations into the planning and policy layers. What the platform cannot do is allocate roles to them or task them directly. The vendor's autonomy continues to fly the platform on its own terms; the platform's outputs become inputs to the shared field.
For most fleet operators, this is fine. The locked vendor platforms are usually the asset class that ships with the strongest native autonomy in its niche, and the operator chose it for exactly that reason. The coordination platform's job is to integrate that asset's outputs into the multi-asset picture, not to second-guess the asset's own autonomy. The sensor-only tier honors that boundary.
What the platform should not do, ever, is pretend the locked vendor stack is fully integrated when it isn't. Operators read the integration matrix more carefully than the marketing pages assume.
What the operator should look for in an integration matrix
A few honest evaluation criteria, separated from the slide-deck language:
Production bridge versus reference implementation. A production bridge is one the platform vendor is shipping to a paying customer running the platform in operations. A reference implementation is one the platform vendor has tested in their own lab. Both are useful; they are not the same thing. Ask which is which.
The bridge's coverage of platform-native autonomy. A PX4 bridge that supports waypoint navigation but not the platform's onboard obstacle avoidance is a different (and less useful) product than one that integrates obstacle avoidance into the platform's role allocation. Ask which features at the platform-native autonomy layer are surfaced to the coordination layer.
Bridge update cadence relative to the underlying platform. PX4 and ArduPilot both release on roughly six-month cycles. A bridge that lags six months is fine for stable operators; a bridge that lags two releases starts to be operationally significant. Ask how the platform vendor keeps bridges current.
Sensor-only fallback for unsupported platforms. Operators field assets the platform doesn't bridge. The honest answer is the sensor-only tier; the dishonest answer is "we'll add it when you sign." Ask about the fallback explicitly.
Identity, authentication, and audit at the bridge boundary. Every command crossing the bridge is an action the platform is responsible for. Every observation written through the bridge is an evidence event the platform is responsible for. Ask how the bridge authenticates its commands to the platform and how the bridge's contributions are signed into the evidence chain.
We publish our own integration coverage on the integrations page — production bridges for PX4, ArduPilot, ROS 2 (rosbridge), MAVLink (generic), TAK/CoT, plus sensor-only adapters for additional vendor platforms. The coverage is documented at the production-versus-reference distinction, with the caveats about locked vendor stacks made explicit.
Why this architecture is the long game
Hardware programs come and go. The drone the joint force fields in 2026 will not be the drone it fields in 2031. The robot the warehouse operator buys this year will be replaced by a better one next year. The vendor the SAR team chose for its airborne asset will pivot to a different market and stop supporting the model the team standardized on.
The orchestrator outlasts any single platform program. That is the structural argument for the adapter pattern. The coordination platform integrates new vendor stacks through the bridge layer without rearchitecting the substrate. Each new bridge expands the fleet the platform can coordinate. The coordination substrate itself stays stable across platform churn.
This is why almost every long-cycle infrastructure layer in computing — operating systems, browsers, databases, middleware — converged on the adapter pattern decades ago. The substrate that lasts is the substrate that integrates everything else without becoming brittle to any specific component. The substrate that does not last is the substrate that demands its own homogeneous stack.
The coordination layer for autonomous systems is going to follow the same pattern. The platform that owns the layer is the platform that integrates PX4, ArduPilot, ROS 2, MAVLink, TAK, and the next vendor stack that hasn't been built yet, through the same bridge architecture. The platform that owns the layer is the one whose substrate is stable enough to absorb the next decade of platform churn without breaking the fleets running on top of it.
That platform exists. It is live, it is shipping bridges, and it is integrating new platforms through the same well-typed boundary that handles every existing one.
If you're a fleet operator with a heterogeneous installed base, we'd like to talk. The architecture is built for exactly the fleet you have. Not the fleet the integration slides assumed.
The orchestrator the joint force is buying is the same architecture commercial fleets need.
The bridges are real.