FireClaw

A safety-aware embodied-agent framework for firefighting robots.

Comment

Inspiration

Firefighting robots operate under smoke, heat, degraded communication, and uncertain localization. A human operator should be able to say, "Go to the second floor and rescue people," but an embodied agent must do much more than generate text. It must select a capable robot, construct executable steps, verify current state, preserve hardware boundaries, and produce an auditable record.

Shared memory introduces another safety risk. An observation from another robot may be stale, spatially uncertain, or associated with the wrong victim. FireClaw is built around one principle: memory is evidence, not permission to act.

## What it does

FireClaw is a safety-aware embodied-agent framework for firefighting robots.

The runnable showcase performs a complete workflow:

  1. MissionAgent interprets an English rescue command and extracts the target floor.
  2. It rejects offline or incapable robots and selects an available rescue robot.
  3. It generates five typed skills: navigate, search, assess, report, and return.
  4. Mission Memory retrieves nearby victim evidence contributed by two robots.
  5. SafetyGate refuses memory-only dispatch and requests operator confirmation.
  6. After confirmation, the robot still revalidates the victim with live sensors.
  7. DryRunRobotAdapter executes the plan without making hardware calls.
  8. Every safety decision and skill transition is appended to an audit log.

The Build Week memory demo also shows two robots reporting nearby victims under different local tracker IDs. FireClaw creates an identity proposal but sets automatic_merge=false. An operator must confirm the match before both observations become one current entity, and both original evidence records remain available.

## How we built it

FireClaw separates planning, skills, safety, robot adapters, execution monitoring, and memory into explicit boundaries.

Skills declare required sensors, risk level, runtime policy, retry behavior, and real-robot permissions. The public showcase is dry-run only and reports real_robot_calls=0.

Mission memory uses append-only JSONL as its audit authority. A rebuildable SQLite projection provides spatial lookup through an R-Tree index. R-Tree only narrows possible candidates; exact uncertainty-aware distance determines the final result. Queries are isolated by mission, coordinate frame, and floor.

Every retrieved memory result includes evidence IDs, source robot IDs, and an explicit safety contract:

  • advisory_only=true
  • requires_revalidation=true
  • can_authorize_action=false

The project runs with the Python standard library and requires no API key, network connection, ROS installation, simulator, or robot hardware.

## Pre-existing project and Build Week extension

FireClaw existed before Build Week as a research framework with natural-language command parsing, mission planning, typed skills, robot adapters, SafetyGate, execution monitoring, and simulation- versus-real-hardware separation.

During Build Week, we meaningfully extended FireClaw with Codex and GPT-5.6 by adding:

  • structured Entity Memory for robot observations;
  • robot-namespaced tracker identities;
  • cross-robot victim identity proposals;
  • operator-confirmed append-only entity resolution;
  • evidence-preserving current entity projections;
  • uncertainty-aware nearest-memory retrieval;
  • SQLite Entity projections and R-Tree candidate acceleration;
  • explicit memory-to-action safety contracts;
  • integration between Mission Memory and SafetyGate;
  • a standalone judging package, demos, tests, and English documentation.

The repository includes a detailed capability-by-capability boundary in BUILD_WEEK.md.

## How we used Codex and GPT-5.6

Codex was the primary engineering collaborator for the Build Week extension. It helped inspect the existing architecture, trace Mission Memory and SafetyGate boundaries, implement and review Entity Memory and R-Tree retrieval, generate focused tests, diagnose spatial-query performance, connect memory to the complete agent workflow, and prepare the standalone submission.

The human developer made the consequential product, research, and safety decisions: memory cannot authorize physical action; victim and hazard identities cannot be merged from proximity alone; operator confirmation does not replace live sensor checks; missing spatial state must fail closed; and simulation must remain isolated from real hardware.

## Challenges

The hardest technical challenge was improving retrieval speed without weakening safety semantics. A spatial index can hide uncertainty or introduce false negatives. FireClaw expands candidate bounds by pose uncertainty, uses R-Tree only for candidate selection, and applies exact conservative distance afterward.

The hardest product challenge was deciding what remembered information is allowed to do. Two robots observing similar nearby victims is not enough for automatic identity resolution or robot dispatch. FireClaw preserves ambiguity, requires operator confirmation, and still requires current sensor revalidation.

## Accomplishments

  • A complete operator-to-robot workflow that runs with one command.
  • Capability-based robot selection and five typed rescue skills.
  • Safety checks for robot state, sensors, runtime mode, and memory authority.
  • Cross-robot victim memory with complete evidence lineage.
  • Conservative, floor-scoped SQLite R-Tree retrieval.
  • Append-only safety and execution auditing.
  • An explicit dry-run hardware boundary.
  • Eleven deterministic tests with no external runtime dependencies.

## What we learned

Embodied-agent memory is not only a retrieval problem. In a safety-critical system, evidence must be auditable, uncertainty must remain visible, identity mistakes must be reversible, and retrieved context must never silently become physical authority.

## What's next

Next steps include simulator evaluation under localization noise and communication dropout, calibrated identity proposals using perception confidence, ROS1 and ROS2 adapter integration, and comparisons against point-only or generic memory retrieval.

Future evaluation will measure task success, retrieval recall, unsafe-action or near-miss rate, operator load, and p50/p95/p99 latency.

Built With

Share this project:

Updates