How We Taught a Robot to Navigate With One Cheap Camera

Figure 1. A drone finding its way through a cluttered room with nothing but a single ordinary camera — a famously hard problem. One camera can’t directly measure how far away anything is; the AI methods that guess depth from a single image are too noisy to trust in clutter; and the obstacle maps built from those shaky guesses tend to make a robot either crash or freeze. Here’s ours doing it anyway. (Left: an outside view of the flight. Right: the drone’s own read of the obstacles, in green, and the path it plans toward its goal.)

Every time you cross a dark room, you solve a problem that has quietly defeated robots for decades.

You can’t see well. The furniture is a smear of shadows. You have no idea exactly how far the coffee table is. And yet you don’t freeze in the doorway, and you usually don’t crack your shin. You slow down where you’re unsure, move briskly where you’re not, and somehow it works out. Without ever putting it into words, you are doing something we roboticists call planning under uncertainty: acting sensibly in the world despite not really knowing what’s around you.

This turns out to be one of the hardest things to give a machine. A robot, like you, in that dark room, almost never has a perfect picture of its surroundings. Its sensors are noisy. Its estimate of where it is drifts. The people and objects nearby move in ways it can’t predict. The deep challenge of robotics isn’t building a machine that works when everything is known — it’s building one that makes good decisions when things are not known. And a surprisingly large part of the answer comes down to a single idea: a robot needs to know what it doesn’t know.

In our recent work — a system we call MonoMPC — we set out to make that idea concrete, and to show what you gain when you get it right.

The trouble with one eye

Most confidently, navigating robots are expensive. They carry spinning laser scanners (LiDAR) or pairs of cameras that triangulate distance the way your two eyes do. These sensors are heavy, power-hungry, and pricey — fine for a self-driving car, a real problem for a palm-sized drone or a cheap warehouse robot where every gram and watt counts.

So the tantalizing question we kept coming back to was: could a robot get by with a single, ordinary camera? Just one cheap lens, like the one in your phone?

The catch is depth. A single photograph is flat. It tells you what things look like, not how far away they are. A coffee mug six inches from the lens and a building six miles away can occupy the same patch of the image. With one camera, a robot is, in effect, navigating with one eye permanently closed.

In the last few years, AI has offered a workaround. Models trained on millions of images can guess the depth of a single photo surprisingly well, looking at perspective, shading, and familiar shapes the way an artist would. For a moment, it looked like the problem was solved: let the AI estimate depth, build a map from that, and plan a path around the obstacles.

It doesn’t work. Not in a cluttered room, anyway (See Figure 2,3).

