Patrol: a 3D border patrol simulation
A fictional border, four multirotors, a fixed wing, three camera masts, three ground teams, ground sensors and three satellites. Sensors report contacts, the planner proposes who goes to assess them, and a person approves. Five scenarios, a replay of every run and a printable report. Your browser computes all of it.
- Type
- Our own project
- For
- Companies that plan patrols with drones and sensors and want to compare settings before they buy equipment
- Year
- 2026
- Similar project
- Studio pricing and contact
How many sensors and drones before you buy the equipment
We compare settings on the same seed: the fleet changes the line coverage and the response time, while time of day, fog, rain and wind change the chance of detection. Every number comes from a simulation run and names its seed, so you can reproduce it.
From a sensor reading to an assessment on the spot
Sensors
Every 0.25 s, camera masts, drones, the fixed wing, ground radar and fence sensors draw a detection with a chance set by the pixels on the object, weather, time of day and forest. A mast head sees only where it points.
Contacts
Readings join into a track with a class probability and a position uncertainty in metres. What is known about a contact grows as in the Johnson criteria: detection, orientation, class recognition. There is no identification of persons.
Proposals
Every 5 s the planner shares the free assets among the open contacts with the Hungarian method, at the lowest total cost. It writes the result as proposals: dispatch, retask, search or handover to the services.
Consent and assessment
A person approves or rejects. Then a ground team assesses the situation, gives first aid when someone needs it and hands the persons over to the services.
Five classes with data cards
The class names are fictional, and the parameters are assumptions within ranges from public literature: they show the differences between classes, not the behaviour of real equipment. The TL-Q4 multirotor weighs 4.2 kg and carries a 199 Wh pack; in the rotorcraft power model, on a full pack at 25 °C, it hovers for about 24 minutes. The TL-F12 fixed wing takes off vertically, orbits at 250 m at 400 m above the terrain and banks by 30° at most.
The TL-M20 mast with a PTZ camera sees only where it points and turns its head at up to 30° per second. Add seismic sensors, vibration sensors on the fence and a ground radar, and TL-V4 teams that drive along winding roads. Three fictional satellites deliver an image 30 to 90 minutes late, and clouds block it. That is shorter than the 4 to 12 hours after which images ordered from commercial operators arrive; in a run of 3 hours it lets the image arrive.
The fixed wing never slows below its stall, and the link ends behind a ridge
The core computes flight every 0.25 s. Acceleration has a class limit (a_max), speed has a class limit, and bank follows from acceleration. Apart from the vertical take-off and landing, the fixed wing never flies below its stall speed of 13 m/s. The radio link drops behind a ridge, so an asset behind the ridge loses contact with the operator.
The AI proposes, a person approves
The planner writes the result of its assignment as a proposal: dispatch, retask, search or handover to the services. Each proposal shows the numbers behind it: travel time, share of the battery and the risk weight. Without a person's consent nothing happens beyond the patrol.
Three exceptions protect assets and people: a return at the battery reserve, a return after the link is lost, and first aid by a team that is already on the spot. The decision mode can be switched to manual or automatic, for example for comparisons.
Map, 3D view and camera in one window
The 2D tactical map uses symbols in the general APP-6 logic: our own blue, unknown yellow, neutral green. Red marks only an armed contact and an unknown air object over our side. The local grid is labelled as a demo. The 3D view shows models built in code at true scale, and the camera image has a HUD overlay.
Cmd or Ctrl+K opens the command palette, the timeline has a filter, and the fleet editor computes the effect of a change in the number of assets. The narrator writes reports from the event log in Polish and in English; for the same seed and the same decisions they always read the same. An optional language model in the browser summarises the reports. It downloads only after a click (489 MB), and every sentence it writes carries the label “generated by a model, may be wrong”.
Five situations on the same terrain
An unknown air object over a mast, a group crossing the line in fog, a random scenario from the seed, an armed contact and sabotage. Armed contact in State B's buffer zone: a drone observes from our side at 400 m and reports to the services, and the teams stay away. Sabotage: a decoy alarm far from the scene, then a fence sensor goes silent and a group walks through the dead segment; a team repairs the fence and the sensor is tested.
The same run, other decisions
The “Compare on this seed” button computes your run twice more: with the nearest-free-asset rule and with the Hungarian algorithm. The contacts, the weather and the time stay the same; only the decisions change. The result is a table of seven measures and one sentence with the seed.
How many assets are enough on the same line
The fleet editor changes the number of multirotors (0 to 8), fixed wings (0 to 2), masts (0 to 4) and teams (0 to 4), then computes the effect on the same seed. We compared three fleets in the automatic mode, that is without time for a person's consent: the median of 50 runs (five scenarios, seeds 1 to 10), each for 3 hours of simulated time, with the Hungarian algorithm. Line coverage is the mean share of the border line that some sensor saw in the previous 5 minutes. Response time is the mean time from the first detection of a contact to an asset arriving on the spot.
The default fleet (4 multirotors, 1 fixed wing, 3 masts, 3 teams): coverage 0.952, response time 41 s. The lean fleet (2 + 0 + 1 + 1): 0.691 and 71 s. The full fleet (8 + 2 + 4 + 4): 0.986 and 42 s. The full fleet is 18 assets instead of 11 and adds only 0.034 of coverage, while its response time is 1 s longer. The lean fleet is 4 assets: it loses 0.261 of coverage and responds 30 s later.
Observation, assessment and help only
This is an educational simulation on synthetic data, not an operational system. It is not for making decisions about people. It does not identify anyone: the figures are anonymous and there is no biometrics.
The window is named ARES (fictional system). Several real companies use the name ARES, some of them in defence; our fictional ARES is not a product of any of them and does not copy any real system. The product is called Patrol.
Our drones and teams never cross the fictional line, and they watch an armed contact from 400 m or more. Property tests in Rust, which pass before every commit, check this. Among other things they check that acceleration and speed never exceed the class limit in any step, that assets never enter side B, and that in the proposal mode nothing is dispatched without a person's consent. There is no flight plan export and no link to real equipment. The full rules and the sources are on the demo's “What is it” page.
Smooth on an ordinary laptop
The 3D scene with shadows and the camera runs at 60 frames per second on an Apple computer with 8 GB of memory with the full fleet of 8 + 2 + 4 + 4: median frame interval 16.7 ms, with the scene taking 2.44 ms of processor time per frame. Method: scripts/perf.mjs, headless Chromium with hardware graphics, 1440 px, 8 seconds at ×30 speed, scenario “A group crosses in fog”, seed 42.
At scene start the browser downloads about 256 kB after brotli compression, of which the WebAssembly core is 50 kB and the scene is 146 kB. The 3D models weigh 0 B, because they are built in code. One simulation step of the full fleet takes 9.3 µs in WebAssembly (Node 26). Lighthouse 12.6.1 in mobile mode (phone emulation), on the live page: 100 in each of the four categories, LCP 1.4 s, CLS 0.
Before every commit the gate passes 43 tests in Rust (41 of them property tests) and 69 tests in Node. Before a release we also run 77 end-to-end checks in Chromium and WebKit; axe-core reports 0 accessibility errors in them, in both themes, at 1440 and 390 px.
For engineers: the technology stack
| Layer | Choice | What it does |
|---|---|---|
| Core | Rust, compiled to WebAssembly | The 0.25 s step, flight physics, the radio link and the sensors in one place. The same seed gives the same run in every browser; a test compares the state hash with the native build bit for bit. |
| Scene | three.js 0.186.1 on WebGL2 | Loads only when the scene starts. The 3D models are built in code, at true scale, so there are no files to download and no third-party licences. On a phone the 2D map is the main view, and the 3D view starts on request. |
| EO and IR camera | A shader on the graphics card and a HUD overlay | Palette, blur that depends on flight height, fog and sensor noise. Persons are anonymous figures. |
| Assignment | The Hungarian method in Rust | A pair costs its travel time plus battery use; a contact left without an asset costs by its risk. A test checks the result against a full search of every assignment. |
| Replay | Command log and seed | The run slider rebuilds the simulation up to the chosen moment. A test compares the state hash with the live run bit for bit. |
| Window | HTML, CSS and strict TypeScript | No framework. Light and dark theme, Polish and English, full keyboard control, a command palette, a printable report. |
| Narrator | Rules in TypeScript; optionally Transformers.js 4.3.1 and ONNX Runtime Web | The reports from the event log are deterministic. The language model downloads on a click and runs on the visitor's graphics card; an answer that names an object missing from the log is rejected. |