reylink

Drone swarm command and control · edge-native

One operator. A whole fleet. Every move checked.

reylink is a modular command-and-control system for drone fleets. Adapters connect any vehicle, a C++ core plans missions and checks every command, and the operator works in missions, not joysticks. It runs on your hardware, at the edge.

Fleet 40 Roster 40/40 Formation Grid Min sep — Floor 2.0 m Gate Active Illustration

Tested end to end with PX4 v1.17 · evidence for every figure

10/10armed drones stopped in flight by one fleet emergency stop, confirmed by PX4Jul 2026
50drones in one supervision load test, all tracked on about 62% of one CPU coreJul 2026
2.89 mclosest pair while 10 drones reshaped formation; the enforced floor is 2.0 mSep 2026
~20×less supervision CPU than the previous software stack at 10 drones16.6% vs 342% of one core

Every figure maps to a recorded evidence bundle from software-in-the-loop testing with PX4 v1.17 and Gazebo.

Recorded run · 2026-10-17

Not a render.
A recording.

An AI planner, Claude, sent reylink two plans for a ten-drone survey. The first was deliberately unsafe: two drones' paths crossed, and reylink refused it at preflight, before any motor ran. The second was proven and flown. In flight, the runtime guard still paused drones 29 times when it could not prove they would stay 2 m apart, and every pause cleared. Every position in the replay is from the Gazebo world-truth log, and the film under it is the same run.

claude-split-survey-n10-20261017T1355Z · gazebo world truth —
loading recording…
mission-film-20261017 · gazebo 3d + atlas 44 s · sped up 1–4× · no sound

Simulation, filmed live. The same run as the replay above, captured from Gazebo's 3D view (PX4 SITL) and from Atlas, reylink's operator UI. Playback speed and the mission clock are on screen.

What the film shows
  1. T+0 sTwo AI-written survey plans go to preflight. Plan 1 is refused at once: the paths of px4_4 and px4_6 conflict.
  2. T+3 sPlan 2 passes preflight with separation proven, and the launch starts.
  3. T+8 sTakeoff: all ten leave their pads and climb before any route starts.
  4. T+19 sRoutes start: each drone flies to its own survey column.
  5. T+21–45 sAtlas, connected as a read-only observer, tracks all ten live while the mission runs through the operator API.
  6. T+45–68 sSurvey lanes 12 to 20 m above takeoff. Routes complete one by one, 10 of 10 at T+68 s.
  7. T+72 sOperator LAND: each drone descends onto its own pad.
  8. T+97 sComplete: all ten back on their pads, disarmed, confirmed.

The gap

Drones are cheap. A fleet of dozens is affordable. Flying it still takes one pilot per aircraft.

AI can plan. No one lets a model that can't be verified command real aircraft on its own.

The layer in between is missing. Something has to decide what a fleet may do, prove it, and keep enforcing it when links, GPS or the AI fail.

That layer is reylink.

Three layers

Each layer changes without touching the others.

Add a vehicle by writing an adapter. Add a mission type as a module. Connect any console, partner C2 screen or AI assistant through the operator API. Missions flow down, telemetry and records flow up, and only the adapter layer knows what a specific vehicle is.

  • Operator layerMissions in; state, alerts and records out, through one versioned API. Desktop console, partner C2 or an AI assistant all connect the same way.
  • reylink core, C++Plan, prove, allocate, gate, execute, record. Deterministic and fail-closed, the same code on the ground and in the onboard agent.
  • Adapter layerOne adapter per vehicle type. PX4 qualified; ArduPilot and ground-robot adapters built; a template for closed SDKs.

How it works

A mission, start to finish.

