Other Systems & Customization Suite
Autonomous Path Planning

A vehicle that can move is not the same as a vehicle that can move safely. Between the two sits path planning: turning what the machine perceives and how the site is laid out into a route that avoids what it should avoid, and that can still be followed when reality differs from the plan.
Autonomous Path Planning covers the ground vehicles that work indoors — AGVs and other mobile robots — as well as legged robots and drones outdoors. The principles are the same in each case: build a model of what is there, plan against it, hand the result to the machine, and replan when the model stops matching reality.
What makes a plan usable rather than merely clever is that it can be explained. When a machine stops, the useful question is not whether the algorithm was right in general, but which obstacle, which zone and which rule produced the stop. A plan that can be read is also a plan that can be challenged and improved.
A route nobody can explain is a route nobody can trust when it fails.
What it is
Planning from what is actually there. Zones, corridors, obstacles, traffic routes and restricted areas are held as configuration and updated as the site changes.
For ground and air. The same principles apply to an AGV on a floor, a legged robot on a site and a drone in the air; what differs is the environment model and the rules that apply to it.
Routes that avoid, not routes that stop. Where a path exists around an obstacle, the plan uses it; a stop is reserved for the cases where there genuinely is no safe route.
Traffic considered together. Several machines on one site are planned against each other, so a single vehicle's shortest path does not become everyone else's blockage.
Replanned, not patched. When the environment changes, the plan is recomputed from the current state rather than adjusted by hand.
Explainable routes. Which obstacle, zone or rule produced a given route or a given stop is retained, so behaviour can be reviewed rather than guessed at.
What gets in the way today
The route is fixed. It worked when it was drawn, and nothing since.
A fixed path is laid out and never reviewed. And the first time it is blocked, everything stops.
Detours are worked out by whoever is standing there. Which is fine occasionally and unsustainable as a routine.
Temporary obstacles — a pallet, a trolley, a parked truck — have no place in the plan. So they become a reason to call somebody.
Several machines behave like one machine. Each one is planned in isolation.
Every vehicle takes its own shortest path. Which is how two of them end up at the same junction at the same time.
Deadlocks are resolved by the driver getting out and pushing. Which is a real cost that never appears in a report.
Traffic rules exist in practice and on paper. And in practice they are whoever is closest to the junction.
The map and the site disagree. The plan is built on one, the machine drives through the other.
A layout change is made on the floor and never reaches the plan. So the plan is confidently wrong.
Stored obstacles and restricted areas are not updated. So a route goes where it should not.
The environment is only partly known. Which is treated as fully known, and discovered the hard way.
When it stops, nobody can say why. The most expensive failure mode is the unexplained one.
A fault code is raised without indicating what was seen. So the cause has to be guessed at on site.
The event is not retained. So the same stop happens again next week with the same unknown cause.
Changing the behaviour means changing code. So the fix waits for a release.
From what the machine can see to a route it can follow
The same four steps for every platform, whatever it drives or flies through.
What the machine perceives is fused with the configured site model to produce the plan, and what the plan used is retained alongside what it decided. Where a route cannot be found, the machine is given a defined hold rather than being sent somewhere that happens to be free, and the reason is recorded. Neither the environment model nor the perception quality is something the planner can improve on its own: where the site is not mapped or a sensor is blocked, that limitation shows up as a limitation rather than being papered over.
What you get
Where it is used
What changes between these settings is the environment, the speed at which it changes, and what happens when a machine has to stop.
Setting | What path planning usually focuses on |
Warehouses and factories | AGV routes between storage, production and despatch, with traffic and restricted zones |
Production lines | Machine tending and delivery between stations, where the layout changes with the line |
Large sites and yards | Legged robots and outdoor vehicles moving between buildings and plant |
Inspection and survey | Drone routes covering defined areas, with the plan retained for what was actually flown |
Multi-floor facilities | Vertical movement between levels, where lifts and doors become part of the plan |
Capabilities
Grouped by what they do.
Capability | What it means |
Site model | Zones, corridors, lanes, obstacles, restricted areas and speed limits held as configuration |
Map import and maintenance | Bring in an existing site model or layout and keep it current as the site changes |
Multi-platform planning | Ground vehicles, legged robots and drones planned against their own environment models |
Static and dynamic obstacles | Both planned around, with the dynamic set refreshed as the site reports movement |
Multi-vehicle coordination | Several machines planned together, with shared routes, priorities and conflict resolution |
Priority and traffic rules | Which machine yields, where, and under what rule — configuration rather than chance |
Route handover | A route issued to the vehicle and followed, with the vehicle reporting what it actually did |
Replanning | Plans recomputed when the environment changes, on a configurable trigger |
Hold and recovery | A defined hold when no safe route exists, and a defined behaviour when the route becomes clear |
Restricted zones | Areas a machine may not enter, checked before a route is issued |
Explainable decisions | Which obstacle, zone or rule produced a route or a stop, retained for review |
Time budgets | Planning and execution held to times the machine needs to keep moving |
Simulation and test | Try a layout or a rule change before it is applied on the floor |
Monitoring | Position, state and current assignment across the fleet, with history |
Integration | Connect to the fleet control layer, the site systems that report movement, and the systems that carry out the work |
Deployment choice | On the vehicle, at the edge, or centrally, decided by latency and by where site data may be processed |
Roles and retention | Role-based access, retention set by policy, with changes and overrides logged |
How it works
Model the site. Zones, corridors, obstacles and restricted areas are defined and kept current.
Bring in perception. What each machine sees is fused with the configured model to establish what is actually there.
Plan. A route is produced that avoids obstacles and other machines, within the time the vehicle needs.
Hand over and follow. The route is issued to the machine, which follows it and reports what it did.
Replan. When the environment changes or a machine is held, the plan is recomputed rather than adjusted by hand.
Review. Routes, holds and the reasons behind them are retained, so behaviour can be examined and rules improved.
Boundaries and what it depends on
What it depends on. The quality of the site model and of what the machine perceives. Where the site is not mapped, or a sensor is blocked or dirty, that limitation appears as a limitation rather than being hidden.
It plans; it does not locate. Positioning is produced elsewhere and taken as an input. A planner cannot compensate for a position it is not given.
It does not move machines by force. Where a vehicle has to be stopped, stopping it is a decision for the safety arrangements at the site, not something the planner overrides.
Air operations are governed by the local rules. Altitude, no-fly zones, permissions and any operation beyond visual line of sight are the operator's responsibility and are configured accordingly.
Where it runs. On the vehicle, at the edge or centrally, decided by latency and by where site data may be processed.

