The Drone-First-Responder Operations Checklist

Drone-first-responder programmes succeed or fail on preparation, not on aircraft. This is the checklist we walk through with teams standing up DFR operations: what has to exist before the first real call comes in, and what the software has to do for it to count.

Regulatory and organisational

• Operating authorisation for the response area, including the category and any BVLOS or beyond-the-fence permission the response profile needs. The authorisation defines where the dock may send an aircraft without a pilot at the site, and nothing else does.
• Insurance that covers the mission profile, not just the aircraft.
• Written SOPs for launch criteria, airspace checks and abort conditions. The launch decision is made in writing before the call, so nobody has to make it at 03:12.
• Training and currency per crew member, documented. A pilot who is not current on the aircraft type is a pilot the gate should refuse. In AutrikOS the personnel record holds licences and recency and the launch gate checks them before the aircraft arms.
• A pre-flight checklist that is signed, with attendees, for every launch path: take-off from the console, a scheduled mission, an alarm-triggered one.

The fly page zoomed out: six aircraft with their status over the city.

Hardware

• The aircraft, plus spares. A DFR programme with one airframe is a programme that is sometimes offline. Two aircraft on one dock, or two docks, change that.
• A dock or a rapid-launch setup at the response location. The dock is what makes “first on scene” true: it is already there.
• Redundant links. LTE from the dock, a second carrier or a wired uplink, and the aircraft’s own link to the dock. A programme that depends on one SIM card depends on that carrier’s maintenance window.
• Power and charging that survive a long incident. The second and third sortie of a fire are the ones that matter, and they need a charged pack waiting.
• The payload for the call: a thermal camera for search at night, a zoom for stand-off, a speaker and a spotlight where the aircraft has to address people.

Eight live feeds on one wall, each labelled with its camera.

Software

• Live video and telemetry shareable to command and field units in a browser, with nothing to install mid-incident. A share link with an expiry that a dispatcher sends to the incident commander’s phone, and the fire service’s own operations room sees the same picture.
• A common map. The aircraft, its camera footprint, the search area and what has been covered, points marked by air and ground, all on one map that everyone looks at.
• Recorded flight paths and video as evidence. Every flight leaves a log, every recording is downloadable, and the compliance record says who flew and why.
• Integration into the systems the control room already watches. The drone feed goes into the VMS by RTSP pull or RTMP push, and the dispatch system can trigger a flight through a webhook, with an operator’s approval in the loop where the SOP requires it.
• Simulation for training. A simulated dock and aircraft in the same console, so a new operator rehearses the call before the real one.

People and process

• Named roles: remote pilot in command, tactical officer, the person who decides launch. The console’s roles should match: who may fly, who may only watch.
• Notification and escalation levels agreed before the incident, not during. Which alert interrupts the operator, which one waits for the debrief.
• Shift handover that transfers aircraft state, not just keys: what is charged, what is open on the health list, what the last flight flagged.
• A debrief habit. Replay the flight, read the log, write down what the SOP did not cover. The next SOP revision comes from there.

The one-pager

Those four sections, as a single page to pin on the wall of the operations room: ask us for the current version. See how teams run this on AutrikOS on the public safety page, and what the docked-fleet setup looks like when the pilot is not at the site.