Forterra: What Operational Deployment Actually Demands from Autonomous Ground Vehicle Engineering

The Difference Between a Demo and a Deployment

Most autonomous vehicle companies are solving a solvable version of the problem. Their vehicles operate in geofenced areas, in favorable weather, on mapped roads, with engineers nearby and cellular connectivity overhead. The performance envelope is chosen to match what the technology can do today, then expanded incrementally as capability matures. This is rational engineering strategy — it produces fundable milestones and tractable failure modes.

Forterra operates under a different constraint set. Its RAAS (Robotic Autonomous Automation System) platform is deployed in active military logistics operations and industrial environments where the conditions are not chosen to match the technology. The technology has to match the conditions. That inversion — environment-first rather than capability-first — cascades through every engineering decision the company makes, from sensor selection through software architecture to how requirements get written and maintained.

That distinction is worth examining carefully, because it reveals what autonomous ground vehicle engineering actually looks like when the customer is the Department of Defense and the vehicles are moving real materiel in real operational contexts.

What Forterra Has Actually Built

RAAS is not a single vehicle. It is an autonomy architecture designed to retrofit onto existing military vehicle platforms — initially demonstrated on the Polaris MRZR and JLTV variants, and expanded to larger logistics vehicles used in base operations and convoy support. The core capability is leader-follower autonomy: a human-operated lead vehicle establishes a route, and a column of autonomous followers maintains position, spacing, and trajectory without GPS dependency as a primary navigation source.

The leader-follower architecture was not chosen arbitrarily. It reflects a deliberate alignment with DoD operational requirements. Military planners are not looking for fully unmanned convoys in contested environments today. They are looking for ways to reduce the number of personnel exposed to route threats while maintaining operational tempo. A human in the lead vehicle provides command intent and route authorization; the autonomous followers reduce the manpower exposure per vehicle in the column. This is a tactically credible capability that fits inside existing doctrine, which is why it has moved from demonstration to actual deployment.

Forterra also operates its technology in industrial port and depot environments — container yards, ammunition storage areas, and logistics hubs where the combination of GPS occlusion, vehicle congestion, and safety requirements maps well onto the same technical stack built for military use.

Environmental Qualification Is Not a Feature, It Is a Threshold

For commercial autonomous vehicles, environmental performance — rain, dust, temperature extremes — is documented in terms of tested operating ranges. For a platform intended to deploy with U.S. Army units or operate in forward logistics elements, those same parameters become qualification requirements with pass/fail criteria, and failure to meet them disqualifies the system regardless of how well it performs in nominal conditions.

MIL-STD-810 defines environmental test methods for defense materiel. For an autonomous ground vehicle, relevant test conditions include operating temperature ranges that span well below freezing to well above 40°C, humidity and salt fog exposure, blowing dust and sand, vibration profiles derived from actual road and off-road transport, and shock loading from vehicle mobility events. A sensor suite that performs adequately in a suburban California test environment may fail qualification testing before it ever sees an operational environment.

This has direct implications for sensor selection. Lidar systems optimized for cost and resolution at the expense of temperature range or ingress protection ratings are not candidates regardless of their nominal performance. Radar becomes structurally more important in a defense context not because it is a better sensor in benign conditions, but because it maintains acceptable performance across a wider environmental envelope. Camera systems require heating elements, moisture control, and ruggedized housings that add weight, cost, and failure modes.

None of this is surprising to defense systems engineers. What it means for an autonomous vehicle company is that the sensor stack that makes sense for the operational requirement is categorically different from the sensor stack that makes sense for a commercial robotaxi or warehouse AMR. Forterra’s engineering choices reflect this. The system is heavier, more expensive per unit, and more conservatively specified than a commercial-equivalent capability — because those are the correct engineering decisions given the actual requirements.

GPS-Denied Navigation: The Baseline, Not the Edge Case

In commercial autonomous vehicle development, GPS-denied operation is typically framed as a future capability or a niche use case. Underground parking, tunnels, urban canyons — these are handled with localization fallbacks of varying maturity. The primary assumption is that GNSS is available and reliable, with degraded-mode handling added around that assumption.

For defense autonomous ground vehicles, this is inverted. An adversary with jamming capability can be assumed. GPS should not be the load-bearing element of a navigation architecture intended for contested environments. This is not a theoretical concern — GPS jamming and spoofing have been documented in active operational theaters, and military planners designing capability requirements have to assume adversary employment of electronic warfare.

Forterra’s navigation architecture reflects this. The leader-follower approach reduces GPS dependency by design: the follower vehicles track the leader’s physical path rather than maintaining independent coordinate-based navigation. This means that GPS degradation or denial does not immediately break the operational concept — the followers can continue to operate as long as the leader-follower link is maintained. This is a meaningful architectural choice with real consequences for how GPS denial is handled at the system level.

Complementary to this, the system relies on inertial navigation, visual odometry, and terrain-relative localization to maintain position estimates when external reference signals are unavailable or unreliable. The accuracy requirements for military logistics convoy operations are different from those for urban robotaxi operations — the relevant performance metric is maintaining convoy integrity and avoiding contact with obstacles and route hazards, not lane-level positioning on a mapped road network. Requirements that are written against the actual operational need rather than imported from commercial contexts produce different and often more achievable technical specifications.

