Small robots face a difficult tradeoff. As they become more autonomous, they need more processing power to understand their surroundings and make decisions. But adding computing hardware means adding power consumption, memory and, in some cases, more battery capacity. For a small drone or mobile robot, there is not much room for any of them.
Cloud computing has helped get around some of those limits by moving demanding workloads off the device. A robot can collect sensor data and send it elsewhere for processing rather than carrying all of the computing hardware itself. That approach works well for some tasks, but less so when the robot needs to respond immediately or has to operate where network coverage is unreliable.
Researchers are now looking more closely at how much useful intelligence can stay onboard, particularly when the available power is measured in milliwatts.
One recent example comes from MIT, where researchers developed a 2 mm × 2 mm system-on-chip called Gleanmer that builds 3D maps of its surroundings while consuming less than 6 mW. The chip contains 622 KB of SRAM and can generate maps at 88 to 331 frames per second, depending on the workload.
Those numbers are possible in part because the researchers changed how the robot represents its surroundings.
Rethinking the Map
A robot moving through an unfamiliar space needs to keep track of what is around it. Depth sensors and cameras collect the information, but those measurements have to be turned into a map the robot can use to navigate.
One way to do this is to divide three-dimensional space into small cubes, or voxels. A detailed environment can require millions of them, which creates a considerable memory and processing workload for a small machine.
The MIT researchers developed another approach. Their GMMap algorithm represents the environment using three-dimensional Gaussian shapes. Unlike a fixed cube, these shapes can stretch to match the geometry of the space being mapped. A single elongated Gaussian, for example, can represent an area that would otherwise require many individual voxels.
That reduces the amount of information the system needs to maintain.
The researchers then designed Gleanmer around the algorithm rather than trying to fit the algorithm onto an existing general-purpose processor. Incoming depth images are processed in a single pass, so the chip does not need to store the entire image before it begins working. Small on-chip memories also keep frequently used data close to the computational units.
The result is a mapping system designed around the limitations of the robot that will use it.
MIT reports that Gleanmer consumes less than 6 mW. Running the same mapping algorithm at near-real-time speeds on an Arm Cortex-A57 CPU requires more than 4 W. The researchers also compared Gleanmer with an earlier occupancy-mapping accelerator that consumed 251 mW.
For a robot operating from a small battery, that difference leaves considerably more power available for the motors, sensors and communications hardware that also have to run.
Computing Is Only Part of the Power Budget
Processing the data is not the only thing consuming energy. The data also has to move.
Sensor information may travel through memory several times as it is collected, processed and used by an application. Moving data between memory and a processor consumes energy, which becomes more noticeable as the power budget gets smaller.
This is one reason specialized processors have become increasingly useful for edge AI. Instead of designing hardware to handle almost any possible workload, engineers can optimize it for a narrower set of operations and keep more of the required data close to the processing hardware.
A small inspection robot, for example, does not necessarily need the kind of general-purpose AI capability available from a cloud service. It might need to determine whether the path ahead is clear, recognize a piece of equipment or identify something unusual in a camera image.
Limiting the job also changes the amount of computing needed to perform it.
There will still be workloads that are too large or too infrequent to justify running locally. That is where the relationship between the robot and the cloud becomes more useful than treating them as competing approaches.
Dividing the Work
Large AI models are much easier to run on cloud GPUs than on a processor attached to a small robot. Model training, analysis of accumulated operating data and fleet-level optimization also have little reason to consume limited onboard computing resources.
Navigation presents a different problem.
A robot approaching an obstacle needs to react to what its sensors are seeing now. Sending that information across a network introduces latency, and the amount of delay is not always predictable. A connection can also disappear altogether.
Recent robotics research is beginning to split these workloads more deliberately.
CloudEdgeVLA, introduced by researchers in August, uses a large vision-language-action model running on cloud GPUs for higher-level information while a lighter edge component works with current visual data to make corrections as the robot moves. Rather than sending the entire control loop to the cloud, the system keeps the part most sensitive to changing conditions closer to the robot.
Another recent project, PhyAI, takes on the same issue from the software side. Its researchers developed an inference runtime that supports physical-AI models across onboard hardware, edge GPUs and cloud systems. A model does not have to be tied to one computing location.
Both approaches leave room for large remote models without making every robotic function dependent on them.
Mapping and obstacle avoidance are obvious candidates for local processing because delays directly affect how the robot moves. More computationally demanding analysis can happen elsewhere when an immediate answer is not required.
Bandwidth creates another reason to make that distinction. Cameras and other sensors generate a continuous stream of information. Processing some of it onboard means the robot can transmit the result instead of sending all of the raw sensor data over a network.
For a machine running from a small battery, reducing radio activity can be useful too.
How Much Intelligence Does the Robot Need?
The answer depends heavily on what the robot is supposed to do.
A warehouse robot operating on a controlled floor has different requirements from a drone navigating an unfamiliar building. An industrial sensor that needs to recognize an abnormal vibration pattern has a much narrower job than a humanoid robot expected to understand spoken instructions and interact with its surroundings.
That makes the edge-AI problem less about fitting the largest possible model onto the smallest possible processor and more about choosing what the device needs to handle on its own.
Gleanmer is one example of what this looks like at the hardware level. It was not designed as a general-purpose AI processor. Its architecture is built around one demanding but specific problem: creating a useful 3D representation of the environment with little power and memory.
Other edge devices are taking similar approaches to vision, audio and sensor processing. Dedicated accelerators can perform neural-network inference without keeping a larger processor active for every task. Some systems process sensor data before it reaches the main processor. Others wake more powerful hardware only when a local detector determines that something needs attention.
Each approach is trying to avoid spending energy on computing that the application does not need.
That becomes particularly important for drones and small mobile robots because the electronics draw from the same battery used for movement. More computing does not come for free. Neither does transmitting everything to another computer.
The cloud will continue to play a role as robots take on more complicated tasks, particularly as larger AI models become part of robotic systems. But small autonomous machines will still need enough processing of their own to keep moving when a network is slow, unavailable or simply unnecessary.
The challenge is no longer putting all of a robot’s intelligence in one place. It is deciding which parts need to travel with the robot.