From one start command to landing, with no pilot on any aircraft. Each step below is from a recorded test run, and each leaves a structured record: what was commanded, what was allowed or refused, and why.

  1. Bring-up

    One command starts the whole system: simulator or vehicles, supervision, operator API and ground-station link. The same command serves 10 drones or 50.

  2. Preflight

    reylink reads each drone's failsafe settings, identity and pre-arm state from the autopilot itself. A drone with a missing or wrong setting is refused, and the reason is named.

  3. Start

    The mission is authorized and each drone gets its own route. The fleet arms and takes off together.

  4. Formation

    The fleet reshapes in flight from a line to a triangle to a square at 3 m spacing. All 10 drones settled within 7.3 cm of their slots; the closest pair stayed 2.89 m apart.

  5. Hold and resume

    The operator pauses the fleet mid-route. Every drone holds; on resume, each autopilot switches back to its route within 12 ms of receiving the command.

  6. Emergency stop

    One command latches the fleet's emergency state and disarms all 10 airborne drones, confirmed by their autopilots. Nothing re-arms until an explicit recovery.

Modular by design

Vehicles and missions are plug-in modules.

The two things that change most in a fleet are the vehicles and the missions. Both are modules behind fixed interfaces, so a new vehicle or a new mission type inherits every safety check on day one.

Any vehicle: write an adapter

An adapter is one package behind one interface. The mission core, the safety gate, the operator API and the records stay untouched.

// the whole contract a vehicle adapter implements
class VehicleTransport {
  start() · stop()
  send_arm() · send_set_mode() · run_prearm_checks()
  send_position_setpoint() · send_velocity_setpoint()
  hold() · land() · return_to_launch() · emergency_stop()
  get_state() · get_health() · get_identity()
  subscribe_state() · subscribe_health() · subscribe_estimator()
  capabilities() · supports() · capability_profile()
}
  • Declare a profile: kinematic class and frame, safe actions backed by real behavior, the emergency action, telemetry confidence, known limits.
  • Register by name: the fleet configuration selects the adapter; an unknown name fails startup.
  • Pass the suite: ten fail-closed scenarios, including a seeded mismatch that must fail, fix the authority level from L0 to L5.

Authority levels: L0 observe only · L1 supervisory: arm, hold, return, land, emergency action · L2 route execution · L3 full authority, with enforced route leases · L4 onboard safety mirror · L5 signed, expiring leases in a partitioned mesh.

Proof: the ground-robot adapter maps four native ROS 2 topics onto this interface with no MAVLink, and it ran in the same mixed-fleet mission as the PX4 drones.

Any mission: add a module

A mission is one small document. Six objective families are built in, each a decomposer module that turns the objective into per-drone tasks with deterministic ids.

// mission-spec.v1 · a search mission
{
  "schema_version": "mission-spec.v1",
  "name": "ravine-search",
  "objective": {
    "objective_type": "search",
    "center": [420.0, -180.0],
    "altitude": 40.0, "max_radius": 300.0,
    "ring_spacing": 40.0, "ring_points": 12
  },
  "drones": ["px4_1", "px4_2", "px4_3", "px4_4"],
  "constraints": {
    "geofence": [[-100,-600],[900,-600],[900,300],[-100,300]],
    "no_fly_zones": [[[500,-50],[560,-50],[560,10],[500,10]]],
    "altitude_min": 15.0, "altitude_max": 60.0,
    "speed_limit": 8.0
  }
}
  • Families: waypoint route, area survey, coverage, recon, escort, search.
  • Generators: lawnmower, orbit and transit, plus a polygon partition for one balanced sub-area per drone.
  • Shared downstream: allocation, separation proof, the command gate, execution and records.

The same document always yields the same tasks. An objective the core does not know is refused, never guessed at.

What it does

Built, tested, recorded.

Each capability below is built into the core. The small line under each names its proof.

Missions, not joysticks

Six mission types become allocated per-drone routes, started with a plan hash and a separation proof.

flown: routes, formations, hold and resume, retask

Any vehicle, one fleet

Each adapter declares what its vehicle can safely do; a 10-scenario qualification suite fixes its authority level.

PX4 qualified at L3, full authority · ArduPilot and ground-robot adapters built

Every command checked

A four-step gate on every command (authorization, lifecycle, safety, movement), a 2 m separation floor on every setpoint with predictive refusal, and one fleet emergency stop with a sticky latch.

10/10 armed drones stopped in flight · refusal at 20.9 m

Works when the link doesn't

Vehicles move only while they hold a signed, expiring permission. Under jamming, GPS loss or a network split they hold, then land, and rejoin cleanly.

validated in network emulation

Fleets that recover

