First Review

PolarisGCS Cloud Ground Control System

A proposed cloud console to plan, launch and watch a mixed fleet of real and simulated drones - with every aircraft moving through one identical path.

Team members: Krish Chauhan (23BRS1187), Arhaan Penwala (23BRS1155), Ananya Shailesh (23BRS1200) Guide: Suganaya G Guide's signature: _______
VIT Chennai Logo
01 / 16

Problem

Most drone software is stuck on local laptops

As fleets grow, using different desktop apps for different drones creates dangerous data silos and safety bottlenecks.

Hobbyist & Long-Range
Radio-Controlled Drones
Connected via narrow-band radios.Controlled by basic desktop apps.
Flight logs stay trapped on the pilot's laptop.
Industrial & Commercial
High-Bandwidth Drones
Equipped with rich payloads (Video, LiDAR).Controlled by proprietary software.
Data cannot be easily shared with the fleet.
The Core Bottleneck
Isolated Local GCS
Pilots use disconnected screens.No single source of truth.
Fleet coordination becomes blind and unsafe.
02 / 16

Problem

The radio runs out before the software does

One 915 MHz channel, shared by every drone on it. Drag the slider.

Drones sharing one channel 4
5.0 Hz per drone
Full rate Degraded Unsafe
Comfortable. Every aircraft reports position, altitude and battery fast enough to fly on.
  • 01A fixed budgetSplitting bandwidth evenly across N aircraft is the whole story - nothing returns the lost slots.
  • 02Below 1 Hz, you're flying the pastA drone at 12 m/s has already moved 12 metres between two position reports.

The real question isn't how many drones fit on a map. It's who decides, continuously, which aircraft gets the bandwidth right now.

03 / 16

Literature review · 2023–2026

What the field has already settled

15 peer reviewed papers. Select a row - scroll for more.

Row 1 is the base paper for this project.

04 / 16

Literature review · base paper and gap

Where it stops, and where we start

Base paper
Ground Control Station for Multi-UAV Systems in Infrastructure Inspection and Environmental Monitoring Applications
Poma, Sojo, Maza and Ollero
Journal of Intelligent & Robotic Systems, Springer, 2025
An open source ground station between a Control Centre and a heterogeneous UAV fleet: task intake, mission planning, coordinated execution, results back. Validated on real tower and power line inspections. It proves the right shape for the problem - an application agnostic layer, not a per-autopilot tool. We propose keeping that shape and moving it to the cloud.
doi: 10.1007/s10846-025-02312-6
Left open
Runs on site, one team, one location.
→
We propose
A cloud backend with multi-tenant accounts; gateways pair by token from anywhere.
Left open
Assumes each vehicle already has an adequate link.
→
We propose
A two-tier radio model that budgets a shared channel automatically, in flight.
Left open
Simulation sits apart from the flight stack.
→
We propose
A parity rule enforced in code: no branch anywhere may ask if a drone is simulated.
Left open
No stated readiness contract before launch.
→
We propose
Launch stays disabled until protocol-level proof arrives: heartbeat, then MISSION_ACK.
Left open
MAVLink ships unencrypted; link ciphers secure one drone to one station.
→
We propose
Token-paired gateways behind TLS, with keys scoped per account across every bound aircraft.
05 / 16

Use case 1 of 3 · asset inspection

Utilities and infrastructure owners

96.9%accuracy in automated line detection
3×faster coverage than manual walks
27target drones per gateway
  • Who is this for: Grid operators, bridge authorities, and contractors.
  • What they currently use: Disconnected planner apps and single-drone radios.
  • How it helps: Plan a flight path once, then fly it repeatedly with a mixed fleet.

Santos et al., Sensors 2024 and Lyu et al., Automation in Construction 2025 both solve UAV inspection perception; neither coordinates the fleet doing the flying.

Mission editor concept: takeoff, waypoint and land pins along a route
06 / 16

Use case 2 of 3 · emergency response

Disaster response and search teams

  • Who is this for: Disaster response and search & rescue teams.
  • What they currently use: Voice radios and scattered maps to coordinate teams.
  • How it helps: Connect any drone via Android to a shared, live cloud map instantly.
