We recently hosted a technical session with STMicroelectronics on precise positioning for last-mile delivery. The conversation focused on real deployments—where localization quietly breaks down, and what changes when location data becomes trustworthy.
Rather than recap the webinar, I want to share the patterns we keep seeing across customer conversations. Problems that look operational on the surface—driver complaints, geofence overrides, routes that never quite optimize—often trace back to something simpler: the system doesn’t know precisely enough where things are.
And it usually starts with what “good enough” accuracy actually costs at scale.
"Close enough" creates an operational tax
A one-to-ten-meter positioning error doesn’t sound overly dramatic. In isolation, it might not be. But last-mile use cases are fundamentally about the compounding impact of hundreds of stops per driver, thousands of drivers per fleet, day after day.
The same small error shows up at every stop. Vans park slightly too far from the optimal spot. Drivers walk extra distance. Delivery software refuses to complete a job because the reported position doesn’t line up with a geofence, so someone has to call for an override. If you stack these across a fleet doing hundreds of thousands of deliveries, this can become an operational drag or tax.
At first, most teams don’t frame this as a location problem. It takes a while to notice that the common thread is positioning accuracy.
It's actually three problems stacked together
One reason last-mile localization is tricky is that it’s not a single challenge. It’s a stack of related ones that reinforce each other.
Where the vehicle stops. Maps are often built from imprecise historical data, and real-time positioning doesn’t always align cleanly with them. Without repeatable, high-precision traces, it’s hard to know whether a van should stop ten meters earlier, or on the opposite side of the street, or in a completely different spot that nobody’s thought to try. Over time, drivers develop their own workarounds, but the system never learns.
Where the driver is. Many delivery workflows rely on handheld devices and geofencing to confirm a drop-off. When the handheld reports an inaccurate location, drivers can be physically standing at the door while the system insists they’re somewhere else. The result is a phone call, a manual override, and a few minutes lost—multiplied by however many times it happens per shift. This isn’t a geofence design problem, but a signal quality problem.
What patterns emerge over time. Route optimization depends on understanding traffic patterns at a granular level—which lane is faster at certain times, which turns consistently slow drivers down, which stops have predictable parking. Without consistent lane-level positioning history, optimization efforts plateau. The underlying data is too noisy to surface the insights.
If you’re seeing any of these symptoms, it’s worth asking whether you’re treating them as separate operational issues or as facets of the same underlying location problem.
Why standard GPS falls short
Last-mile delivery happens in some of the hardest GNSS environments: urban canyons, dense residential neighborhoods, university campuses, loading zones surrounded by reflective surfaces. Everyone expects degraded performance in downtown Manhattan. Fewer people expect it in a suburban cul-de-sac with a two-story house blocking half the sky.
What’s even less obvious—until you see it in production—is that the vehicle itself often contributes to the problem. Modern delivery platforms are packed with electronics: displays, cameras, compute modules, power systems. As Mike Slade from ST pointed out in the webinar, in many deployments, the strongest interference a GNSS receiver sees comes from inside the vehicle, not outside it.
This is why traditional GPS accuracy specs don’t translate cleanly to real-world performance. The question isn’t whether GNSS works in ideal conditions. It’s whether your system can maintain accuracy and trust when conditions are messy—in last-mile delivery, they usually are.
How to think about localization architecture
The shift that’s made the biggest difference in our deployments is architectural.
Instead of treating GNSS as a black box that hands you a position fix, modern systems treat it as a measurement engine. Raw GNSS observations, inertial data from an IMU, and signal-quality metrics all flow into a positioning engine that fuses them together and evaluates which inputs to trust at any given moment.
On the left, the ST Teseo 6 receiver and IMU act as a measurement engine—outputting raw GNSS observations and inertial data rather than a position. That data flows to the host running the Point One Positioning Engine, which fuses it with RTK corrections from our network. The output is precise position, velocity, and time with integrity metrics attached.
This separation matters. The receiver focuses on what it’s good at: acquiring signals across multiple constellations and frequency bands, tracking satellites, and reporting measurement quality. The positioning engine focuses on what it’s good at: fusing multiple data sources, rejecting bad measurements, and maintaining accuracy through tough conditions. Neither is a black box—both expose the information needed to make intelligent decisions downstream.
One thing worth noting: we’re always using both GNSS and IMU data, not switching between them. Even in open sky when GNSS is strong, the IMU provides a continuous sanity check. If the satellites say you moved ten meters but the accelerometers say you’ve been stationary, something’s wrong—and the system can flag or discard that measurement before it corrupts the solution.
The practical takeaway: if you’re evaluating GNSS solutions, don’t just look at position accuracy specs. Ask what raw measurements are exposed, what quality metrics come with them, and how the system behaves when inputs disagree. That’s where reliability comes from.
Measurement quality matters
Precise localization doesn’t start with corrections or filters. It starts with how clean the raw observations are.
Carrier-phase noise, signal stability, and the ability to acquire signals independently across bands can matter as much or more than multi-band or multi-constellation support. Historically, this level of measurement quality required expensive survey-grade hardware that didn’t make sense for fleet deployments.
What’s changed is the price-to-performance curve. For example, the ST Teseo 6 receiver delivers quad-band, multi-constellation measurements with detailed quality metrics exposed at the measurement level. It tracks GPS, Galileo, BeiDou, and GLONASS across L1, L2, L5, E6, and B3I bands—which means more signals to choose from when some are blocked or degraded. And because it can acquire L5 independently of L1, the system stays resilient even when the legacy band is compromised by interference.
That’s not marketing language—it means the positioning engine has the information it needs to reject multipath and interference before they affect the solution, rather than trying to recover after the fact.
If you’re speccing hardware for a last-mile application, push your vendor on measurement-level metrics, not just position-level accuracy claims.
The corrections layer
RTK corrections are the other half of this equation, and they’re worth understanding even if you’re not building the system yourself.
We’ve taken an OSR-first approach—meaning we’ve built and deployed close to 3,000 physical base stations on our own infrastructure rather than relying purely on modeled corrections. Each station is surveyed to a global reference frame, monitored for power and cellular connectivity, and maintained so we know when something’s wrong before customers notice.
The practical upside is consistent three-centimeter 2D accuracy at the furthest baselines we support, and predictable behavior as vehicles move between coverage areas. Because every base station is surveyed to the same reference frame, you get consistent positioning whether you’re operating in Texas or Toronto—no alignment jumps when you cross coverage boundaries.
For teams operating in regions we don’t yet cover densely, we offer deploy-on-demand: we’ll work with you to site and install base stations on private locations with good sky view.
For more detail on the Point One RTK network, dig in here.
Where to start
If you’re running a last-mile operation and some of this resonates, here’s what I’d suggest:
Quantify the problem. How often do drivers request geofence overrides? How much time per shift is lost to positioning-related friction? These numbers are often tracked but rarely aggregated in a way that reveals the pattern.
Evaluate your current positioning stack. What accuracy are you actually seeing in production—not in spec sheets, but in the environments where you operate? What happens when conditions degrade?
Think about the full workflow, not just the vehicle. If your driver’s handheld is on a different positioning system than the van, you’ve got two sources of error that may not align. Consider whether unifying them on the same reference frame would simplify your geofencing logic.
Ask vendors the right questions. Raw measurement access, integrity metrics, behavior under interference, correction network architecture. These matter more than headline accuracy numbers.
If you want to see this system running in real environments, the webinar recording shows live centimeter-level accuracy on the Las Vegas Strip—one of the toughest urban canyons around. And if you’re further along and want to talk specifics, please reach out!