A failed or low vehicle hands its task to another; an unhealthy drone is quarantined while its formation continues. The operator is told, not asked.

retask flown with 5 drones · re-plan built, switched on per deployment

A record of every decision

Every command, decision and refusal is logged with its reason. Replay, audit and qualification evidence come with every run.

every flight above has a recorded evidence bundle

Roadmap

Where reylink is going.

The goal: one operator running a hundred vehicles, in the air and on the ground, with the safety core on board every one. The path there:

  1. Real aircraft

    First flights on real drones, one and then five. Mission console for operators.

  2. First customer pilot

    Sensor-driven missions and the AI mission assistant, in the field with a customer.

  3. Mixed, link-proof fleets

    Air and ground teams; the onboard safety core proven with the ground link cut.

  4. Fleet scale

    100+ vehicles per operator, a multi-vendor adapter program and qualification kits for customers.

Built for the edge

Your hardware. No cloud in the loop.

The whole stack runs on one machine, from vehicle adapters to operator API. It is small enough for a rugged laptop, portable across x86 and ARM, and the same core runs in the onboard agent.

1machine runs the whole stack, with no cloud service in the loop
62%of one CPU core in a 50-drone supervision load test, full roster tracked
2architectures, x86_64 and ARM64: the same Linux images run on a Windows desktop and an ARM64 server
1codebase on the ground and onboard, so authority can live on the vehicle

Security, built in. Signed, expiring authority; a deny-by-default graph policy; mutual-TLS operator access; a fail-closed ground-station gateway; a full audit trail. Built, and switched on per deployment.

AI, bounded. reylink ships no AI model of its own. It is the envelope any model runs inside: AI proposals enter through the operator layer and cross the same gate as every other command.

Who it's for

Defense & homeland security

Surveillance and reconnaissance, perimeter and border security, base protection

Public safety

Search and rescue, disaster response, firefighting support

Industry

Power line, pipeline and solar inspection; mining; agriculture

Drone makers & integrators

Embed reylink as the fleet layer of their own products

Questions

What teams ask first.

Short answers on vehicles, links, safety, AI and the roadmap. For anything else, ask us below.

What is reylink?

A command-and-control (C2) system for drone fleets and swarms. One operator gives the whole fleet a mission; reylink's C++ core plans it, gives each drone its own route and checks every command before it reaches a vehicle. It runs on your own hardware, at the edge.

Which drones and autopilots does it work with?

Any vehicle with an adapter. PX4 is qualified; ArduPilot and ground-robot adapters are built, and a template covers closed vendor SDKs. A new adapter implements one interface and passes a ten-scenario, fail-closed qualification suite that fixes its authority level.

Does it need an internet or cloud connection?

No. The whole stack, from vehicle adapters to operator API, runs on one machine, small enough for a rugged laptop, on x86 or ARM64. The same core runs in the onboard agent, so authority can live on the vehicle.

What happens when the radio link or GPS fails?

Vehicles move only while they hold a signed, expiring permission. Under jamming, GPS loss or a network split they hold, then land, and rejoin cleanly. This is validated in network emulation.

How does it keep drones from colliding?

Every setpoint is checked against a 2 m separation floor, and a command that would break it is refused before it is sent. In a recorded ten-drone formation change, the closest pair stayed 2.89 m apart.

Can an AI model command the fleet?

Only through the gate. reylink ships no AI model of its own; it is the envelope a model runs inside. AI proposals enter through the operator layer and cross the same command gate as every other command. In the recording above, Claude's deliberately unsafe plan was refused at preflight and its second plan flew.

What's next for reylink?

First flights on real drones come in 2026 Q4, one and then five; then a first customer pilot in the field in 2027, and fleets of 100+ vehicles per operator by 2028. Every result on this page is measured in software-in-the-loop testing with PX4 v1.17, and each has a recorded evidence bundle. Want your fleet in the first field pilots? Tell us below.

Contact

Tell us what you operate and what the mission demands.

We'll map your platforms, objectives and constraints; define the adapters, workflows and safeguards your environment needs; and show the coordination layer on a scenario that matters to you.

Prefer email? contact@reylink.io

White papers optional

We use your details only to reply to you.