01Three crews arrive, three phonesEach phone connects one drone to the cloud.
02All bind to one incident accountA quick pairing code connects them all.
03One map, one shared pictureEvery crew and the commander see the full fleet.

Tan and Zhao, Complex & Intelligent Systems 2025 optimise task allocation across a UAV fleet once it's reachable from one place. Making that true in the field is what we propose.

Mission execution concept: drone mid mission with a route trail
07 / 16

Use case 3 of 3 · public health

City health departments and vector control

  • Who is this for: City health and vector control units.
  • What they currently use: Manual foot surveys block by block after storms.
  • How it helps: Automates fleet-scale drone surveys to quickly scan districts.
Survey swarm concept: several drones covering a district
  • Automated repeat surveysStanding water dries up within a week; one survey is never enough.
08 / 16

Who we design for

Four people, one system

Every design decision traces back to one of these four.

Field operator
On site, hands on
Connect an aircraft, confirm it's healthy, know instantly if the link drops.
Manual registration, five-phase pre-flight checklist
Mission planner
Desk, before the flight
Draw a route, set altitude per waypoint - never arm a live aircraft by accident.
Mission editor with no arming authority
Fleet administrator
Above the whole deployment
Visibility across every gateway, a defensible audit trail, one safety policy.
Admin console, centrally authored failsafe policy
Platform developer
Before anything flies
Exercise a full fleet on a laptop and trust the result predicts real hardware.
Simulation suite on the same code path

Authority is separated by role, not by trust. A planner cannot arm. Only a backend script can grant admin.

09 / 16

Proposed methodology

Three invariants, a five-step build

Rules no module may break, tested in this order.

I
One path for every vehicle
No branch may ask whether a drone is simulated. No drone_type check, no DRONE-SIM-* match.
II
Registration is explicit
No auto-attach, no scanning. A human types the drone ID and endpoint, always.
III
Gate on proof, not optimism
Upload needs live heartbeats. Start needs a MISSION_ACK. Nothing is assumed ready.

Build and validation sequence

10 / 16

Proposed system design

Four layers, one direction of travel

Telemetry flows left to right. Select a layer.

MAVLink /ws/ingest /ws/viewer commands: upload · ARM · AUTO · RTL
11 / 16

Proposed module A · edge gateway

The only thing that speaks MAVLink

One shared Python core, two shells. Select a radio group.

Target capacity, one gateway27 drones
T1 WiFirich, unthrottled
T1 WiFirich, unthrottled
T1 WiFirich, unthrottled
Video1080p payload
(4 groups × 6 Tier 2) + 3 Tier 1 + 1 video = 27 drones
Job 1
Translates Drone SignalsMAVLink frames re-packaged as WebSocket payloads.Links raw local telemetry straight to the cloud.
Job 2
Bandwidth BudgetingPromotes active aircraft, handles the rest safely.
Job 3
Command DeliveryExecutes waypoints securely and reliably.
Add Drone dialog concept: drone ID and MAVLink endpoint fields
12 / 16

Proposed module B · backend and telemetry

Ingest and viewing, two separate channels

A slow browser must never slow a drone. Switch paths.

Edge gateway desktop or android Cloud Database long-term storage Cloud Backend routing data Live Broker live telemetry topics Browser client 60 fps map render 20 Hz frames write publish fan out broadcast in memory bus
Critical feed - position, altitude, battery, armed state
1–5 Hz
Rich feed - attitude, velocity, vibration, sensor health
10–20 Hz

Latency budget, edge to pixel

edge
network
broker
render
0 mstarget: under 200 ms
13 / 16

System Architecture

High-Level Block Diagram

A four-part topology connecting fleets to operators.

Cloud GCS Architecture Diagram
14 / 16

Proposed module C · lifecycle and failsafe

Five stages, four locked doors

A state machine, not a checklist. Select a stage.

Failsafe timeline concept: trigger, recovery and stand-down entries
Link loss
No heartbeat for 3.0 s → local RTL, no cloud round trip.
Battery / GPS
Charge under threshold, or HDOP above 2.5 m.
Policy
Authored once, synced to every bound gateway.
15 / 16

Thank you.

Team members: Krish Chauhan (23BRS1187), Arhaan Penwala (23BRS1155), Ananya Shailesh (23BRS1200) Guide: Suganaya G
16 / 16