The platform

The navigation stack you were about to build

Localization, mapping, perception, planning and control — production-hardened, sensor-agnostic and portable across embodiments. Integrated into your robot in months, then improved for as long as it runs.

Navigation core

Five problems, solved once

Every mobile robot has to answer the same five questions. The core answers them as one system, so the modules share state instead of fighting each other at integration time.

Where am I?

Continuous pose estimation that holds up where satellite positioning does not: underground garages, warehouse interiors, store aisles, and the transitions between indoors and outdoors that break most systems.

  • Visual, LiDAR and fused localization against a prior map
  • Seamless indoor–outdoor handover without a GNSS dependency
  • Recovery from kidnapped-robot and cold-start conditions
  • Degrades predictably in low-texture, low-light and crowded scenes
  • Accuracy improves as fleet operating hours accumulate

What does the world look like?

Mapping built for places that change. Maps are created from your own robots' passes, kept current from routine operation, and shared across every unit in the fleet.

  • On-robot mapping — no external survey rig required
  • Multi-session merging and drift correction across passes
  • Change detection for moved shelving, vehicles and layouts
  • Semantic layers: drivable space, no-go zones, docking points
  • Map versioning and rollback per site

What is around me right now?

Detection and tracking tuned for the sensor set you shipped, not an idealised rig — including the small, low, reflective and fast-moving things that cause real incidents.

  • Obstacle detection and tracking across camera, LiDAR and ultrasonic
  • People, vehicles and cart traffic, with motion prediction
  • Free-space and surface estimation, including kerbs and ramps
  • Corner-case library drawn from live deployments
  • Graceful behaviour under sensor occlusion or dropout

How do I get there?

Route and motion planning that respects your robot's actual shape, kinematics and comfort envelope — and the social rules of the space it operates in.

  • Global routing plus local motion planning under kinematic constraints
  • Tight-space manoeuvring, multi-point turns and precision docking
  • Human-aware behaviour: yielding, spacing, predictable motion
  • Configurable safety margins and operating design domain limits
  • Deterministic fallback and safe-stop behaviour

How do I move?

Trajectory execution matched to your drivetrain, tuned per embodiment. The layer where a good plan becomes motion people are willing to stand next to.

  • Controllers for differential, Ackermann and omnidirectional bases
  • Per-embodiment tuning for smoothness, ride quality and stopping distance
  • Runs within production compute and latency budgets
  • Clean interface to your existing safety and e-stop chain
  • Telemetry on tracking error and intervention events

Learning network

The part that keeps getting better after you ship

In-house stacks are frozen at launch and improve only when someone is funded to improve them. A platform improves continuously, because it learns from every robot on it — under data terms you agree to before anything leaves your fleet.

Shared data

Operating experience

Interventions, near-misses and failures are captured with full context and turned into test cases the whole platform is measured against.

Shared maps

Living site knowledge

Sites stay current from normal operation. New units inherit an accurate map on day one instead of surveying from scratch.

Shared models

Portable capability

Capability proven on one embodiment or environment is packaged and made available to others, without exposing anyone's proprietary data.

Your data stays yours

Data rights, retention and permitted use are agreed per programme before deployment. You decide what is collected, what leaves the robot and what may be used to improve shared models. Nothing is assumed by default.

Measured, not asserted

Every programme runs against defined metrics — localization accuracy, intervention rate, corner-case coverage — reported over time so improvement is something you can verify rather than take on trust.

How it works

From first call to production

A typical programme runs three to six months from kick-off to production readiness. The variables are your sensor set, your compute budget and how unusual your environment is — not whether the stack exists.

Step 01

Scope

We review your robot, sensors, compute and operating design domain, and say plainly what the platform covers today and what it does not.

Step 02

Bring-up

The core is ported to your hardware and calibrated to your sensor geometry. You get a robot navigating in a real space, early.

Step 03

Field tuning

We run in your environment against agreed metrics, work through the corner cases it produces, and tune behaviour to your requirements.

Step 04

Production

Release-ready builds, validation evidence, deployment tooling and fleet telemetry — then continuous improvement over the product's life.

Bring us a hard environment

Crowded, changing, indoor-to-outdoor, poorly lit, GNSS-denied. Those are the ones that improve the platform fastest, and the ones we most want to hear about.

Scope a programme →

Questions

Common questions

Do we have to use your sensors or your compute?

No. The platform is designed around the hardware you have already selected. We will tell you during scoping if a particular sensor set or compute budget puts a capability out of reach, and what the trade-off looks like.

How is this different from an open-source navigation stack?

Open-source components are a reasonable starting point and a poor finishing point. The distance between a demo and a production release — validation, corner cases, per-embodiment tuning, field support over a multi-year product life — is where the years and the millions go. That distance is what we sell.

How does this relate to robot foundation models?

They address different layers. Foundation models are pushing general-purpose capability forward, largely around manipulation and task reasoning. We focus on spatial intelligence for production deployment: getting a specific robot through a specific environment reliably, on production hardware, at a cost that works. The two are complementary, and we expect most robots to use both.

Which embodiments are supported today?

Four-wheel platforms and cart-class robots are in production or in development now. Additional embodiments, including legged and humanoid platforms, are supported through the same core with per-embodiment tuning. Ask us about your specific case — we will give you a direct answer about what is proven versus what would be new work.

What happens to data collected by our robots?

Data rights are agreed per programme before deployment. You control what is collected, what leaves the robot and whether any of it may contribute to shared models. Programmes that keep all data private are supported.

Can we license only part of the stack?

Often, yes. Some customers take the full core, others integrate specific modules — localization and mapping being the most common — alongside their own planning and control. We will recommend the smallest integration that gets you to production.