Sentinel Edge

• 

  Deploy new edge sites with confidence — guided provisioning keeps connectivity, devices, policies, and readiness checks in one workflow.

• 

  Move from policy intent to enforceable controls — manage rules, exceptions, compliance impact, and rollout scope before publishing changes.

• 

  A single operational view for the entire edge environment — health, incidents, performance, alerts, and actionable insights at a glance.

• 

  AI-assisted investigation grounded in evidence — connect attack paths, suspicious entities, correlated alerts, and next steps.

• 

  From global visibility to site-level context — instantly see where connectivity, devices, or environmental conditions need attention.

• 

  Update fleets without flying blind — stage firmware rollouts, test pilot groups, track compliance, and keep rollback safeguards visible.

• 

  Turn detections into action — investigate incidents with timelines, evidence, affected assets, response playbooks, and remediation controls.

• 

  Turn operational data into decisions — explore trends, uptime, regional risk, recurring issues, KPIs, and scheduled reports.

• 

  Know the state of every edge device — health, firmware, resource usage, risk, and operational context in one place.

• 

  Automate response while keeping control — visually build, test, monitor, and verify remediation workflows from trigger to completion.

Inspiration

Most edge-AI demos focus on one model doing one job. I wanted to explore a harder question: what happens when several Physical AI workloads need the same small edge computer at the same time?

A wildfire camera may need heavier vision inference just as rainfall is increasing, a slope sensor is showing movement, and an IMU suddenly detects earthquake-like shaking. On constrained hardware, running everything continuously wastes resources, while normal OS scheduling has no idea which physical event matters most.

That became Sentinel Edge: an offline-first, multi-hazard Physical AI platform that intelligently shares limited Arm compute across wildfire, earthquake, flood, and landslide monitoring.

What it does

Sentinel Edge runs four hazard-monitoring paths on one shared platform:

• Wildfire: camera-based smoke observation with temporal persistence and adaptive heavy-inference wake/sleep behavior.
• Earthquake: fixed-rate three-axis IMU processing with a reserved high-priority path for earthquake-like shaking.
• Flood: rainfall, water-level, rate-of-rise, threshold, missing-data, and recovery logic.
• Landslide: rainfall, soil moisture, tilt, vibration, and movement-anomaly monitoring.

The main feature is the Arm AI workload orchestrator.

Instead of treating every workload equally, it considers criticality, deadlines, minimum cadence, queue pressure, sensor health, workload cost, and system conditions.

That lets Sentinel Edge reserve capacity for seismic work, wake heavier wildfire inference only when useful, adapt flood and landslide monitoring frequency, defer lower-priority work without starving it, and keep queues bounded under load.

The web interface makes those decisions visible alongside incidents, evidence, sensor health, monitoring coverage, and uncertainty.

How I built it

I organized Sentinel Edge into six components: acquisition, analysis, model/workload runtime, incident management, REST/integration APIs, and client applications.

One important design rule is that simulated inputs do not get shortcuts. Camera, IMU, rainfall, water-level, soil-moisture, tilt, and vibration fixtures enter through the same normal observation contracts intended for real adapters. Incidents are then created through the normal Incident & Event Engine.

For this hackathon candidate, I validate Arm execution in a reproducible AArch64 emulated environment. Physical sensors are represented by deterministic simulated streams, and I explicitly label that limitation instead of presenting emulated results as Raspberry Pi measurements.

Where applicable, the AI runtime uses Arm64 ONNX Runtime with the CPU Execution Provider.

I also structured the optimization work into three comparable configurations:

• B0: naive fixed-rate baseline
• B1: optimized model/runtime, still fixed-rate
• O1: B1 plus adaptive orchestration

This lets me separate model/runtime improvements from scheduling and adaptive-cadence improvements.

Challenges I ran into

The biggest challenge was scope. A four-hazard platform can easily become four unfinished projects, so I focused on making the shared runtime and orchestration story work end to end before adding optional features.

Simulation was another challenge. A button that directly creates a “critical incident” would make a nice demo but prove very little. Instead, I built deterministic scenarios with timestamps, missing data, stale observations, replay, failures, recovery, and evidence generation through the real processing path.

Scheduling was also more subtle than simply saying “high priority goes first.” Native inference cannot magically be preempted at arbitrary points, so Sentinel Edge focuses on admission control, bounded queues, reserved capacity, maximum deferral, and visible overload rather than pretending to provide hard real-time preemption.

Accomplishments I'm proud of

The part I'm most proud of is the simultaneous multi-hazard scenario.

While several workloads compete for resources, earthquake processing can receive reserved service, wildfire heavy inference can wake and sleep, environmental monitoring cadence can adapt, lower-priority work can be deferred, workers can fail and recover, and replayed data is prevented from masquerading as fresh evidence.

I'm also proud that the project is designed to be easy for judges to reproduce. Core operation requires no cloud account, API key, live external data source, Gmail account, second board, or physical sensor.

And instead of hiding limitations, I made Sentinel Edge clearly distinguish between simulated, replayed, measured, and target-only evidence.

What I learned

The biggest lesson was that edge AI optimization is not only about making an individual model faster.

When several workloads share one constrained machine, deciding when not to run something can be just as valuable as optimizing the model itself.

Inference latency and model size matter, but so do duty cycle, queue delay, deadlines, admission control, sensor freshness, and behavior under simultaneous load.

I also learned that reproducibility is part of the product. Deterministic fixtures, scenario manifests, model/configuration identities, and explicit evidence classification make a demo far more credible and much easier for someone else to inspect.

What's next for Sentinel Edge

The next step is running the same candidate on physical Arm hardware with real sensors. That would let me extend the current methodology with real device latency, thermal, power, and sustained-load measurements.

I also want to connect real camera and IMU adapters to the same observation contracts already exercised by the simulations.

Beyond a single node, the most interesting extension is Collaborative Detection: optional, privacy-preserving sharing of small derived hazard signals between independent Sentinel Edge nodes, without transmitting raw camera footage or raw sensor streams.

The long-term goal stays simple:

use limited edge compute where it matters most, stay useful when connectivity disappears, and make every important decision inspectable.

Built With

• aarch64
• arm64
• docker
• fastapi
• json-schema
• linux
• numpy
• onnx-runtime
• openapi
• physical-ai
• progressive
• pydantic
• python
• qemu
• rest-api
• server-sent-events
• sqlite
• typescript
• uvicorn
• websocket