Powerline & Infrastructure Inspection
Replace $1,500/hour helicopter inspection with multi-drone fleet operations. First targets: utilities like CMP and Versant covering hundreds of miles of rural Maine transmission line.
UNIVERSAL MULTI-DRONE CONTROL
Operator-first software plus a bolt-on sensor pod that retrofits onto any Pixhawk or PX4-compatible drone. Built in Maine for the operators who actually fly.
WHAT WE BUILD
Multi-drone operations today are stuck in single-pilot, single-vendor mode. Every manufacturer ships its own ground station, and they don't talk to each other. Operators end up running four drones with four pilots and four pieces of software — and the labor cost kills the ROI of multi-drone work.
Gragg Robotics changes that. Our software puts one operator in command of an entire fleet, regardless of who built the drones. Our hardware pod adds swarm capability to existing fleets without forcing a fleet replacement.
We work with any MAVLink-compatible flight controller — Pixhawk, PX4, ArduPilot. Your existing fleet stays in service.
One operator commands 4 to 12 drones simultaneously. About 10× labor leverage compared to single-pilot models.
Same UI, same hardware pod scales from civilian inspection and SAR to defense applications. AFWERX-aligned from day one.
THE STACK
A real-time strategy interface for fleet operations. Six command primitives cover roughly 90% of real ops.
Built on the open MAVLink standard. Runs on commodity hardware. Drop-in compatible with PX4 SITL simulation.
A bolt-on sensor and control pod that retrofits onto any compatible drone.
Raspberry Pi 5 companion compute · visible camera · long-range mesh radio (RFD900x)
Jetson Orin compute · visible + thermal imaging (FLIR Lepton 3.5) · LiDAR (Livox Mid-360) · long-range mesh radio
Standardized mount, field-serviceable, IP54 weatherproof. Same enclosure scales across drone classes.
SEE IT IN ACTION
Watch one operator command a 4-drone fleet through inspection, search & rescue, and security scenarios — in real-time, with the same six commands that cover roughly 90% of real ops.
Run the live demo on your own machine — no install, no internet, no Python.
One self-contained 18 MB Windows .exe that boots the full operator UI with a 4-drone simulation. Click the buttons, drive the swarm, run the pre-built TACTICAL / INSPECTION / SAR scenarios end-to-end. Same software that runs on real hardware.
↓ Download Live Demo (18 MB · Windows) Prefer a guided walkthrough? Request one01
SWEEP
Operator drops one search box. Four drones auto-distribute into a spiral pattern and begin coverage.
02
TARGET
A drone detects the missing hiker. Operator clicks once — that drone locks position and streams live video.
03
FOLLOW + GO HOME
Ground team moves in. One drone shadows them; the rest are sent back to base, fully autonomous.
USE CASES
Replace $1,500/hour helicopter inspection with multi-drone fleet operations. First targets: utilities like CMP and Versant covering hundreds of miles of rural Maine transmission line.
Rapid wide-area search with autonomous detection and ground-team handoff. Cuts hours off SAR timelines, especially in the first golden hour. Built with Maine Game Wardens, K9 SAR, and Civil Air Patrol use cases in mind.
Crop scanning, livestock counting, irrigation diagnostics. One operator covers thousands of acres in a morning.
Autonomous patrol with intruder detection, audio warnings, and live video to a security operator. For substations, water treatment, ports, and dams.
Thermal sweep, hot-spot mapping, ground-crew handoff. Multi-drone coverage faster than any single platform.
Photogrammetry and LiDAR over construction sites, forest plots, and coastlines. RTK-grade accuracy.
Defense applications via AFWERX SBIR are an active track. Same platform, same operator workflow.
?US — PUBLIC POLLING
?US is a polling app that fits inside a notification. A question goes out and every phone buzzes with it, along with a button for each answer. You tap one. The notification closes and you carry on with your day. Open the app later and the only thing inside it is the results.
One answer per person, per question. No account to make, no feed to scroll, no form to fill in, nothing to sit through first.
That design is the entire point. Traditional polling reaches whoever is willing to stop what they are doing and answer at length — which is a small and unrepresentative slice of anybody. Most people are not unwilling to be counted; they are unwilling to spend ten minutes being counted. Reduce the cost of answering to a single tap and you start hearing from people a survey never reaches.
The goal is to make public opinion loud enough to be heard by the people making decisions. Not a comment section, not engagement metrics, not a shouting match — a clean count of what a population actually thinks about a specific question, gathered fast enough to matter while the question is still live, and legible enough that a representative cannot wave it away. If constituents can answer in one second, there is no longer a good reason for anyone to guess what they want.
It runs on infrastructure anyone can stand up: a Kotlin app, a Python server holding the questions and the votes, and a single-box admin page. There is no account system by design — the server has one admin key, and whoever holds it is the one who can ask.
SIDE PROJECTS
Before the drones and before the polling app, the shop built a lot of other things — tools we needed, experiments we ran, and questions we wanted answered properly. Most are retired. They are listed here in full, working or not, because a project list that only shows the wins is not a project list.
Python · multi-venue execution
A family of automated trading systems built across very different venues: centralised exchange spot trading through a common API layer, perpetual futures on a decentralised exchange, prediction-market contracts, and a fast-moving token sniper. Each ran unattended with its own risk limits, alerting and web dashboard.
The reusable engineering is in the parts nobody advertises: one order abstraction over venues with incompatible conventions, position and exposure tracking that survives restarts, daily-loss and per-position circuit breakers, and an accounting layer strict enough to tell a real result from a flattering one. Getting the measurement right proved harder than getting the trading right.
Retired as an income effort, for the reason described under Market Research Systems: rigorous out-of-sample testing did not find a durable edge, and we would rather report that than pretend otherwise.
No longer maintained. Not a financial product, not investment advice, and nothing here is offered for download.
Python · quantitative research
An open investigation into a narrow question: can prices on public prediction markets be beaten systematically by a small operator? The interesting part was never the trading — it was building measurement honest enough to answer the question in either direction.
What got built: a backtesting corpus that replays thousands of real markets offline, a monitor comparing implied volatility against what the underlying subsequently did, a behavioural circuit breaker that halts the system on anomalous activity rather than waiting for a loss, and an attribution layer that separates automated decisions from human ones so results cannot flatter themselves.
The finding so far is a negative one, and we publish it as such: across 1,275 strategy configurations tested over 2,814 markets with an out-of-sample holdout, no entry rule showed an edge that survived. Most of the value has been in the methodology — measuring correctly is harder than trading, and far more reusable.
Internal research. Not a financial product, not an offer, and not investment advice. Nothing here is for sale or download.
Python · multi-process orchestration
A fleet of independent worker processes running monitoring, reporting and market tasks in parallel, reporting into one shared dashboard, with a supervisor that noticed when a worker died and brought it back.
The engineering problem was never any single worker — it was keeping a dozen long-running processes honest: liveness detection that survives restarts, state that persists across crashes, and a supervisor that can tell "idle" from "wedged". Those lessons carry directly into fleet software, where the same question is asked about aircraft instead of processes.
Retired deliberately. Running many things adequately turned out to be worth less than running one thing properly, and the coordination overhead cost more than the parallelism returned.
No longer maintained. Superseded by focused single-purpose systems.
Python · Solana + Jupiter
An automation that carried out routine on-chain interactions across a set of Solana protocols on a schedule, spread over multiple wallets, with a quote-only dry-run mode and per-wallet reporting.
The engineering worth keeping is the safety scaffolding rather than the strategy: every action could be simulated before it was signed, wallets were isolated so one failure could not cascade, and the system reported what it had actually done rather than what it intended to do. Those are the same properties any system that acts in the real world without supervision needs.
No longer maintained. Not financial advice and nothing here is offered for download.
Markdown · Claude Code routing policy
A drop-in routing policy for Claude Code that sends mechanical work to cheaper models and keeps your best model for the decisions that actually need it — without downgrading anything that matters.
Built from running a live trading bot, a startup’s federal-funding pipeline, and a robotics codebase side by side under one assistant, without any of them starving the others of budget or attention. The same triage-and-route discipline, packaged as copy-paste files with a guide for wiring it into your own setup.
Python · LLM code generation
An automated pipeline that invented, wrote and packaged software products end to end. It mined real freelance job postings for what people were actually asking to have built, identified gaps against the existing catalogue, specified a product to fill one, generated the working code, and produced the README, licence and configuration example around it.
The output was a finished, installable ZIP with no human step in the middle — which is also the honest limit of it. Generating software is easy now; the hard problems are demand, trust and support, and none of those are solved by writing more code faster.
The demand-mining half is the part that aged well: deriving what to build from evidence of what people are already paying for beats guessing, in any industry.
No longer maintained.
Python · LLM + publishing APIs
A distribution system for the products above. It generated a distinct, genuinely useful developer-facing article per product rather than reposting the same blurb, produced cover artwork to go with it, published to dev.to through their API, and queued the rest for one-tap manual posting where automated submission would have been unwelcome.
That last distinction was deliberate. Communities like Reddit and Hacker News are hostile to automated promotion for good reason, so the bot stopped at the queue and left a human to press send. Building the line between automation and spam into the design was the interesting part.
No longer maintained.
Python · multi-provider infrastructure
One module every other system called instead of talking to a language model directly. It routed each request to a preferred provider, fell through to alternates on failure, and handled rate limiting, retries and backoff so that callers never had to.
It exists because provider outages, regional blocks and rate limits are normal rather than exceptional, and a system with a dozen call sites should not learn that a dozen times. The same reasoning drives the vendor-agnostic layer in our drone software: depend on a capability, not on one supplier's availability.
Superseded. The pattern carried forward into the drone control stack.
Python · packaged tools
A library of small, self-contained automation tools built as standalone deliverables — price trackers, web scrapers, lead extractors, report and invoice generators, a stock screener, social schedulers and chat-platform bots. Each one solves a single problem end to end and runs on its own.
Built during a period of deliberately high output, to learn what packaging software as a product actually involves: dependency pinning, configuration a stranger can follow, and documentation good enough that nobody has to ask. That packaging discipline is why the swarm controller ships as one file that runs on a machine with nothing installed.
No longer maintained.
Python · Flask + scrapers
An automated pipeline that pulled freelance job postings from several boards, scored them for fit against a skills profile, and surfaced only the worthwhile ones on a local dashboard instead of leaving them to be read by hand.
It worked, and it was still retired — wound down on purpose when the shop committed to drone autonomy full time. Kept on the list because filtering a firehose down to the few items a human should actually look at is the same problem as filtering sensor feeds, and the approach transferred.
No longer maintained.
Python · Flask + Selenium
A local price-comparison tool that searched several retailers at once from a single box and kept a saved-items list, so a watched item could be re-checked later without repeating the search.
Retired, and worth being straight about why: it drove a real browser to read result pages, so every retailer layout change broke it. The maintenance cost outran what the tool was worth. Kept on the list because the approach is still a reasonable starting point for anyone building something similar.
No longer maintained.
Design · print-on-demand
A run at print-on-demand apparel: original graphics and a catalogue of shirt designs prepared for the usual fulfilment platforms, where the product is printed and shipped only after somebody orders it.
It never became a business. The design work was the easy half; the hard half was distribution, and on a marketplace where every seller has the same fulfilment and the same catalogue, there was no advantage to be had. Listed here because it happened and because the honest version of a project list includes the ones that did not work.
Not currently offered for sale.
Curious about any of these, or want a closer look at the engineering behind one? Ask us.
ABOUT
Gragg Robotics LLC is a Maine-based drone autonomy company founded by Lucas Gragg. Formed in Maine May 2026. We build the universal control layer that lets one operator command any fleet of compatible drones, plus the hardware pod that adds swarm capability to drones operators already own.
We're working with the Maine APEX Accelerator on federal procurement readiness, have applied to the Maine Technology Institute Business Innovation Funding program, and are preparing an AFWERX SBIR Phase I application for the next available window. SAM.gov entity registration is complete.
Headquartered in Waterville, Maine.
MISSION
Put one operator in command of any drone, anywhere, on any mission — and do it from Maine.
GET IN TOUCH
Whether you're a utility evaluating drone inspection, a SAR team exploring autonomous capability, an investor tracking Maine deep-tech, or a developer interested in the platform — we'd like to hear from you.