TLDR: After discovery, you have two or three architectures that could plausibly meet your requirements. The goal of this phase is to collapse those options to one — with real-world data, on representative hardware, before any board goes out for fabrication. The central decision is where the positioning engine runs: on the module or on the host. Four data-flow questions narrow the rest. And the prototyping itself frequently surfaces requirements that weren’t in the original brief, which on the left side of the V-model is cheap to absorb.
This is the fourth post in a series on localization system design for autonomy and robotics. Earlier posts covered the V-model and the stages of a design program, the six mistakes that most often derail programs, and the three requirements that have to be settled before you evaluate hardware. Each one comes out of a live conversation between Tom Weeks and me. This post picks up where discovery ends.
Discovery gives you a set of requirements that belong to your product instead of a number that belongs to a datasheet. It also gives you two or three candidate architectures that could plausibly meet them.
This is where the left side of the V-model stops being theoretical. You have to pick one. And the way to pick one is not more analysis — it’s testing the candidates in the environment the product will actually operate in.
This is the part of the job I like most.
The central decision: where the positioning engine runs
Most RTK receivers on the market are modular. The positioning engine runs on the module’s own compute, which is limited. For a lot of applications that’s the right answer, and it’s worth saying that directly — we’re not pushing teams toward host-based architectures. The point is to confirm that the on-module solution actually works for what you’re building.
Where it stops working is when the application needs more than a standard RTK plus IMU solution. Non-standard platform dynamics. Degraded urban environments where multipath is constant. Fusion with cameras, lidar, or wheel odometry. In those cases the module’s compute ceiling becomes a hard wall, and the answer is a host-based architecture where the positioning engine runs on the platform’s main compute.
The shift we’re seeing is teams asking earlier whether they can leverage compute that’s already on the platform. A robot running a lidar stack already has significantly more compute than a GNSS module. Often the answer is yes.
A team that discovers this at design validation test (DVT) is facing a redesign. A team that discovers it at architecture selection is having a conversation.
Four questions that narrow the rest of the architecture
The positioning engine location is the big one, but four data-flow questions shape everything downstream of it. Each answer eliminates architectures.
GNSS-only or inertially fused? There are use cases where an RTK-only engine is the better choice — if you only want to rely on position when you have a carrier-phase fix and you’re handling continuity with other sensors in your own stack, that’s the clean answer. If the system needs to hold position through GNSS gaps, you need inertial fusion, and that changes the compute question above. It also raises the loose versus tight coupling decision.
What’s the correction source? Can the application tolerate slightly less accuracy in exchange for more consistent coverage? SSR and VRS solutions trade differently than single-baseline RTK, and the right answer depends on where the product operates and how far it is from the nearest reference station. Network density is the variable that determines how much of that tradeoff you actually have to make.
Position only, or full PVT with attitude? An underground utility scanner trying to get absolute location down needs position. That’s it. A vehicle that needs to know its yaw, pitch, and roll on the bank of a racetrack — or its heading as it comes to park so a downstream system knows which way it’s facing — is a completely different requirement and a different data stream on the back end. This is one that gets missed, because heading and attitude aren’t specced out on a GNSS datasheet.
Attitude also has to come from somewhere physical. Two antennas on a fixed baseline produce GNSS heading directly, which is why dual-antenna systems exist — Atlas Duo is ours. A single antenna fused with an IMU can also produce heading, but only once the platform is moving enough for heading to become observable, which is exactly the constraint that bites a vehicle that needs orientation at a standstill. Pitch and roll come from the inertial solution. This is worth settling early, because it’s an antenna count and a mounting decision, not a software setting you flip later.
What are the connectivity requirements? At the end of the day, corrections require connectivity. Understanding where the product operates and what network access looks like there is part of the architecture, not an implementation detail to solve later.
In practice there are four paths, and most systems end up with a primary and a fallback. Cellular is the default for ground platforms — corrections arrive over NTRIP, and the tradeoff is coverage gaps. Wi-Fi works when the platform operates inside a known footprint, like a warehouse or a fixed job site. A local radio link to a base station you own removes the network dependency entirely, which is why it persists in agriculture and survey — but it doesn’t scale past the geographies where you’ve installed base stations. L-Band satellite delivers corrections where there’s no terrestrial network at all, at lower accuracy than terrestrial RTK.
The fallback path determines what happens in the fraction of a percent that consumes your entire availability budget. That’s worth deciding on purpose.
Building a proof of concept: representative, not identical
Once we have two or three reference architectures, the job is to recreate them as closely as we can and get them into the field.
A concrete version of what that looks like: for a mid-size outdoor mobile robot, the three candidates might be (1) a module-based RTK plus IMU solution with corrections over cellular NTRIP, position out over serial — lowest cost, lowest compute; (2) the same receiver hardware with the positioning engine running on the robot’s host compute, adding wheel odometry into the fusion for GNSS-degraded stretches; and (3) an integrated hardware accelerator delivering full PVT with attitude over Ethernet, with the fewest integration unknowns and the highest per-unit cost. All three could meet the accuracy requirement on paper. They differ enormously in what happens under a tree line, and in what the bill of materials (BOM) looks like at 5,000 units.
The standard is representative hardware, not identical hardware. Ideally the proof of concept uses the same hardware the customer plans to ship, but that depends on their timeline and what’s available. When it can’t, the signal path architecture is what matters.
For example: a team has settled on a module that won’t have samples available for another three months. Rather than lose the quarter, we build with a receiver we have on hand, configured to emit the same message set over the same serial interface at the same rate their host will see in production. Their integration work is real work. The performance data is real data. The part number changes later.
If a customer has already committed to a module that outputs serially to their host — meaning the module computes position on-board and streams the solution to the main compute over a serial interface, rather than handing over raw observations for the host to process — I’ll build a rig that outputs serially to a host, even if the receiver underneath is different. If they’re using a high-end receiver, I can build something structurally similar with a different evaluation kit (EVK), the vendor-supplied dev board used to test a receiver before committing to a design. What we’re validating is the architecture, not the BOM.
That distinction is what makes fast prototyping possible. If you have to wait months for your first boards before you can test anything meaningfully, you’ve spent your schedule buffer before you’ve learned anything. And if the testing you do in that window is on one individual component rather than the system, that’s where things go wrong.
Case study: RTK on wearable glasses
Wearable glasses with cameras and inertial units are showing up everywhere now. A customer building a VIO system — visual-inertial odometry, which tracks position by fusing camera imagery with IMU data — approached us because they wanted to add GNSS.
They had already thrown GPS out. They’d tested it, it didn’t work, and they’d moved on.
When we got into what they’d actually tested, the problem was antenna placement. The signal quality you get from something worn on the chest, or mounted at the side of the head, isn’t going to work. Body blockage and orientation variability make it a fundamentally different signal environment than a roof-mounted antenna on a car. That wasn’t a GPS problem. It was a design problem that GPS was getting blamed for.
So we built something testable. They sent us an evaluation kit of their own compute platform — the same processor their product would ship with, on a dev board we could wire into. We hooked up the same receiver they were working with and built a small modular rig that could be worn by an actual human in actual environments. There are pictures of me wearing one: compute at the hip, antenna in position, and a head-worn antenna alongside it acting as the ground truth system.
That head-worn ground truth rig is deliberately low-tech and it has worked for a long time. It’s available if anyone needs one.
With that in place we could collect real data with them and answer real questions. How much does each environment degrade signal quality? What can the positioning engine do with degraded signal to still produce a usable solution? How well can the IMU carry position when GNSS drops out?
And it opened a path they hadn’t considered: they already had compute running a VIO system. The module’s generalized inertial solution isn’t tuned for human dynamics — but there’s no reason the GNSS fusion couldn’t run on the compute that’s already there.
The product went from “GPS doesn’t work for us” to a viable architecture. Not because of a better algorithm. Because we tested the right thing.
Prototyping is a requirements tool, not just a validation tool
The wearable case is the pattern, not the exception. Applications that are newer to precision location — first responder wearables, safety equipment, body-worn sensing — surface requirements during prototyping that weren’t in the original brief.
Sometimes that means looping back to discovery. On the left side of the V-model, that loop is cheap. You change a document and rebuild a rig. On the right side, the same loop is a redesign, a delay, and in the worst case a cancellation.
The iterative version of this phase sounds like: that hardware didn’t work, let’s spin up something with higher-end hardware and see if the numbers move. Or: let’s go back and re-examine what you’re actually trying to achieve. Both of those are inexpensive right now. Neither is inexpensive after you’ve built tens, hundreds, or thousands of boards and discovered a failure at that point.
Where hardware accelerators fit
There’s a middle path worth knowing about. Part of how we run this process is with production-quality hardware that bundles everything required — receiver, IMU, RTK engine, and sensor fusion — into a single unit. We call these hardware accelerators. Atlas INS and Atlas Duo are the current generation.
At 10 or 50 units, you may not need a module-based design at all. You can ship on a hardware accelerator that’s representative of the architecture you’re validating. At 1,000, a module-based design of your own makes sense. At 10,000 or 20,000, you’re looking at a chip-down design — placing the receiver chipset directly on your own PCB instead of buying a pre-packaged module. Chip-down costs engineering effort up front and pays back in BOM and board area at volume.
The proof-of-concept method still applies at each of those transitions. You don’t drop a new receiver into a shipping product and call it a day. Each generation goes through the same phases — which is also where the interesting cost-down work happens. Going chip-down on the next generation can get you more bands, more constellations, and a lower BOM, because you drop the parts of the module you weren’t using.
The real deliverable
The output of this phase is one architecture, chosen with data.
But the actual goal is narrower than that. By the time a design goes to fabrication, the chance of a catastrophic missed requirement — a breakdown in system design that forces a return to the left side of the V, or kills the program — should be as close to zero as the process can make it.
That’s what the testing buys. Not certainty, which nobody has. Confidence that the thing you’re committing to has already been proven in the conditions it will actually ship into.
The next post covers what happens when you cross into engineering validation test (EVT) — and what the right side of the V-model looks like when the left side was done well.
If you’re evaluating architecture options and want to pressure-test them against real-world data before committing, schedule a Discovery Workshop with a Point One engineer.
Watch the full conversation — Catalyst Episode 2
FAQs
What does the architecture and prototyping phase of localization system design involve?
It’s the step between requirements and hardware commitment. You start with two or three candidate architectures from discovery, build representative prototypes of each, test them in the actual operating environment, and use that data to select one. The goal is eliminating architectures with evidence rather than analysis.
Should the positioning engine run on the GNSS module or on the host?
It depends on compute requirements. Most modular RTK receivers run the positioning engine on the module, which is sufficient for applications with good open-sky availability and standard RTK plus IMU needs. Applications requiring complex sensor fusion — non-standard platform dynamics, degraded urban environments, or fusion with cameras, lidar, or odometry — often exceed the module’s compute ceiling and need a host-based architecture. Deciding this at requirements is cheap; discovering it at DVT means a redesign.
What does “representative hardware” mean in a GNSS proof of concept?
Hardware that reproduces the signal path and data flow of the intended design, even when the exact components differ. If the production design is a module outputting serially to a host, the prototype should be a module outputting serially to a host — the specific receiver can differ. What’s being validated is the architecture, not the bill of materials.
How do you get heading and attitude from a GNSS system?
Two ways. A dual-antenna configuration on a fixed baseline produces GNSS heading directly and works at a standstill. A single antenna fused with an IMU can also produce heading, but only once the platform is moving enough for heading to become observable. Pitch and roll come from the inertial solution. Because this determines antenna count and mounting, it has to be decided during architecture selection rather than treated as a software configuration.
What connectivity options are available for delivering RTK corrections?
Cellular over NTRIP is the default for most ground platforms, with coverage gaps as the tradeoff. Wi-Fi works for platforms confined to a known footprint. A local radio link to your own base station removes the network dependency but doesn’t scale beyond geographies where you’ve installed base stations. L-Band satellite delivers corrections where no terrestrial network exists, at lower accuracy than terrestrial RTK. Most production systems use a primary path plus a fallback, and the fallback determines behavior during the outage window that breaks a high-availability requirement.
Why does antenna placement matter so much on wearable devices?
A roof-mounted antenna on a vehicle has clear sky view and a ground plane working in its favor. A chest-worn or side-mounted antenna introduces body blockage and constant orientation change, producing a fundamentally different signal environment. Teams frequently conclude GNSS doesn’t work for their wearable when the actual constraint is placement. Testing with a representative rig separates the two.
How do you measure ground truth for a body-worn positioning system?
With a second, higher-quality reference system worn on the same platform. For wearables we use a head-worn antenna rig as ground truth — deliberately simple, and effective. Without a ground truth reference you can collect data but you can’t measure error, which makes the testing far less useful.
What is SSR and when should you use it instead of single-baseline RTK?
SSR (state space representation) corrections model error sources across a region rather than transmitting observations from a single reference station. SSR and VRS solutions generally offer more consistent coverage over larger areas in exchange for somewhat lower peak accuracy than a short-baseline single-station RTK solution. The right choice depends on where the product operates and reference station density. Network density determines how sharp that tradeoff is.
What is a hardware accelerator in localization system design?
A production-quality unit bundling receiver, IMU, RTK engine, and sensor fusion into a single integrated system. It lets a team ship at low volume without doing their own module-based design, and serves as representative hardware during architecture validation. Atlas INS and Atlas Duo are Point One’s hardware accelerators.
What is a chip-down design?
Placing a GNSS receiver chipset directly on your own PCB rather than using a pre-packaged module. It costs more engineering effort up front and requires RF design competence, and it pays back in bill-of-materials cost and board area at high volume. It can also add capability, since you’re no longer constrained to the band and constellation configuration the module vendor chose.
How does a localization architecture change as volume scales from 100 to 100,000 units?
The architecture that’s correct at 100 units is often not correct at 100,000. At low volume, an integrated hardware accelerator is usually the fastest path. As volume grows, a module-based design of your own becomes economical, and at high volume a chip-down design does. Each transition should go through the same proof-of-concept process — and each is an opportunity, since chip-down designs can add bands and constellations while reducing cost by dropping module components you weren’t using.
How can I learn more about the Catalyst process?
Catalyst is Point One’s methodology for localization system design. The V-model post covers the stages and why left-side decisions dominate right-side cost. The six common mistakes post covers the specific choices that most often cause redesigns. The discovery post covers the three requirement inputs that precede architecture selection. Upcoming posts go deeper into EVT, the right side of the V, and how positioning requirements evolve at scale. You can also explore the positioning engine directly, or schedule a conversation with a field engineer.