Skip to content

Instantly share code, notes, and snippets.

@Hulupeep
Created September 26, 2026 02:02
Show Gist options
  • Select an option

  • Save Hulupeep/9520e60991c981ffac3684db14ddd157 to your computer and use it in GitHub Desktop.

Select an option

Save Hulupeep/9520e60991c981ffac3684db14ddd157 to your computer and use it in GitHub Desktop.
CCF sensorless robot relocation detection: fleet fingerprint relocation alarm without GPS, AMR fleet monitoring false alarm rate, privacy-preserving robot fleet analytics, warehouse robot drift detection (Rust benchmark)

CCF 2026: sensorless robot relocation detection from a 73-byte daily fingerprint, measured on a simulated warehouse fleet

A robot moved to a different kind of zone was flagged within a day in 96 of 100 simulated moves. The alarm setting decides whether anyone is still listening.

Introduction

Sensorless robot relocation detection means noticing that a robot has been moved to a different place without GPS, beacons, or any location sensor at all. The robot sends a short daily summary of how familiar its surroundings feel. The server notices when that summary jumps.

CCF filed this as part of its fleet analytics provisional (US 64/039,623). The robot keeps a familiarity score for each kind of situation it meets. Once a day it condenses that state into fewer than 20 numbers and sends only those. No camera frames, no sensor readings, no names. The server keeps a smoothed baseline per robot and raises "possible relocation" when today's summary is further from the baseline than usual.

This gist builds that detector as filed and measures it on a simulated fleet of warehouse robots. It reports how fast it catches a move, how often it cries wolf, and what the filed alarm settings do to both.

What CCF does about it

The filed design has four parts that matter here.

  • A fixed-size fingerprint. The filed figure lists 17 numbers: how many situation types the robot has met, the share of situations in each of four phases (familiar or not, disturbed or not), how interconnected its situation map is, how many clusters it has, mean and spread of familiarity, time-of-day activity shares, and people-presence shares. An optional 18th number is the share of situation types seen for the first time today.
  • A drift distance: how far today's fingerprint is from a smoothed baseline (7-day moving average).
  • A threshold: the mean of recent drift values plus k standard deviations. The filed default is k = 3 over 30 days of the robot's own history. The filing also allows a threshold taken from a cohort of robots in the same kind of zone.
  • A quiet period after each alert while the robot settles in.

Nothing here computes a trust certificate. This is the fleet side of CCF, and it stands on its own.

Implementation

Crate: crates/research/sensorless-relocation-detection (Rust, no external crates). 13 tests, deterministic.

  • Situation types use the filed quantization: 3 brightness x 3 sound x 4 presence x 3 motion x 3 orientation x 4 times of day = 1,296 types.
  • Four zone types: ambient pick face, cold store, dispatch dock, overnight charging aisle. Each has its own busy hours, people pattern and congestion rate. Two zones of the same type share part of their situation types.
  • Familiarity uses filed constants only: the earned floor min(0.70, 0.005 n) and a gain fitted to a filed worked example.
  • The connectivity number runs 20 Sinkhorn iterations on the day's situation-to-situation transitions, as the filing's own simulation did.
  • 160 simulated robots per scenario, 240 days, move on day 120. Every alarm setting runs over the same simulated days.

What this means in plain English

A warehouse robot gets used to where it works. Once a day it sends head office eighteen numbers about how familiar things felt. If someone moves it to another depot, those numbers jump, and head office can see it without any tracking hardware.

The weak spot is the alarm setting. With the filed default, each simulated robot raised about six false alarms a year. After each alarm the system goes quiet for two weeks. So on about a quarter of days a robot could be moved and nobody would hear. Comparing each robot with its peers, which the filing also allows, cut false alarms to about one and a half a year.

In a real room

This example is invented. The numbers are from the simulation.

Niamh Cassidy runs the night desk at a chilled grocery depot outside Mullingar. The company has 36 floor robots split between Mullingar and a sister depot in Tullamore. On a Tuesday a Tullamore robot breaks down at the dispatch dock. A contractor takes a robot from the Mullingar cold store and runs it in Tullamore for the week. Nobody logs it.

