Why the Army's $6 Billion Robotic Combat Vehicle Program Can't Figure Out Whether to Drive or Fight

Somewhere in the Pentagon's wish list for future warfare sits a small, unmanned ground vehicle that can scout ahead of troops, absorb enemy fire that would otherwise kill soldiers, and eventually pull a trigger on command from a safe distance. The concept is genuinely compelling. The execution has been, to put it charitably, a work in progress.

Photo by Saifee Art on Pexels.

The Army's Robotic Combat Vehicle program (RCV) has been running in some form since 2018. The basic idea: field a family of unmanned ground vehicles across three weight classes (light, medium, and heavy) that can operate alongside manned formations without putting soldiers directly in harm's way. Total investment so far has climbed past $6 billion when you fold in related research, prototyping contracts, and the various renamed predecessor programs that fed into it.

Here's the problem. Building a robot that drives is hard. Building a robot that fights is harder. Building one that does both, reliably, in contested terrain, with communications that might be jammed, against an enemy actively trying to defeat it, has turned out to be genuinely difficult in ways that slide decks from 2018 did not fully anticipate.

The Army ran limited user tests with RCV prototypes at Fort Hood (now Fort Cavazos) in 2021 and 2022. The results were instructive in the worst way. Vehicles lost communications links. Operators struggled to maintain situational awareness from remote stations. The human-machine interface, the actual business of telling the robot what to do and understanding what it was seeing, was clunky enough that soldiers in the tests spent more time managing the vehicles than they did thinking tactically.

One finding that kept surfacing: the operator cognitive load was brutally high. Controlling an unmanned ground vehicle in a dynamic environment requires processing video feeds, managing waypoints, monitoring vehicle health, and making engagement decisions, all simultaneously, from a station that may itself be under fire. The Army had assumed software and interface design would mature faster than it did.

The program also ran into a structural tension that nobody fully resolved on paper before metal started getting cut. Should the RCV be primarily a reconnaissance asset, staying light and fast and sacrificing armor? Or should it be a direct-fire platform capable of engaging enemy vehicles? The two roles pull the design in opposite directions. A scout needs to be small, quiet, and hard to detect. A fighter needs armor, a capable weapon station, and enough computational power to support targeting. Trying to split the difference produces a vehicle that's mediocre at both.

By 2023, the Army had largely shelved the heavy variant and was concentrating resources on the medium class, which was rebadged and restructured under new contract vehicles. Textron, Oshkosh, and QinetiQ have all had skin in various parts of the game. The medium RCV is now oriented around a 10-to-12-ton class vehicle with a remote weapon station, designed to operate in teams with manned Armored Multi-Purpose Vehicles.

That teaming concept is worth taking seriously. The Army is not trying to replace human soldiers with robots outright; the vision is robots as force multipliers that absorb risk on the most dangerous tasks, like breaching a defensive position or probing a tree line where you suspect an anti-tank team is hiding. On paper, this is smart. In the field, it requires a level of manned-unmanned teaming software maturity that the Army still doesn't quite have.

For context, here's roughly how the capability layers are supposed to stack:

graph TD
    A[Manned Command Vehicle] --> B(RCV Medium)
    A --> C(RCV Light)
    B --> D{Engage or Withdraw?}
    C --> D
    D --> E[Fire Mission Authorized]
    D --> F[Retreat and Relay Intel]
    E --> G((Target Engagement))

The decision node in the middle is where things get philosophically and technically messy. Who authorizes the fire mission? A soldier in the loop, always, which adds latency? Or does the vehicle have some autonomous engagement authority under defined conditions? The Army's official position is human-on-the-loop for lethal decisions. The practical reality of communications-degraded environments makes that harder to guarantee.

Ukraine has been watching all of this with interest. Russian and Ukrainian forces have both been fielding improvised unmanned ground vehicles, mostly modified commercial platforms, with mixed results. The lessons from that conflict suggest that small, cheap, and expendable often outperforms large, expensive, and capable when it comes to unmanned ground platforms in active combat. That's not exactly a ringing endorsement for a $6 billion program built around sophisticated, heavily integrated systems.

None of this means the RCV program is hopeless. Unmanned ground vehicles will eventually be part of how armies fight, the physics and demographics both point that way. But the Army has a habit of writing requirements for the robot it wants to exist rather than the robot that current technology can actually build. Closing that gap is less a procurement problem than an engineering honesty problem. And those tend to be expensive to fix.