Partnership vision Robot integrations are proposed development work.

More autonomy in the air. More clarity on the ground.

When AI helps plan a flight, the operator should be able to understand the mission, approve its boundaries, and intervene. We want to build independent oversight for civilian drones with the teams that fly them.

For civilian drone makers, inspection teams, and fleet operators.

AI-generated concept of a civilian inspection drone at a coastal wind farm with a ground operator
AI-generated concept art made with fal.ai. Proposed use case, not a product demonstration.

Give each mission an accountable human owner.

Inspection, surveying, and infrastructure teams need to explain where a drone was allowed to go, what it was allowed to record, and how a human could intervene. Our vision is a shared evidence layer around the mission.

  1. Follow the mission

    Connect mission intent, operator approvals, changes to the plan, and flight-controller-reported outcomes in one understandable record.

  2. Set boundaries before takeoff

    Explore approved operating areas, mission duration, data collection permissions, and the people allowed to change a plan. Flight limits remain enforced by the aircraft’s own systems.

  3. Make intervention explicit

    Agree how a human requests hold, return, or landing through supported flight interfaces, and show whether the aircraft confirmed the requested state.

Human intervention, designed for the machine.

For a drone, “stop” needs a flight-safe meaning.

Cutting motor power in flight can create a new hazard. The operator and manufacturer must define the right response for the aircraft and conditions: hold, return, or controlled landing where appropriate. Onboard flight safety and lost-link behavior must continue if the observer or network is unavailable.

ClawMetry is not a safety-rated emergency-stop system. Robot support would need manufacturer integration and validation for the specific use case.

An open layer, built with robot makers.

Our proposal is a shared way to describe tasks, permissions, approvals, and outcomes across manufacturers. Operators could get an independent view while each robot keeps its own local control and safety systems.

Read the founding story and watch the vision video

Proposed responsibilities

People and operating rules

Intent, permissions, and approval

ClawMetry observation and governance

Activity evidence and authorized requests

Manufacturer’s robot controller

Motion, local safety, and confirmed state

Local emergency stops and safety systems stay independent of the observer and cloud.

Start in simulation. Validate on the machine.

A public SDK or simulator gives us a practical place to begin. We want to develop against the manufacturer’s supported interfaces, then validate the same integration with their team on a specific physical robot.

  1. Connect to the supported interface

    Agree which SDK, API, or robot events expose tasks, state, permissions, and operator actions. Begin with observation and record what the interface cannot tell us.

  2. Test a real simulator workflow

    Run normal work and interruptions. Compare recorded requests with simulator feedback, including disconnects and delayed acknowledgements. Keep simulated results clearly identified.

  3. Validate with the robot maker

    Test the selected model and software version under supervision. Check timing, sensors, physical loads, safety behavior, and recovery before describing hardware support as available.

Working in simulation does not establish physical-device compatibility or safety certification. Each manufacturer, model, and deployment needs validation.

Public development environments we are evaluating

Robotnik ROS 2 simulation Reachy 2 SDK and simulation

These are manufacturer resources, not announced ClawMetry integrations or partnerships.

Begin with one workflow.

Start with simulation, then a supervised civilian inspection scenario with the manufacturer and qualified operator. Observe one mission and its approvals before evaluating intervention requests and lost-link reporting.

Before we start

Does ClawMetry currently control drones or grant flight approval?

No. Drone integrations are proposed partnership work. Operators remain responsible for the permissions and operating requirements that apply to their flights. The pilot would use the manufacturer’s flight-control interfaces and local safety systems.

Why involve a third party?

Manufacturers know their machines best. Our thesis is that an open observation layer can help customers compare evidence, understand permissions, and keep a consistent operator experience across vendors. We want to test that value with partners, while keeping safety responsibilities explicit.

Let’s make safe AI together.

We would love to visit your test site and learn how your team plans, flies, and reviews missions. Together we can explore the evidence and controls that help customers adopt autonomous inspection.

A practical first conversation

  1. Show us one real workflow and the people responsible for it.
  2. Choose the evidence, boundaries, and intervention we should study.
  3. Agree a small supervised pilot and how we would judge the result.

An invitation to collaborate, with no claim of an existing robot partnership.