With the filed default setting, the fleet raises about 216 relocation alarms a year, four a week. The desk clears them without reading. Tuesday's alarm goes the same way. If that robot had a false alarm the week before, it was still in its quiet period and said nothing.

With each robot compared against the other robots in the same kind of zone, the fleet raises about one false alarm a week in total. Tuesday's alarm stands out and Niamh rings Tullamore. In the simulation, a move to a different kind of zone was flagged the same night or the next in 96 of 100 cases.

A move from one cold store to another cold store is harder, because the two places look alike. The optional 18th number is what gives it away: 95 of 100 flagged with it, 73 of 100 without it.

Comparisons

Approach What it needs What it tells you
RTLS (Ubisense, Sewio) beacons or tags on site position
Robot fleet platforms (InOrbit, Formant) configured telemetry streams battery, faults, tasks; not "which site"
Kidnapped-robot detection (Thrun, Burgard, Fox 2005; arXiv:2607.17852) a map and the robot's own raw sensors pose loss, on the robot
CUSUM / EWMA change detection (Page 1954; Roberts 1959; Lucas & Saccucci 1990) a monitored statistic a change time, with known delay and false-alarm trade
CCF fleet fingerprint (US 64/039,623) 17 or 18 numbers per robot per day a change in where the robot is, plus zone type

The threshold rule is an estimated control limit, so the control-chart literature applies to it directly. Jensen, Jones-Farmer, Champ and Woodall (J. Quality Technology, 2006) review how limits estimated from small samples inflate and scatter false-alarm rates. A 30-day self history is that case, and the numbers below show it.

Benchmarks

Intel Core i5-10400T @ 2.00 GHz, rustc 1.98.1, release build. All numbers from RESULTS.txt and BENCH.txt in the crate.

False alarms, stable robots, 48 observations per day:

Setting False alarms per robot-year Share of days in a quiet period
own history, k = 3 (filed default) 6.006 0.2319
own history, k = 4 1.362 0.0538
cohort, k = 3 1.560 0.0629
cohort, k = 4 0.256 0.0105

At k = 3 the chance of a false alarm on a given day was 0.02142. A bell-curve reading of "3 sigma" would say 0.00135. With more observations per day it came down (3.317 per year at 192, 2.351 at 768) but stayed about five times the bell-curve figure.

Flagged on the move day or the next (k = 3):

Move Own history Cohort
to a different zone type 0.7937 0.9563
to the same zone type, 17 numbers 0.6875 0.7250
to the same zone type, 18 numbers 0.8000 0.9500
no move (placebo) 0.0187 0.0000

Missed moves under own history line up with robots that were in a quiet period on the move day (0.2437).

Two moves 7 days apart: both flagged 0.9313 with a 7-day quiet period, 0.2000 with 14, 0.0125 with 30. Classifying each day's fingerprint by zone type (time-of-day and presence numbers only) named the final zone correctly on 0.9791 of days, so it catches the lost second move when the zone type changes.

Size and cost: a 73-byte packet (18 numbers as f32 plus a schema byte) stands in for a state of 15,129 numbers (60,516 bytes) at the measured average of 122 situation types. Server check: 117 ns per robot per day. Robot side: 83 microseconds per simulated day, most of it the Sinkhorn step.

Failure modes

  • This is a simulation. Zone layouts, noise and congestion are chosen, not measured. False-alarm rates moved with observations per day.
  • The filed drift notification (drift above half the threshold for 7 days) fired on 63% of stable robots at 48 observations per day and 96% at 768. It did not separate a real staffing change from normal wobble.
  • Cohort thresholds treat gradual change at a site as a move: 45% of robots at a site with a changing shift pattern got a relocation alarm, against 18% of stable robots.
  • Moves between near-identical zones are close to invisible: with 90% of situation types shared, 3 to 6 in 100 were flagged under a cohort setting.
  • Classifying with every fingerprint number fails in the weeks after a move (0.2916 correct), because a newly moved robot looks young rather than looking like its new zone.
  • This run does not test what the fingerprint reveals about people. It makes no privacy claim.

Get started

License & contact

Code is BSL 1.1, converting to Apache 2.0 in 2032. CCF is covered by US provisional applications including 64/039,623. Licensing and contact via floutlabs.com.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment