We took the UBR Stack out of the lab.

We went to the European Defense Tech Festival, on an airfield east of Berlin, to show what we had built. We came back with a better idea of what people need to see, what the system still cannot do, and which problem may be worth solving first.

A few days ago, we took the UBR Stack to the European Defense Tech Festival, east of Berlin. We brought one UGV, one UAV, onboard compute, sensors, batteries, cables and more, all the way from Lisbon. It was the first time we had carried the whole ‘physical stack’ this far outside the lab.

The plan was simple: put the system in front of people who build and operate machines in difficult conditions, then pay attention to what they ask, and the feedback they give.

The pitch met the hardware

We arrived talking about three layers: a brain, resilient communications, and a Ground Control System that can coordinate different machines. That architecture still holds. But the audience taught us something quickly. Most people did not begin with the architecture. They gravitated toward the robots.

The strongest reaction came from seeing intelligence run locally on a machine. A robot receiving a mission in natural language, deciding what to do, and acting without depending on a cloud connection created the moment people remembered. The more abstract version of the stack required explanation — the machine thinking in front of them did not.

That does not mean the hardware is the company. Our rover and drone remain development platforms for the UBR stack. It means the next demonstration needs to make the architecture visible through behaviour.

A field test, not a victory lap

This trip also made the gaps harder to ignore. Some sensors underperformed. The machines moved too slowly for a convincing public demonstration. Drone restrictions — weather, airspace — reduced what we could show. The prototype worked like a prototype: useful enough to teach us, not reliable or polished enough to sell itself.

The positive part is that the underlying choices looked familiar to people building serious systems. We saw comparable cameras, radars, onboard computers and communications equipment across the event. The question is no longer whether the ingredients exist. It is whether we can integrate them into a system that completes useful missions repeatedly.

We also came back with a higher standard for data. Proprietary field data is not valuable because it is proprietary. It is valuable only when it produces better model performance, safer decisions, or more completed missions. Every new dataset now needs to answer that test.

The operators are the bottleneck

The most useful customer hypothesis from Berlin was not about a specific robot. It was about the number of people required to operate them.

Emergency-response and defence organisations may be able to acquire more drones, ground vehicles and sensors than they can staff with qualified operators. If every machine needs one person watching one screen, adding machines eventually adds complexity instead of capacity.

The UBR Stack should change that ratio. One person gives a mission. The Ground Control System translates it into machine-level assignments. The operator reviews and approves the plan. Machines execute locally, report progress, and keep safe behaviour when communications degrade. The person remains accountable without having to manually drive every movement.

This is still a hypothesis. The next field tests need to prove whether operator scarcity is painful enough, and whether supervised autonomy creates measurable leverage.

← 1 / 5 →

What changes next

Berlin moved us from prototype mode toward performance mode. The next version cannot only be technically interesting. It needs to be faster, clearer and more reliable in front of someone meeting the UBR stack for the first time.

Build a repeatable mission where one operator supervises multiple machines and can see what happens when a link degrades.

Make the machine’s local decision visible. The audience should understand what it saw, what it decided, and why it moved.

Measure model latency, mission completion, operator workload and failure behaviour instead of relying on the quality of the demo story.

Built in West Portugal

We left Portugal with machines and an architecture. We returned with a clearer standard: if the system cannot make one operator more capable, keep working when the link drops, and show why it made a decision, it is not ready.

The next field test needs less explanation and stronger proof. Faster machines. Visible decisions. One operator, several systems. A mission that continues when the demo script and the network stop cooperating.

We did not go to Brandenburg to look like the future. We went to find out what it will take to make the future work.