The moment a UAV lifts off, the unit controlling it gains an asymmetric intelligence advantage — provided that information reaches every relevant operator. The operational failure mode is not a lack of drone coverage: it is the drone operator narrating what they see over voice radio while everyone else works blind in their GCS or ATAK screens. Drone telemetry TAK integration closes that gap by feeding the UAV's position, gimbal angle, and video feed directly into the common operating picture so every ATAK client in the network sees the drone as a live track alongside friendly forces.
This article walks through the full technical pipeline: MAVLink telemetry from the drone to a ground control station (GCS), conversion to Cursor on Target (CoT), forwarding to TAK Server, video relay, gimbal footprint encoding, reverse waypoint synchronization, bandwidth optimization for MANET radios, and multi-drone management conventions. All components described are open or commercially available — the architecture is implementation-neutral.
Why drone-COP integration matters: the context-switching problem
A typical small-unit UAV operation involves at least three distinct operator roles: the drone pilot watching the GCS video feed, the ground force commander working the ATAK map, and a sensor operator monitoring the camera. Without integration, each role operates from a different data source. The pilot knows where the drone is; the commander does not, unless the pilot narrates. When the pilot goes heads-down to fly a manoeuvre, the narration stops. Ground forces have no track — they cannot see the drone's coverage area, they cannot tell when the sensor is looking at a target, and they cannot push a new waypoint without finding the pilot and asking verbally.
UAV ATAK integration replaces voice coordination with data. The drone appears as a moving air track on the ATAK map. The gimbal footprint — a polygon showing exactly what the sensor is looking at — updates in real time. The video stream is one tap away in the ATAK Video Receiver. A commander can push a new loiter point from the map without finding the pilot. The pilot sees the updated mission on the GCS. This is not a quality-of-life improvement: in contested urban terrain with communications discipline enforced, it is the difference between coordinated ISR and guesswork.
MAVLink telemetry pipeline: drone to TAK Server
The pipeline has five stages: drone autopilot → radio data link → GCS (QGroundControl or Mission Planner) → MAVLink bridge process → TAK Server.
MAVLink protocol basics. MAVLink is the dominant telemetry and control protocol for small UAS. It is a lightweight binary protocol designed for low-bandwidth, lossy radio links. Version 2 (MAVLink 2) is the current standard and adds packet signing and a larger message ID space. A MAVLink stream from a typical autopilot (ArduPilot, PX4) includes GLOBAL_POSITION_INT at 2–10 Hz, ATTITUDE at 10–50 Hz, HEARTBEAT at 1 Hz, MOUNT_ORIENTATION at 10–25 Hz (if a gimbal is fitted), and MISSION_ITEM_INT on request.
GCS as telemetry router. The GCS receives the MAVLink stream over the radio data link — typically a 900 MHz or 2.4 GHz radio modem, an LTE dongle, or a mesh radio in infrastructure mode. QGroundControl and Mission Planner both support MAVLink forwarding: configuring a secondary UDP output to localhost:14551 (or a remote IP) delivers the full stream to any process on the GCS machine without interfering with the primary GCS connection.
MAVLink-to-CoT bridge. The bridge process reads the forwarded MAVLink stream and converts each position report to a CoT XML event. Key mapping: GLOBAL_POSITION_INT.lat / lon / alt → CoT <point> lat/lon/hae; GLOBAL_POSITION_INT.hdg → CoT <detail><track course=... />; ATTITUDE yaw → track heading fallback. Several open-source bridges exist — MAVLink2TAK (Python), UASLINK (C++) — or you can implement a lightweight bridge in Go or Rust for a production deployment where resource constraints matter.
TAK Server delivery. The bridge connects to TAK Server over TCP/TLS on port 8089 using a client certificate. It sends CoT events as streaming XML — one event per TCP send, no framing delimiter. TAK Server immediately federates the events to all connected ATAK, WinTAK, and CloudTAK clients subscribed to the drone's group.
CoT message structure for air tracks
Getting the CoT type code right is important — it controls the icon ATAK renders and the track colour. For a friendly fixed-wing unmanned aircraft the type is a-f-A-M-F-Q. Decoded: a = atom (real-world entity), f = friendly, A = air domain, M = military, F = fixed-wing, Q = unmanned. For a friendly rotary-wing drone: a-f-A-M-H-Q. For an unknown contact: replace f with u.
The how field should be m-g (machine-generated, GPS) — this tells ATAK clients the position is autonomous sensor data, not a human-entered estimate. The stale time (stale attribute on the <event> element) should be set 20–30 seconds ahead of the event time for a drone flying at typical reconnaissance speeds. A stale time that is too short causes the track to disappear during momentary telemetry gaps; too long leaves ghost tracks on the map after the drone has landed or moved significantly.
A minimal CoT event for a drone position report:
<event version="2.0"
uid="DRONE-ALPHA-01"
type="a-f-A-M-F-Q"
how="m-g"
time="2026-05-29T10:00:00.000Z"
start="2026-05-29T10:00:00.000Z"
stale="2026-05-29T10:00:25.000Z">
<point lat="48.3794"
lon="31.1656"
hae="250.0"
ce="5.0"
le="10.0"/>
<detail>
<contact callsign="ALPHA-1"/>
<track course="045.0" speed="18.5"/>
<remarks>MAVLink sysid=1</remarks>
</detail>
</event>
The ce (circular error) and le (linear error) values should reflect actual GPS accuracy from the autopilot's GLOBAL_POSITION_INT message — ATAK uses these to render the accuracy ring around the track icon.
Video streaming integration: RTSP to ATAK
Most small UAS payloads encode video in H.264 or H.265 and expose it as an RTSP stream over the data link. The integration path: drone camera → onboard encoder → RTSP over data link → GCS → FFmpeg relay → ATAK Video Receiver.
FFmpeg relay. On the GCS machine, FFmpeg receives the RTSP stream from the drone and re-streams it in a format optimized for ATAK delivery. For UDP multicast (LAN/MANET distribution): ffmpeg -i rtsp://192.168.1.100:554/stream -c copy -f mpegts udp://239.2.3.1:1234. For unicast to a specific ATAK device or TAK Server relay: -f rtsp rtsp://localhost:8554/drone-alpha. The key parameter is -c copy — transcode only when you must, because transcoding adds latency and CPU load on the GCS.
ATAK Video Receiver configuration. ATAK clients do not need manual video configuration when the pipeline is set up correctly. The bridge publishes a CoT event of type b-i-x-i (video alias) containing the stream URL, protocol, path, and a human-readable alias. When this event arrives at an ATAK client, the Video Receiver plugin automatically adds the stream to its source list. Operators tap the drone track icon and select "View Video" — ATAK opens the stream inline.
Degraded link adaptation. When the data link is saturated or range-limited, video quality degrades before the telemetry link drops. Configure FFmpeg to accept a lower-quality feed from the drone encoder (or trigger the encoder to reduce bitrate via MAVLink parameter CBRN_VIDEO_BITRATE on ArduPilot). At 500–800 kbps, H.264 delivers workable reconnaissance video at 720p/15fps. Below 300 kbps, consider switching to a lower-resolution JPEG snapshot stream published as a CoT sensor point rather than a live video, to preserve telemetry bandwidth.
Gimbal and sensor overlay: encoding the FOV polygon
The drone's position on the map tells operators where the UAV is. The gimbal footprint polygon tells them what the sensor is covering — a far more operationally useful piece of information. Computing the footprint requires: drone position (lat/lon/HAE), gimbal pan angle (azimuth from north), gimbal tilt angle (depression from horizontal), camera horizontal and vertical field of view (degrees), and a flat-earth approximation or WGS84 projection for the polygon vertices.
For a nadir-pointing camera at altitude H with a horizontal FOV of θ_h and vertical FOV of θ_v, the footprint is a rectangle. For an oblique angle, the footprint is a trapezoid. The bridge computes the four corners, encodes them as a CoT GeoObject polygon:
<event type="u-d-f" uid="DRONE-ALPHA-01-FOV" ...>
<detail>
<shape>
<polyline closed="true">
<vertex lat="48.3802" lon="31.1641"/>
<vertex lat="48.3802" lon="31.1671"/>
<vertex lat="48.3786" lon="31.1671"/>
<vertex lat="48.3786" lon="31.1641"/>
</polyline>
</shape>
<color argb="-2130706433"/>
<strokeColor value="-16711936"/>
<fillColor value="570556928"/>
<remarks>ALPHA-1 gimbal FOV</remarks>
</detail>
</event>
The FOV polygon UID is derived from the drone's UID with a suffix (-FOV) so ATAK clients can associate the polygon with the parent track. Update the polygon with every MOUNT_ORIENTATION message — typically 10–25 Hz — so operators see the gimbal sweeping in real time. Throttle to 2–5 Hz over constrained radio links. Use a stale time of 5 seconds on the polygon so it disappears if the gimbal telemetry is lost, preventing stale footprints from misleading operators.
Waypoint synchronization: from ATAK back to the GCS
Bidirectional integration — operators pushing tasking from ATAK to the drone — is the most operationally significant capability and the most technically complex. The reverse path: ATAK operator draws a route → ATAK publishes a CoT route event to TAK Server → bridge receives the route → converts CoT waypoints to MAVLink MISSION_ITEM_INT → uploads mission to GCS → GCS pushes to drone.
CoT route events. When an ATAK operator draws a route and sends it to the drone's UID, ATAK publishes a b-m-r (route) CoT event containing an ordered list of <point> elements. The bridge subscribes to CoT events from TAK Server filtered by the drone's UID and handles incoming route events.
MAVLink mission upload protocol. The upload is a request-response handshake: bridge sends MISSION_COUNT, drone ACKs, drone requests each MISSION_ITEM_INT by sequence number, bridge sends each item, drone sends MISSION_ACK on completion. Implement a timeout-and-retry on each step — radio link dropouts are common and the mission upload must be reliable. After successful upload, the bridge publishes a CoT remark event to TAK Server confirming the mission was accepted, with a timestamp.
Coordinate system note. MAVLink MISSION_ITEM_INT uses the MAV_FRAME_GLOBAL_RELATIVE_ALT frame by default — altitude relative to the home point set when the drone armed, not absolute HAE. CoT uses HAE (height above ellipsoid, WGS84). The bridge must convert: HAE → (HAE − home_HAE) = relative altitude. Source the home altitude from the GLOBAL_POSITION_INT stream at arm time or from the HOME_POSITION MAVLink message.
Low-bandwidth optimization for MANET radios
MANET radios used in dismounted operations — Persistent Systems MPU5, Silvus StreamCaster, Harris FALCON IV — provide 1–20 Mbps of shared bandwidth across all nodes in the mesh. A single drone integration adding 5–10 Hz position updates, a video stream, and 10–25 Hz gimbal polygon updates can consume a disproportionate share of the budget and degrade the situational awareness of ground forces who depend on the same radio.
Track update rate throttling. At 1 Hz, a drone moving at 20 m/s moves 20 m between updates — acceptable for an air track that operators are not placing precision fire against. At 0.5 Hz, the track lags enough to be misleading during turns. 1 Hz is a reasonable default for most ISR applications over constrained links; increase to 2 Hz for close-support scenarios where the drone position is directly correlated with ground action.
Binary CoT vs XML CoT. TAK Server 4.x and recent ATAK builds support protobuf-encoded CoT (binary CoT), which reduces message size by 55–65% compared to XML CoT. For a position update that weighs ~400 bytes in XML, binary CoT is approximately 150 bytes. At 1 Hz for 4 drones, this saves ~1 Mbps of radio bandwidth — meaningful on a 5 Mbps MANET link shared among 20 nodes. Enable binary CoT by configuring the TAK Server input connector and updating the ATAK preferences on client devices.
Video quality management. Video is by far the largest consumer. A 720p H.264 stream at 2 Mbps for a single drone consumes 40% of a 5 Mbps MANET link. Use RTSP unicast rather than multicast when only one or two operators need the video — multicast delivers to all nodes regardless of whether they are watching. Implement a simple request-to-view mechanism: operators request the video via a CoT message, the GCS side unicasts only to requesting clients.
Key insight: Drone-COP integration is a radio budget problem as much as a software problem. Model your MANET link budget before deployment — account for telemetry, video, ground force CoT, voice, and overhead. A drone integration that works on a benchtop with a LAN switch will degrade gracefully or catastrophically over radio depending on whether the bandwidth was planned.
Multi-drone handling: callsign conventions and group management
Operating more than two drones simultaneously — whether a coordinated ISR swarm or multiple independently tasked platforms — introduces deconfliction challenges on the ATAK map. Without discipline, multiple drone tracks with similar icons and no clear labelling create confusion about which drone is covering which area.
CoT UID and callsign conventions. Each drone must have a globally unique CoT UID — use a structured scheme that embeds unit, role, and serial: UNIT-ROLE-SERIAL (e.g., 3PLT-ISR-01, 3PLT-ISR-02). The callsign, displayed on the ATAK map label, should follow the same convention and match voice radio callsigns used by the unit. Avoid generic callsigns like "Drone 1" — in a battalion-level operation with 10+ UAVs in the air, there will be multiple "Drone 1" tracks and operators will not know which belongs to which unit.
CoT group assignments. TAK Server groups control which clients see which tracks and allow operators to show/hide subsets of the picture. Assign drones to the same group as the ground unit they are supporting — a platoon's organic UAV goes in the platoon group, not the battalion group, so platoon operators see it by default without filtering. Cross-attach drones to higher groups when the picture needs to roll up to the company or battalion COP.
MAVLink bridge drone registry. When multiple GCS instances report to the same TAK Server, the bridge on each GCS must use a drone registry — a persistent map of MAVLink system IDs to CoT UIDs — to ensure consistency. Two bridges both reporting system ID 1 with different UIDs will create duplicate tracks. The registry is a simple JSON or SQLite file; it should be pre-populated before deployment and stored centrally to avoid conflicts when GCS personnel rotate.
Swarm awareness at scale. For operations with more than 5–6 drones in the air simultaneously, consider adding a dedicated drone management overlay — a custom ATAK plugin or WinTAK component that displays all drone tracks with their battery state, mission status, and video availability in a tabular format alongside the map. Pure map-based management becomes unwieldy above 4–5 simultaneous tracks in a compressed battlespace. WinTAK's larger screen real estate makes it the preferred platform for this role.