TL;DR. Most localization programs don’t slip because of a hard technical problem. They slip because of an early design decision that looked fine on a datasheet and fell apart in the field. These are the six mistakes we see most often: figuring out accuracy later, copy-pasting receiver specs, speccing the wrong class of hardware, underestimating the antenna, picking an IMU that can’t carry the gap, and assuming the network is always there, plus the parking-lot test that hides all of them.
In our last post we reviewed the V-model for localization system design in robotics. The left side of the V-model is where you define and design, the right side is where you validate and scale, and the cost of fixing a decision climbs roughly 10x at every stage you move right.
This post is about the decisions that go wrong on the left side. Most of what we’ve learned in field engineering is about the design and design-validation phases, because that’s where the expensive mistakes are made. They’re the ordinary, reasonable-looking choices that don’t survive contact with the real world.
Mistake 1: Figuring out accuracy later
Most teams will tell you they already know the accuracy they need. The problem is the requirement usually isn’t specific enough.
A system gets built to “about a meter”, but the application turns out to need much tighter bounds. Take drone mapping. Without RTK corrections, in real time or in post-processing, you’re carrying a meter of uncertainty. That sounds survivable if you picture a consistent meter of shift across the whole map. But that’s not how the error behaves. It isn’t a uniform offset you can subtract out; it varies across the map, and that’s exactly what breaks survey-grade work.
The deeper trap is “I don’t need that level of accuracy.” Sometimes that’s true. But the moment you need the system to work everywhere, the bar moves. Higher accuracy is what gives you the tighter bounds to build precise applications on, and to keep them precise as you scale into harder environments.
Pin the accuracy requirement to what the application has to do, in the conditions it has to do it, before anything else gets chosen.
Mistake 2: Copy-pasting receiver specs
This is a very common mistake, and it’s easy to see why. You buy a receiver that supports RTK, the datasheet says “1 cm + 1 ppm” (one centimeter plus one part per million times baseline distance), and you write that into your requirements.
That number is real, in a perfect world. One centimeter when you’re sitting right on top of your base station, in open sky, with nothing interfering. That’s not how most applications operate.
Real environments have obstructions, and it is literally impossible to design a system with zero interference to the GNSS signal, because the interference often comes from inside your own product. Another computer or subsystem sitting near the receiver can be enough to degrade it.
A datasheet number measured in ideal conditions is a ceiling, not a spec you’ll see in the field. Treat it as the best case you’ll ever get, and design for the conditions you’ll actually operate in.
Mistake 3: Spec’ing the wrong class of hardware
Not all GNSS receivers are built for the same job. There are different categories of receiver, and they deliver genuinely different performance depending on what they were designed for.
For example, survey equipment uses very high-end and expensive receivers and antennas specifically to guarantee accuracy and reliability. But a wearable uses something from a completely different category. Neither is wrong; they’re built for different requirements. The mistake is reaching for the wrong category for your application, and only finding out later that the precision isn’t there.
It goes beyond the bill of materials, too. Some receivers carry sophisticated positioning-engine software and deep IMU integration that handles difficult environments well; others don’t. A heavy multipath environment will separate them quickly, and “multipath” isn’t one thing: there are different types of multipath. Signals scattering under shrubbery is a completely different problem from signals bouncing off glass in downtown San Francisco.
Define the category you need early, based on the precision and reliability the application demands, not on what’s familiar or cheap to start with.
Mistake 4: Underestimating the antenna
You’d be surprised how often the antenna is the thing standing between a system and centimeter-level position.
We see this in live walkthroughs constantly. We’ll bring a simple test rig to a customer, a receiver and an antenna, and start showing centimeter-level position. Then we mount the antenna on the actual robot and the GPS signal disappears, because there’s too much RF interference inside the platform from Bluetooth, cellular, and everything else packed in there. Move the antenna away from the robot, and the centimeter-level fix comes right back.
The antenna decisions that matter: the type and size, the bands it supports (it has to cover all the bands your receiver uses), and where it physically sits relative to the rest of your electronics. The good news is you can test all of this before you ever lay out a PCB (printed circuit board).
Modular hardware on the bench will surface antenna and RF-interference problems cheaply and iteratively, which is exactly the kind of early, low-cost validation the design phases on the “left side” of the localization V-model are for.
Mistake 5: Picking an IMU that can’t carry the gap
The range of IMU (Inertial Measurement Unit) quality is enormous, from a few dollars to tens or hundreds of thousands or tens of thousands of dollars (or more!). The spec that usually matters isn’t the headline accuracy; it’s how long the IMU can carry you when GNSS drops out.
Lower-end IMUs in a coupled GNSS/IMU solution are often scoped for ten to thirty seconds of dead reckoning. That can be fine. But the longer a low-end IMU has to drift on its own, the worse your solution gets. If you need to dead-reckon under a parking garage for a long stretch, you need a higher-end IMU, or other sensors (wheel speeds, cameras) feeding the sensor fusion to compensate.
There’s also a packaging choice here. An integrated module with a built-in IMU is a what’s-in-the-box, generalized inertial solution. It works, and when you lose GPS it’s better than nothing. But a generalized solution isn’t tuned to your platform. For new or demanding platforms, a custom approach with the right IMU and a positioning engine that models your dynamics will outperform it.
Decide which you need from your worst-case outage, not from whatever was easiest to integrate.
Mistake 6: Assuming the network is always there
It’s easy to forget that the world isn’t your test environment. Here in the US there are still meaningful cellular dead zones; Europe is in better shape, but the gaps are real, and they rarely get designed for.
The math is unforgiving. If your requirement is one-centimeter accuracy 99.9% of the time, even a 0.1% cellular outage while driving around will fail it, instantly. The fix usually isn’t to eliminate every dead zone. It’s to understand the impact and program for it.
If you lose corrections for ten seconds, a well-understood RTK engine doesn’t drift off the map; it loses a little certainty and recovers. That graceful behavior is a design choice you make early, not a surprise you discover in production.
The parking-lot test
Open-sky testing is a fine place to start. It’s predictable, and it confirms the system fundamentally works. The trap is letting it become your validation baseline, because open sky is close to the best case your system will ever see. You’re barely leaning on the other sensors because GPS data is so plentiful, performance looks great, and it feels done.
Then the product ships into suburban streets, loading docks, tree lines, and urban canyons, and the numbers fall apart. The parking-lot numbers are not your design baseline.
What we push for early is a test plan that’s representative of what the system will actually do in the world, run in your hardest environments before DVT, not after. Validate where you need to succeed, not where you know you will.
The same pattern across all six top mistakes..
These aren’t discrete problems with discrete fixes. As we put it in our localization system design discussion above: a system with all the right components, configured wrong or tested in the wrong environment, still won’t work. It’s a system interaction. The receiver, antenna, IMU, corrections, and the environment all determine the result together.
That’s the whole case for developing the discipline of rapid prototyping and iteration on the ‘left side of the V-model. If you surface these interactions early, with representative hardware in representative conditions, the cost is a quick conversation. If they surface at DVT or in production, they cost a redesign.
In the next post, we’ll get into the discovery process we run with customers under Catalyst: how we go from a blank page to two or three reference architectures ready to validate in parallel, so these mistakes get caught before any hardware is committed.
If you’re early in a localization system design program and want a second set of eyes before you lock an architecture, that might be a very productive conversation for us to have.
Schedule a Discovery Workshop with a Point One engineer
FAQs
What are the most common GNSS localization design mistakes?
The six we see most: defining accuracy too loosely, copying receiver datasheet specs into requirements, choosing the wrong class of receiver for the application, underestimating the antenna and its RF environment, picking an IMU that can’t dead-reckon long enough during outages, and assuming cellular coverage is everywhere. Validating only in open sky hides all of them.
Why don’t datasheet RTK accuracy specs match real-world performance?
Datasheet figures like “1 cm + 1 ppm” are measured in ideal conditions: open sky, a short baseline to the base station, and no interference. Real platforms have obstructions and internal RF interference from their own electronics, so field performance is almost always worse than the datasheet ceiling.
How long can a GNSS/IMU system dead-reckon without signal?
It depends on the IMU. Lower-cost IMUs in a coupled solution are typically scoped for ten to thirty seconds of dead reckoning before drift degrades the solution. Applications that need to operate longer without GNSS (for example, under a parking structure) require a higher-grade IMU or additional sensors like wheel-speed or camera input.
Why does antenna placement affect GNSS accuracy so much?
The antenna is the entry point for the signal, and modern platforms generate significant RF interference internally from cellular, Bluetooth, and compute. An antenna placed inside that interference envelope can lose signal entirely, even when the receiver is capable of centimeter accuracy. Antenna band coverage also has to match the receiver’s bands. Both are testable with modular hardware before PCB layout.
What happens to RTK when the cellular connection drops?
A well-understood RTK engine doesn’t lose position immediately when corrections stop. For a short outage it loses a small amount of certainty and recovers when the connection returns. The key is designing for that behavior in advance, since strict availability requirements (such as one centimeter 99.9% of the time) can be failed by even brief outages.