I have spent much of my career working on drones, robotics, autonomy, and the companies trying to turn those technologies into businesses that actually work. One thing that experience teaches you fairly quickly is that the real world has very little respect for a technology demonstration. A robot can perform beautifully in a controlled environment, but the more important question is what happens when you take that same robot somewhere the conditions are far from perfect.
Put it underground, inside a concrete structure, or somewhere GPS does not work. Give it poor lighting, an incomplete map, and an unreliable communications connection. Suddenly, the problem looks very different. The robot still needs to understand where it is, recognize what is around it, determine where it can safely go, and respond when the environment changes.
That is why I believe the next generation of autonomous robots will increasingly need to make important decisions locally. Cloud computing will remain incredibly useful, but some environments don’t allow a robot to depend on a constant connection to do its job.
The Real World Is an Unreliable Place
After enough years around drones and autonomous systems, you become a little suspicious of perfect conditions. I am always interested in seeing what a system can do when everything works, but I am usually more interested in what happens when something stops working.
That distinction matters because many environments where autonomous robots could provide the greatest value are also among the least predictable. An underground mine is a good example. GPS may be unavailable, communications can be inconsistent, visibility can be poor, and the physical environment itself may be difficult or dangerous for a person to navigate.
The robot does not get to use those conditions as an excuse. It still needs to know where it is. It still needs to recognize obstacles and decide where it can safely move next.
I have seen this problem up close through years of working with autonomous systems designed for complex, dark, disconnected, and GPS-denied environments. Those conditions fundamentally change the conversation around autonomy because you cannot assume that a machine will always be able to send information somewhere else and wait for instructions. In many real-world environments, the robot needs enough onboard intelligence to understand its surroundings, make decisions, and respond to changing conditions on its own.
That is where edge autonomy becomes particularly important.
Local Decision-Making Changes the Equation
When I talk about a robot “thinking” locally, I am not suggesting that it thinks like a person. I mean putting enough computing capability onboard the machine so it can perceive its surroundings, understand its position, navigate, avoid obstacles, and make certain decisions without constantly depending on an outside connection.
This matters for several practical reasons. One is latency. A robot moving through a complicated environment may not have time to transmit information elsewhere, wait for processing, and then receive instructions on what to do next. Another issue is connectivity itself. Sometimes a reliable connection simply is not available.
The bigger issue, in my view, is resilience. What happens when communication disappears?
I think that question should come much earlier in the development process than it sometimes does. Instead of only asking how well a robot performs when everything is connected and functioning correctly, we should also ask what the machine can still accomplish when almost nothing is connected.
That second question tells you much more about whether you have built something capable of operating in the real world.
Defense Makes the Problem Even More Obvious
This challenge becomes even more important when you move into defense and national security.
I spent years working in national security before becoming a technology CEO, and those two parts of my career have increasingly overlapped. Defense environments do not give technology companies the luxury of assuming that communications, GPS, or other infrastructure will remain available. In some situations, those capabilities may be intentionally disrupted.
A robot being used for intelligence, surveillance, reconnaissance, mapping, or force protection has to remain useful under those conditions. If losing a communications link immediately makes the system ineffective, that is a serious limitation.
This is also where I sometimes think conversations about artificial intelligence get ahead of themselves. We understandably spend a lot of time discussing how intelligent these systems can become, but raw computing capability is only part of the problem. We also need to ask where that intelligence is located, how quickly the machine can use it, and what happens when the robot cannot communicate with the rest of the system.
Those questions may not generate the same excitement as a new AI model or an impressive demonstration, but they can determine whether a robot completes its mission.
There Is No Free Lunch in Robotics
I do not want to suggest that the answer is simply to put as much computing power as possible onto every robot. Robotics rarely gives you solutions without tradeoffs.
Onboard computing consumes power. More processing capability can add weight, heat, complexity, and cost. Weight is particularly important for aerial systems because every additional component affects what the aircraft can carry and how long it can remain in the air.
That creates some difficult engineering questions. How much computing does the robot actually need onboard? Which decisions have to happen immediately, and which can wait until connectivity returns? How much redundancy is worth the additional power consumption and weight? At what point does adding capability begin to hurt the overall mission?
There is rarely one clean answer.
I have also learned to be careful with ideas such as platform-agnostic autonomy. I strongly believe in the value of autonomy that can work across different machines, but flexibility does not eliminate engineering complexity. Different aerial and ground platforms have different sensors, payloads, power constraints, operating characteristics, and intended missions.
Making intelligence portable across those systems is difficult work. The goal is not to pretend those tradeoffs disappear. The goal is to decide which tradeoffs are worth making.
Autonomy Matters More When Conditions Get Worse
One observation has stayed with me throughout my time in drones and robotics. The value of autonomy tends to become clearer as the environment becomes less friendly to people.
A robot moving through a predictable warehouse can certainly be useful. A robot capable of navigating somewhere a person cannot safely or easily go can change the nature of the job entirely.
That environment might be an underground mine, damaged infrastructure, an industrial facility, or a defense setting where sending a person first would create unnecessary risk. In situations like these, autonomy is not simply about completing a task faster. It can reduce the need to expose people to dangerous conditions.
This is why I think we should judge the next generation of robotics less by how impressive machines look under ideal circumstances and more by what they can accomplish when those circumstances deteriorate.
Can the robot continue navigating when GPS disappears? Can it understand an environment it has never seen before? Can it respond when communications are interrupted? Can it recognize when continuing would be unsafe? If something goes wrong, can it find its way back?
These sound like straightforward questions until you try to build a machine capable of answering them.
The Cloud Is Not Going Away
None of this means that I believe the future belongs to completely isolated robots. The cloud will continue to be extremely useful for fleet management, larger-scale analysis, historical data, software updates, coordination, and many other functions.
I see the future more as a division of responsibility between the machine and the broader network around it. Some information can be sent elsewhere and processed later. Other decisions simply cannot wait.
Finding that boundary is one of the more interesting challenges in robotics today.
After years of building companies around drones and autonomous technology, I have become less interested in seeing robots perform perfectly when everything around them is working perfectly. I want to know what happens when something goes wrong.
The connection disappears. GPS is unavailable. The environment changes unexpectedly. The map is incomplete. The robot encounters something nobody planned for.
At that point, does the machine simply stop and wait for someone to tell it what to do, or does it have enough awareness, computing capability, and autonomy to make a good decision on its own?
For many of the environments where robotics could have the greatest impact, I believe the answer to that question will define the next generation of autonomous machines.