Retrofitting Autonomy onto Existing Platforms

One of the structural constraints Forterra operates under that clean-sheet autonomous vehicle designers do not face is platform integration. The JLTV, MRZR, and heavy logistics vehicles that form the backbone of military ground mobility were not designed with autonomy integration in mind. Their electrical architectures, drive-by-wire interfaces, and chassis structures reflect design decisions made for human-operated vehicles.

This matters because autonomy requires authority over throttle, braking, and steering — and gaining that authority on an existing platform means either working through whatever by-wire interface the platform provides, or adding actuation hardware that works around the original mechanical controls. Neither approach is clean. Working through existing interfaces means accepting latency, resolution, and bandwidth constraints that were never sized for autonomous control loops. Adding actuation hardware means adding weight, complexity, and failure modes, and it means the autonomous stack is controlling an abstraction layer over the actual vehicle rather than the vehicle directly.

Platform integration also means dealing with existing vehicle electronics, power systems, and communications architectures that were not designed to accommodate the power draw and data bandwidth of a sensor-compute-communications stack. A vehicle that was designed to support radio communications and basic vehicle monitoring now has to support lidar, radar, cameras, an onboard compute cluster, and a communications link to the lead vehicle and potentially to a ground control station. Power budgets, thermal management, and connector and cable routing all become integration problems.

The systems engineering discipline required to manage this — interface control documents, integration verification procedures, configuration management across a fleet of vehicles with varying baseline configurations — is closer to aerospace integration practice than to commercial automotive development. This is not a coincidence. The DoD acquisition system was built to manage exactly this kind of complex, multi-platform integration program, and companies that work within it adopt its practices out of necessity.

Requirements Refinement Through the DoD Feedback Loop

In commercial product development, requirements refinement is continuous and relatively informal. User feedback enters through support channels, usage telemetry, and product roadmap discussions. A change in requirements can move from identification to implementation in weeks.

The DoD feedback loop operates differently in almost every respect. The customer relationship is mediated by contracting officers, program managers, and technical representatives. Changes to operational requirements may require formal modification to the program of record or the system specification. Feedback from deployed systems reaches the engineering team through after-action reports, fielding assessments, and formal deficiency reports rather than through a support ticket or a Slack message.

This is not purely a liability. The formality of the DoD feedback loop means that requirements changes are documented, justified, and traceable. When an operational deployment surfaces a capability gap — a navigation failure mode under specific terrain conditions, a human-machine interface that increases operator cognitive load — the path from that observation to a requirements change is auditable. This is valuable in a domain where safety-critical systems are operating in environments where failures have serious consequences.

What it demands from the engineering team is discipline in requirements authoring and change management. Informal requirements that live in slide decks or engineers’ heads are not adequate when the customer is a government program office that needs to evaluate compliance against a specification. Every capability claim has to be backed by a test event that can be documented and reviewed. Every change to the system that affects a specified requirement has to go through a process that the customer can examine.

Forterra has been in this environment long enough to have developed the organizational discipline this demands. That is a competitive advantage against companies that are earlier in the commercialization process, but it is also simply the table stakes for operating in this market.

What Operational Experience Produces

Companies that have crossed from demonstration into sustained operational deployment tend to develop a specific kind of engineering judgment that is difficult to acquire any other way. They have seen what actually fails in the field versus what fails in test. They have seen the gap between what operators say they need and what they actually do with the system. They have accumulated failure data from environments that could not have been fully anticipated at design time.

This knowledge accumulates in requirements documents, test procedures, design decisions, and engineering culture. It produces conservative assumptions about what conditions the system will actually encounter, tighter tolerance for ambiguity in performance specifications, and a preference for robustness over nominal performance.

It also produces organizational credibility with the customer. A program office that is evaluating competing autonomous ground vehicle solutions can observe which companies have fielded systems and maintained them through operational use, and which are still projecting future capability from current demonstration results. That distinction matters in a procurement environment where past performance is a formal evaluation criterion.

Honest Assessment

Forterra is a small company operating in a domain where the incumbents are large defense primes with established relationships, large contract vehicles, and deep institutional knowledge of DoD acquisition. The RAAS technology is credible and operationally demonstrated, but scaling from current deployment levels to broader Army adoption requires navigating a procurement system that is not optimized for speed, and competing against integration into existing prime contractor program architectures.

The operational focus that produces engineering rigor also produces operational constraint. A system qualified to operate on specific vehicle platforms in specific operational configurations does not automatically transfer to a new platform or a new mission set. Each new integration is a real engineering and qualification effort. The same discipline that makes Forterra credible in existing deployments creates real work for every expansion of scope.

None of this diminishes what has been accomplished. Getting an autonomous ground vehicle system from concept through qualification and into actual operational use with U.S. military customers is a serious engineering and programmatic achievement that a small fraction of the autonomous vehicle companies that have attempted it have managed. The engineering decisions behind RAAS — the sensor conservatism, the GPS-denied architecture, the platform integration approach, the requirements discipline — are the right decisions for the problem as stated. That is what operational deployment actually demands.