I’ve been working on a global planning engine aimed at warehouse/fleet
deployments, and I just opened a free API tier. I’d love feedback from people
running real Nav2 fleets.
What it does
You upload an occupancy grid once. It solves a field for your goal (charging
station, pick station, dock), and from then on every path query — from any
start cell — returns a strictly optimal path in microseconds, without
re-searching the map.
The pitch for fleet operators: the cost of global planning stops scaling with
the number of robots.
Measured numbers (C++ core, single thread, low-end 2-core CPU)
1M-cell 3D warehouse map (100³, mezzanine floors + rack walls):
Metric
VectorField
A* (C++, typical)
One-time solve per goal
47 ms
—
Query, any start pose
7 µs
~5 ms, every query
Optimality
1.0000 (BFS-verified)
optimal
Peak memory
5 MB
—
10,000 simultaneous queries
70 ms total
~50 s
Dynamic sites: obstacle removal (cleared shelves, opened gates) is patched
exactly, 5.9× faster than a rebuild, zero error. Every solve is a fixed,
bounded number of identical array operations, so worst-case latency is known
in advance — relevant if you need timing guarantees for certification.
Where this fits in a ROS stack
Input: an occupancy grid (the same data you already publish on /map or
keep in a costmap_2d layer)
Output: an optimal cell path per query
Today: plain REST API, so anything that can HTTP can plan. A native Nav2
global-planner plugin (drop-in replacement for Navfn) is on the roadmap —
the field-reuse model maps nicely onto multi-goal / fleet planners, which is
exactly where Navfn recomputes the most.
Typical integration I’m picturing: your fleet manager uploads the map once per
shift (or per layout change), then every robot’s global plan request is a
~7 µs lookup instead of a Navfn re-search.
Honest limitations
Built for structured, mostly-static environments — warehouses, factories,
indoor drones. Not for highly dynamic unstructured spaces.
Obstacle insertion currently uses a repair fallback; exact fast insertion is
roadmap work.
It’s a hosted API (with an on-prem license option), not an open-source
package. Free tier is genuinely free: 100³ maps, 1,000 solves + 100K
queries/month.
For those running multi-robot fleets: how do you handle global replanning
cost today? Is 5 ms/query/robot actually hurting you, or is local planning
the real bottleneck?
What would a Nav2 plugin need to do for you to consider it (topic/action
interface, costmap update cadence, multi-goal support)?
Any interest in an on-prem / offline deployment for sites without
connectivity?
No, of course not. Global planning has never been the bottle-neck because it doesn’t run very often. Also, if that’s your value-prop then your approach is flawed: since it pre-computes a policy using Bellman backups (“flooding”) it only works if the global map doesn’t change (not true in practice, because obstacles). But if the map doesn’t change, then why replan? Sure, sometimes the local planner might take the robot astray and far enough away from the current global plan such that global replanning may be beneficial. But 5ms?
Any interest in an on-prem / offline deployment for sites without connectivity?
Yes, obviously. And that’s how current planners all work. Functional dependencies like path planning need to be able to work offline.
The pitch for fleet operators: the cost of global planning stops scaling with
the number of robots.
The pitch? Sounds like AI wrote this. I think that because it both sounds sensational and sensationally off-target! Since planning needs to happen on the robot and not in the cloud, there is absolutely no scaling issue like this “pitch” proclaims.
Optimality | 1.0000 (BFS-verified) | optimal
What does that mean? is 1.0 optimal? Is optimal 1.0? What’s the unit on the 1.0?
Which heuristic did you use to implement A*?
Looking forward to your answers, but please don’t use AI to respond to my questions.
hell, if your global map doesn’t ever change, then the path planning could take 30 seconds for all it matters.
yeah, anything that’s not running on-device is not a real solution.
like, the overhead from an http call alone will be on the order of 50ms. if you’re aiming to get sub-ms global path planning, well, lmfao.
yeah, I’ve been seeing this type of thing so much here. someone just slops something out that “solves” a “problem” which doesn’t actually exist.
I swear that people are just asking the chatbot to give them a million-dollar idea and then they just throw it together in like a day and ship it. I don’t understand it.
Thanks for the sharp questions — several fair points.
The two direct questions first:
Optimality 1.0000 is a unitless ratio: (returned path length) / (BFS
shortest-path length) on the same grid. 1.0000 = exactly shortest, verified
against BFS on 10/10 random instances.
The 3D benchmark A* uses Manhattan distance — admissible on the
6-connected grid. Same map, same start/goal pairs on both sides.
On “5 ms doesn’t hurt”: agreed — for one robot replanning occasionally it’s
noise, and if the global map never changes, 30 s would do. The case I’m
targeting is narrower: centralized fleet planning (Open-RMF-style), where
N robots request mission-level plans to shared goals (charger, pick
station) and one server answers all of them. There the cost really is
N × per-query, and bounded worst-case latency matters more than average.
On map changes: fair point. Obstacle removal (shelf cleared, gate opened)
is patched exactly — 5.9× faster than rebuild, zero error vs rebuild.
Insertion currently falls back to repair/rebuild (~47 ms at 1M cells — not
the fast path, but workable).
On cloud vs on-device: also fair — I wouldn’t put an HTTP call in a
reactive control loop either. Intended placements are (a) a fleet manager
on site WiFi tolerating tens of ms per mission-level plan, and (b) the
on-prem license where nothing leaves the building. If your setup is a
single robot on an unreliable link, this genuinely isn’t for you.
Intended placements are (a) a fleet manager on site WiFi tolerating tens of ms per mission-level plan.
Contradiction. You are “pitching” a 7 microsecond planner, to save us from 5 ms overhead, and now you are admitting that each request can have “tens of ms” overhead?
If your setup is a single robot on an unreliable link, this genuinely isn’t for you.
Who would say something like this? Certainly no roboticist. Please stop.