Figure 2. Two robots, same cluttered room, same single camera. The top robot (a conventional system based on a classical planner — ROSNAV(ROS Navigation Stack) trusts the camera’s noisy depth guesses and builds a map from them — but that map is wrong: the obstacles it imagines (green) don’t match where things really are (red), so it heads into empty space that isn’t empty and collides. The bottom robot is ours. It treats those same noisy guesses not as facts but as hints, weighs their uncertainty, and plans a route that keeps its collision risk low, reaching the goal without hitting anything.

When a good guess isn’t good enough

The depth guesses are noisy. And they’re noisiest exactly where it hurts most — up close, where a small error means the difference between a clean pass and a collision. When a robot treats these shaky guesses as if they were precise truth, two bad things happen. Sometimes it “sees” empty space where a box actually is, and drives straight into it (See Figure 2,3). Other times, the noise paints phantom obstacles everywhere, so the robot freezes or refuses to find a route.

Both failures share a root cause: the robot overestimated its own estimate. It mistook a guess for a fact.

Figure 3. We compare the performance of a classical planner, the ROS Navigation stack (ROSNAV), with our planner across 2 scenarios. In the robot ’s-eye view, the green points are what its camera thinks it sees, and the red points are where things actually are (Technically, we call them point clouds, so the green points are estimated point clouds and the red points are the true/ground-truth point clouds) — shown side by side only so you can judge the camera’s accuracy. The blue lines are the routes the robot is weighing up, and the cyan line is the one it chooses. Crucially, the robot never sees the red (true) points during planning; it works entirely from its noisy green estimate.

The fix: predict a range, not a number

We made a different bet. Instead of asking the AI for the distance to the nearest obstacle, we trained it to predict a range of plausible clearances, along with a sense of how confident it should be.

The difference sounds small, but it changes everything. Compare two ways a system might report the same situation:

• “The nearest obstacle is exactly 2.0 meters away.” (A confident number — and frequently wrong.)
• “The nearest obstacle is probably around 2 meters, but I’m genuinely unsure; it could be as little as 1.5.” (A range, honestly held.)

A planner who hears the second version can do something intelligent with it. It can keep a wider safety margin in the directions it’s unsure about, and move faster in the directions it trusts — exactly what you do in the dark room.

Get Basantsharma’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

It’s worth being precise about what this prediction is — and what it isn’t. The planner is the part that dreams up possible routes; the job of our learned model is simply to judge them. Hand it a proposed sequence of moves together with the current camera view, and it answers one narrow question: along that route, how tight will the tightest squeeze be? That single most-dangerous moment — the closest the robot would come to touching something — is what we call the worst-case clearance. And, as promised, the model reports it not as one number but as a spread of plausible values: wide when the camera’s view is murky, narrow when it’s clear (See Figure 4 below).

Figure 4. The blue line is a route the planner is considering, and the red mark is the tightest point along it — the worst-case clearance the model scores.

Under the hood, getting from a single photo to that spread takes a short chain of steps. The camera image is first turned into a rough depth estimate, then into a sparse three-dimensional sketch of the scene — a “point cloud” indicating roughly where surfaces appear to be. A neural network reads that sketch alongside the proposed moves and outputs two things: a best-guess clearance, and — just as importantly — how unsure it is about that guess. The trick is in the training: we reward the network not only for getting the clearance right, but for being honest about how confident it should have been. Its uncertainty has to be earned, not decorative (See Figure 5 below).

Figure 5

On top of this, MonoMPC runs a planner that is constantly re-deciding. Dozens of times a second, it imagines a fan of possible moves, estimates the probability that each ends in a collision, and picks the route that stays both safe and on its way to the goal. (We engineers call this style of always-replanning a Model Predictive Controller — the “MPC” in the name.) The tuning here is delicate. Lean too cautious and the robot dithers forever; lean too bold, and it crashes. The point is to thread that needle deliberately rather than by accident.

The real trick: being calibrated

Here’s the most interesting part, and the heart of why this works.

The enemy isn’t uncertainty. The enemy is miscalibrated uncertainty — being confident when you should be doubtful, or doubtful when you should be confident. An overconfident robot crashes. An underconfident one is paralyzed by imaginary dangers. What we actually want is a robot whose confidence matches reality.

The gold standard for this is, of all things, the weather forecast. A good forecaster is “calibrated”: on the days they say there’s a 30% chance of rain, it really does rain about 30% of the time. The number means something. A robot’s sense of danger should work the same way — when it says a move is risky, that move should genuinely be risky about that often.

We get there with a neat training idea. Rather than teaching the distance-estimator and the risk-judge separately, we train them together, so the system is rewarded not just for guessing clearances well, but for being honest about how sure it is. The model learns to calibrate its own doubt against what actually happens in the world.

Concretely, here’s the loop we add during training. The model makes its usual prediction—a clearance and a spread of uncertainty around it. But instead of stopping there, we use that spread to play out a quick what-if: given this much doubt, how likely is the route to end in a collision? That produces a risk verdict, which we then check against the truth — did the route actually turn out to be safe? When the verdict and reality disagree, the model gets corrected. Call a genuinely safe move dangerous, and its spread was too wide. Wave through a move that was actually too close, and its spread was too narrow. Squeezed from both sides like this, run after run, the model’s uncertainty is nudged toward exactly the right width.

Figure 6. The added training machinery is the dashed “risk estimation” box on the right — it takes the predicted spread, turns it into a risk verdict, and compares that verdict against the ground truth so the model’s uncertainty gets supervised, not left to chance.

That single design choice — letting the downstream risk be the thing that judges the uncertainty — is what separates a robot that knows what it doesn’t know from one that’s merely guessing with bravado.

The clearest way to see this pay off is to make the camera’s job harder. Turn the lights down, and the image gets noisier — precisely the kind of uncertainty the model is trained to respect rather than ignore. Watch what happens:

Figure 7. Watch how the lighting changes what the robot perceives — the dimmer the room, the messier and less trustworthy its sensed picture of the obstacles becomes. The worse the lighting, the noisier the robot’s view of the world.

Figure 8. Our collision model is trained to be honest about its own uncertainty — to predict not just how much clearance lies ahead, but how sure it is about that estimate. That’s exactly what lets it absorb the extra sensor noise that creeps in when the lights go down. Here, across two low-light runs, the robot navigates the cluttered room without a hitch: on the left, what the camera actually sees; on the right, its noisy read of the scene (the scattered points in green, called the estimated point cloud) and the safe path it threads through it (blue).

Does it work?

Yes — and not by a hair. In real experiments with wheeled robots and quadcopters threading through cluttered rooms, the honest-uncertainty approach reduced collisions by roughly 4 times compared to a version trained without it and up to 7 times compared to a conventional navigation system. We did this using nothing but a single cheap camera, in the kind of crowded indoor space that normally demands expensive laser scanners. And it ran in real time — fast enough on a modest laptop, and even on the small, low-power computers you can actually bolt onto a little drone.

In other words: cheaper hardware, fewer crashes. The win came not from a better sensor, but from a more honest relationship with a bad one.

The numbers above come from static obstacle courses. But the real world doesn’t hold still, so we pointed the robot at a harder test: rooms with people walking through them — sometimes cutting straight across its path, sometimes mixed in with the usual boxes. Strictly speaking, the system was never built to anticipate where a person will step next; it reasons about the scene exactly as it is right now. What saves it is speed. Because it replans dozens of times a second, each fresh glimpse of the room yields a fresh safe path — so a pedestrian stepping into its way simply becomes part of the next snapshot, and the robot flows around them. It reacts rather than predicts, and at this re-planning rate, reacting turns out to be enough.

Figure 9. A harder test — people walking through the robot’s path, in one run alongside static boxes. The robot was never trained to predict human motion, but because it replans many times a second, every new view of the scene produces a new safe route, and it simply flows around whoever steps in front of it. Left: the outside view. Right: the robot’s own read of its surroundings (the scattered points) and the path it picks (blue), with the arrow marking its goal.

The bigger idea

It’s tempting to file this under “clever robot trick,” but the principle reaches much further. Self-driving cars must guess where pedestrians will walk next. Delivery robots must act on a position estimate that’s always a little wrong. Any machine that operates in the messy real world is, at bottom, making decisions under uncertainty — and the ones that do it well are the ones that measure their own ignorance instead of papering over it.

That’s the quiet lesson hiding inside a robot navigating a room of cardboard boxes. The path to acting wisely in an uncertain world doesn’t run through pretending to be certain. It runs through doubt — held carefully, measured honestly, and planned around.

It’s the same thing you do every time you cross a dark room.

Project website: sites.google.com/view/monompc — videos, code, and more.

Full citation: B. Sharma, P. Jadhav, P. Paul, K. M. Krishna, and A. K. Singh, “MonoMPC: Monocular Vision Based Navigation With Learned Collision Model and Risk-Aware Model Predictive Control,” IEEE Robotics and Automation Letters, vol. 11, no. 2, pp. 1330–1337, Feb. 2026, doi: 10.1109/LRA.2025.3641112.