Edge AI

CGC Sentinel

Edge computer vision for drone operations, moving decisions closer to the camera and reducing network pressure.

Delivered edge architecture80% less bandwidthJuly 2026

CGC Sentinel

When connectivity is variable, the edge should decide what matters and the cloud should coordinate what happens next.

Edge computer vision for drone operations, moving decisions closer to the camera and reducing network pressure.

At a glance

  • Status: Delivered edge architecture
  • Architecture focus: Edge AI
  • Primary outcome: 80% less bandwidth
  • Stack: YOLO, TensorRT, Jetson, WebRTC, MQTT, Cloud control plane

The challenge

Cloud-only inference created latency and bandwidth constraints for live aerial operations in variable network conditions.

The architecture decision

Run optimized detection at the edge, transmit events and selected evidence, and reserve the cloud for fleet coordination and deeper analysis.

System architecture

Responsibility moves through explicit boundaries. Each layer has one primary job; policy, health, and trace signals span the system.

Architecture diagram

Open the standalone architecture and workflow diagrams.

Architecture layers

  1. Sensor plane — Drone cameras and telemetry produce high-rate visual and operational signals.
  2. Edge inference — YOLO models optimized with TensorRT run on Jetson-class hardware.
  3. Event policy — Confidence, class, location, and mission rules decide what is important.
  4. Transport — MQTT carries events while WebRTC provides live or requested visual evidence.
  5. Cloud control — Fleet state, mission policy, model rollout, and deeper processing live centrally.
  6. Operations UX — Operators see incidents, evidence, device health, and mission context together.

How the system works

Architecture diagram
  1. Observe locally — The edge node receives camera frames and telemetry without waiting for the network.
  2. Infer and filter — Optimized models detect events; mission policy removes low-value traffic.
  3. Transmit evidence — Small events move continuously while video is streamed only when operationally useful.
  4. Coordinate centrally — The cloud joins events across the fleet and supports operators, analytics, and model lifecycle.

Architecture decisions and trade-offs

ADR-01: Split decision and coordination planes

Time-sensitive recognition stays near the camera; fleet-wide context stays in the cloud.

Trade-off: Edge deployments are operationally harder, but the mission no longer depends on a perfect connection.

ADR-02: Events before raw video

The default payload is structured evidence with selected frames, not a permanent full stream.

Trade-off: Less raw data is centrally available, in exchange for major bandwidth and response-time gains.

ADR-03: Model lifecycle is centralized

Models execute locally but versions, rollout rings, health, and rollback are controlled centrally.

Trade-off: This requires a device-management plane, but prevents unmanaged model drift across a fleet.

Production qualities

  • Latency: Local inference avoids a network round trip for operational decisions.
  • Resilience: Store-and-forward events and local policy preserve useful behavior during outages.
  • Efficiency: Quantization, TensorRT optimization, event filtering, and adaptive streaming reduce compute and network load.
  • Safety: Human control remains explicit; AI findings support mission decisions rather than silently commanding them.

Outcomes

  • Approximately 80% lower bandwidth use
  • Roughly 60–70% lower decision latency
  • Continued operation under weak connectivity
  • Fleet-level visibility without cloud-only inference

Technology stack

  • YOLO
  • TensorRT
  • Jetson
  • WebRTC
  • MQTT
  • Cloud control plane

Related writing

Architecture diagrams

CGC Sentinel — Architecture Diagrams

System architecture

Architecture diagram

Layer responsibilities

  1. Sensor plane: Drone cameras and telemetry produce high-rate visual and operational signals.
  2. Edge inference: YOLO models optimized with TensorRT run on Jetson-class hardware.
  3. Event policy: Confidence, class, location, and mission rules decide what is important.
  4. Transport: MQTT carries events while WebRTC provides live or requested visual evidence.
  5. Cloud control: Fleet state, mission policy, model rollout, and deeper processing live centrally.
  6. Operations UX: Operators see incidents, evidence, device health, and mission context together.

Operating workflow

Architecture diagram

Workflow steps

  1. Observe locally: The edge node receives camera frames and telemetry without waiting for the network.
  2. Infer and filter: Optimized models detect events; mission policy removes low-value traffic.
  3. Transmit evidence: Small events move continuously while video is streamed only when operationally useful.
  4. Coordinate centrally: The cloud joins events across the fleet and supports operators, analytics, and model lifecycle.

Diagram notes

  • The solid arrows show the primary operating path.
  • Policy, security, health, telemetry, and trace signals apply across all layers.
  • The diagram defines responsibility boundaries; deployment topology may vary by environment.

Read the complete CGC Sentinel case study.