The app says the run finished. It did not finish. The robot is wedged under the sofa with one wheel spinning, or it has been parked against a phone charger cable for forty minutes with a plaintive chime nobody was home to hear, or it made it three quarters of the way around the living room and then died on the same rug fringe it died on last Tuesday. You bought the thing so you would stop thinking about the floor, and now you think about the floor more than you did before. As an Amazon Associate I earn from qualifying purchases.
We are the Smart Home Guide Editors, and this page is about that specific failure: a robot vacuum that works, navigates, maps, and cleans — and still gets stuck often enough that you have stopped trusting it to run when you are out. Not a robot that won’t turn on, not one that won’t connect to Wi-Fi, not one that has lost its map. One that is functionally healthy and still keeps ending its runs in a corner with a red light on. Over several months of reading our own reference robot’s error history rather than just clearing the alert and moving on, we found something we did not expect and that changed how we deal with the problem entirely: stuck events are not spread evenly around a home. They cluster, brutally, into a handful of square feet, and the same three or four hazards produce almost all of them. This page is what that log produced.
The Thing Nobody Tells You: Stuck Events Cluster
The mental model most people carry is that a robot vacuum gets stuck at random. It’s a dumb machine bumbling around a complicated house; sometimes it loses. Under that model the fix is a better robot — more sensors, better obstacle avoidance, a smarter chip — and so the natural response to a robot that keeps getting stuck is to start reading about next year’s model.
That model is wrong, and it’s wrong in a way that costs people money. When we started actually recording where our reference robot stopped instead of just walking over and freeing it, the distribution was not random at all. It was violently clustered. The overwhelming majority of stuck events happened in a small number of specific locations — under one particular piece of furniture, at one particular transition between floor types, and around one particular nest of cables behind a media unit. Enormous stretches of the home produced zero events for months at a time. The robot was not bad at the house. The robot was bad at about nine square feet of the house, over and over and over, and those nine square feet were generating nearly all the frustration.
This inverts the whole problem. If stuck events were random, you would need a fundamentally better machine. Because they cluster, you need to find the clusters and neutralize them — which is usually a matter of a cable clip, a strip of tape, or a decision about one piece of furniture, and which costs almost nothing. The robot you already own, with the hazards removed, will usually outperform a much more expensive robot in an unmodified room. That is the single highest-value thing we learned, and it is very hard to see if you free the robot and immediately forget where it was.
| Hazard class | What actually happens | Share of our logged stuck events |
|---|---|---|
| Cables and cords | Cord wraps the brush or wheel axle; robot halts to protect the motor | Largest single class |
| Height traps (climb-in, no climb-out) | Robot mounts a low obstacle, then can’t reverse off it | Second largest |
| Soft edges (rugs, fringe, curtains) | Fabric jams the side brush or lifts a drive wheel off the floor | Third; heavily rug-dependent |
| Wedge geometry (tapering gaps) | Robot enters where it fits and stops where it doesn’t | Moderate but very repeatable |
| Cliff / threshold confusion | Dark flooring or a step edge reads as a drop; robot refuses to move | Small but maddening |
| Genuine navigation loss | Robot cannot relocalize and gives up mid-room | Smallest class by a wide margin |
Read that table top-down as a priority list, because that is how we now read it. The last row — the robot being genuinely lost — is the one people blame first and the one that actually happens least. The first two rows are the ones that matter, and neither of them is a navigation problem at all. They are a physical-environment problem that happens to be discovered by a navigation device.
How We Logged It
Here is exactly what we did, because you should know how the numbers were made before you decide what to do with them.
We stopped clearing stuck alerts blind. Every time our reference robot halted with an error, before freeing it, we recorded three things: the room and approximate position, the error the app reported, and what the robot was physically touching. That last one turned out to be the important one, because the app’s error string and the actual cause frequently disagreed — a cord wrapped around a wheel axle reports as a wheel error, which sounds like a hardware fault and is not. We also logged completed runs with no incident, so we would know the denominator rather than just accumulating a pile of bad days.
We ran this across a normal, lived-in home over several months, on a single robot on a single map, with furniture that moved occasionally the way furniture does. The robot was mid-range, LiDAR-navigating, with a combination brush — which matters, and we’ll come back to why.
Now the limits, stated plainly, because a log like this can be over-read very easily. This is one robot in one home. We cannot tell you that cables are the top hazard in your home, because that depends entirely on how many exposed cables you have. What we can tell you is that the shape of the finding — extreme clustering, physical causes dominating navigation causes, error strings misattributing blame — reproduced consistently and is the part we’d expect to transfer. The specific ranking is ours; the structure is probably yours too. We also cannot separate “the robot got better” from “we got better at the house,” because we were modifying hazards as we found them — this was a lived process, not a controlled experiment, and treating our totals as a benchmark between robot models would be a misuse of them. Finally, we have no data on high-pile carpet homes, on homes with small children’s toys as a permanent floor condition, or on multi-story deployments, all of which we’d expect to change the ranking materially.
| Observation from the log | What we initially assumed | What it actually meant |
|---|---|---|
| “Wheel error” reported repeatedly | Failing drive motor | Charger cable wrapping the axle; motor was fine |
| “Brush jam” on the same rug weekly | Rug too thick for the robot | Fringe on one edge only; rest of the rug was fine |
| Robot halts under one sofa, never the other | Robot avoids dark spaces | Clearance tapered from 4.1 in to 3.4 in — it could enter but not exit |
| “Cliff sensor” errors on a dark floor mat | Sensor failure | Matte black surface reflected too little IR to read as floor |
| Failed runs cluster on weekends | Coincidence | More objects on the floor when the house is occupied |
That third row is the one we tell people about first, because it explains the single most common mystery in this whole category — why a robot gets stuck under one couch and not another that looks identical. The answer is almost never the couch’s height. It’s the change in the couch’s height from front to back.
Cables Are the Number One Hazard and It Isn’t Close
If you do exactly one thing after reading this page, do this one. Cables produced more stuck events in our log than any other cause, and they are also the cheapest and fastest hazard to eliminate. There is no other item on this list with that ratio.
The mechanism is specific and worth understanding, because it explains why “I tucked the cables away” often doesn’t work. A robot doesn’t get stuck by bumping a cable. It gets stuck because the side brush — a spinning arm designed to sweep debris from edges into the robot’s path — is functionally a cable-grabbing machine. It hooks a loop of cord, pulls it inward, and feeds it to the main brush roller, which winds it up like a fishing reel. By the time the robot halts, the cord is wrapped around the roller axle or the wheel, and freeing it means flipping the robot over and sometimes cutting the cord. The robot’s obstacle avoidance, however good, was never the relevant system: a slack cord lying flat is not an obstacle. It’s floor. Right up until it’s around the axle.
That’s why the fix is not “avoid cables better” — it’s “have no slack cord in reachable floor space.” The distinction matters enormously in practice. A cable that runs from a lamp to a wall socket with fifteen inches of slack pooled on the carpet is a hazard no robot will ever reliably survive. The same cable with the slack taken up and clipped to a table leg is not a hazard at all, for any robot. This is the rare case where the accessory genuinely is the answer, and the accessories in question cost a few dollars. A set of adhesive cable clips run along the back of a media unit, or a cable management sleeve that gathers four cords into one thick trunk the robot reads as an obstacle rather than eating, will do more for your success rate than any firmware update ever will.
The pattern we’d flag: phone and laptop chargers are worse than appliance cables, and it isn’t close. Appliance cables tend to be permanently routed, taut, and behind things. Charger cables are light, thin, slack, and move daily — plugged in by the sofa on Saturday, still there Monday when the robot runs. This is exactly why our failure rate spiked on weekends. It wasn’t the day. It was who was home dropping cords on the floor.
Height Traps: The Robot Climbs In and Can’t Climb Out
The second-largest class in our log is the one people find least intuitive, so it’s worth being precise about the mechanism.
A robot vacuum can climb. Most will mount a threshold or a low obstacle of somewhere around three quarters of an inch without complaint, and they do it constantly and successfully. The problem is that climbing in and climbing out are not symmetrical. Going in, the robot has a running start, a ramp angle it likes, and full traction. Once it’s on top of the obstacle — a low sofa rail, a floor vent, the raised lip of a laundry-room threshold — its drive wheels can end up partially unloaded, its underside can be resting on the obstacle, and the geometry it needs to reverse off is not the geometry it used to get on. It has driven itself into a place where it cannot generate traction. Everything is working perfectly. It just cannot move.
The tapering-clearance version of this is the most common and the most maddening: a sofa whose base is 4.1 inches off the floor at the front and 3.4 inches at the back. The robot is 3.7 inches tall. It drives in cleanly, gets progressively more wedged as the clearance shrinks, and comes to rest jammed under the frame with its bumper compressed and its wheels spinning. It will do this every single run, forever, because from the robot’s point of view the entrance was a perfectly legal move.
The diagnostic is a tape measure and ninety seconds. Measure the clearance at the back of every piece of furniture the robot goes under, not the front. If the rear clearance is less than about an inch above the robot’s height, that’s a trap, and no amount of software will fix it. Your options are: raise the furniture with furniture risers so the rear clearance clears the robot comfortably, block the entrance so the robot never enters, or accept it and set a no-go zone in the app. All three work. What doesn’t work is hoping.
| Rear clearance vs robot height | Behavior we logged | What to do |
|---|---|---|
| More than +1.0 in | Enters and exits cleanly, no events | Nothing; this is fine |
| +0.4 to +1.0 in | Usually fine; occasional bumper-drag stall | Watch it; risers if it recurs |
| 0 to +0.4 in | Frequent wedging; the classic trap | Risers or no-go zone |
| Below robot height | Never enters; not a hazard at all | Nothing; low furniture is safe furniture |
That bottom row is the counterintuitive gift in this data. A sofa sitting flat on the floor is safer than a sofa on three-inch legs. The dangerous zone is narrow and specific: clearances just barely above the robot’s height. Furniture that’s obviously too low is never a problem. If you’re buying furniture and you own a robot, the two safe choices are “clearly too low to enter” or “clearly high enough to leave,” and the thing to avoid is the middle.
Rugs, Fringe, and the Edge Problem
Soft goods were our third class, and the finding here is narrower than we expected. The complaint people voice is “my robot can’t handle rugs.” Our log doesn’t support that as stated. Our robot handled the large majority of rug surface area indefinitely without incident. What it could not handle was rug edges — and specifically, one kind of edge.
Fringe is the killer. A tasselled or fringed edge is, to a side brush, indistinguishable from long debris that should be swept up, so it sweeps it up, wraps it, and jams. The rug’s pile height, which is what everyone worries about, mattered far less than whether the perimeter was bound or loose. A thick bound-edge rug was a non-event. A thin fringed rug was a weekly failure. Curtains that puddle onto the floor behave identically and for the same reason — a side brush cannot tell a curtain hem from a dust bunny.
The second rug mechanism is lifting. A lightweight rug that isn’t anchored gets pushed into a ridge by the robot’s bumper, the ridge lifts a drive wheel off the floor, and traction goes. This one has a genuinely trivial fix: rug grippers or double-sided rug tape at the corners. It’s the cheapest intervention on this entire page and it eliminates an entire failure mode.
If you have a fringed rug you love, you have three honest options and none of them are “hope the next robot is smarter”: tuck the fringe under the rug edge, set a no-go zone around that rug’s perimeter and accept vacuuming its edge by hand, or run the robot only when you’re home to intervene. We ended up doing the first, and it worked, and it stayed working, which is the highest praise we can give any smart home intervention.
The Sensor Cases: Dark Floors and Phantom Cliffs
This class is small in count but it produces the most alarming symptom — a robot that stops dead in the middle of an open floor and reports a cliff error, as if it’s standing at the top of a staircase in the center of your living room.
The mechanism is that cliff detection works by bouncing infrared light off the floor and measuring the return. Floor present, light comes back, keep driving. Stairs ahead, light doesn’t come back, stop. It’s simple and it’s reliable and it fails in exactly one situation: a floor surface so dark and so matte that it absorbs the IR and returns almost nothing. To the sensor, a matte black doormat and an open stairwell are the same reading. The robot is not malfunctioning. It is correctly reporting what it sees, and what it sees is a void.
This is worth naming clearly because the instinct is to conclude the sensor is broken and the robot needs service, and it doesn’t. Test it: pick the robot up, put it on a light-colored floor, and see if the error clears. If it does, your problem is a floor surface, not a sensor. The fixes are to remove or replace the dark item, put down a lighter mat, or set a no-go zone over it. And separately: cliff sensors are small windows on the underside of the robot and they collect dust. If phantom cliff errors appear gradually over months on floors that used to be fine, flip the robot and wipe the sensor windows with a microfiber cleaning cloth before you conclude anything else. Dust on the sensor and darkness on the floor produce identical symptoms, and one of them takes ten seconds to rule out.
Maintenance Masquerading as Navigation
One more pattern deserves its own section, because it took us longer to see than it should have. A robot with a hair-wrapped brush roller, a clogged filter, or fuzzy caster wheels does not report “I need maintenance.” It reports getting stuck more often. The mechanism is unglamorous: a wound-up roller increases drag, a fouled caster stops swiveling freely, and the robot’s ability to climb a threshold or reverse out of a tight spot degrades. It’s still navigating fine. It just has less physical margin than it used to, and margin is exactly what it spends when it gets into trouble.
We noticed this as a slow creep — a robot that had been reliable for months getting stuck twice a week — and we went looking for a software cause. There wasn’t one. There was a brush roller with a dense band of hair at each end and a front caster that had stopped rotating. Ten minutes with a seam ripper and the stuck rate went back to where it had been. If your robot has gotten worse over time rather than always having been bad, look here first. A replacement brush and filter set is a low-cost consumable, and treating it as one rather than as a repair is the correct mental model.
The Order We’d Fix Things In
Given all of the above, here is the sequence we’d actually run, ordered by payoff per minute spent. This is the decision helper we wish we’d had at the start.
| Step | Action | Cost | Why this order |
|---|---|---|---|
| 1 | Log the next 5 stuck events: room, position, what it’s touching | Free | You cannot fix a cluster you haven’t located. Everything below is guessing without this. |
| 2 | Eliminate all slack cord in floor space | A few dollars | Largest class in our log, cheapest fix, works for every robot |
| 3 | Measure rear clearance under every enterable furniture piece | Free | Finds the tapering traps that repeat forever |
| 4 | Anchor loose rugs; tuck or exclude fringe | A few dollars | Eliminates the lifting and jamming modes |
| 5 | Flip the robot: clear the brush, wipe cliff sensors, free the caster | Free | Restores physical margin; fixes gradual degradation |
| 6 | Only now: no-go zones for whatever still repeats | Free | Zones are a bandage; use them on what you couldn’t physically fix |
| 7 | Only now: consider a different robot | Expensive | If steps 1-6 didn’t fix it, you have a real capability mismatch |
The thing we want to underline is the position of step 7. Almost everyone starts there. In our experience it belongs last, because a new robot inherits every hazard the old one died on. The cord that wrapped your current robot’s axle will wrap the new one’s axle too. Buying hardware to solve an environment problem is the most expensive way to not solve it.
We’d also flag step 6 more strongly than most people do. No-go zones are genuinely useful and we use them. But every zone you draw is floor that no longer gets cleaned, which means the robot’s job is now partially yours again, which is the thing you were trying to avoid. A zone is what you do when the physical fix isn’t available — a radiator you can’t move, a cable run you can’t reroute. Reaching for zones first gets you a robot that reliably cleans less and less of your house.
Symptom to Cause, at a Glance
| What you observe | Most likely cause | First move |
|---|---|---|
| Same spot every run | Height trap or fixed hazard | Measure rear clearance there; look for cord |
| Different spot every run | Movable objects on floor | Floor-clear routine before scheduled runs |
| “Wheel error,” robot free-standing | Cord wrapped on axle | Flip it over and look; don’t book service |
| Cliff error mid-room | Dark surface or dusty sensor | Test on light floor; wipe sensor windows |
| Worse than it was 6 months ago | Brush/caster/filter fouling | Full flip-and-clean; replace consumables |
| Stuck only when household is home | Cords and objects, not the robot | Schedule runs for when the house is empty |
| Halts on rug edge only | Fringe or unanchored corner | Tuck fringe; add gripper pads |
That second row deserves a comment. If your stuck events genuinely have no spatial pattern — different place every time, nothing in common — you have a different problem than this page describes, and it’s usually a floor-clutter problem rather than a robot problem. The honest answer there is that a robot vacuum requires a floor that is clear of small objects, and a house that can’t reliably provide that will not get good results from any robot at any price. That’s not a satisfying conclusion, but it’s the true one, and we’d rather say it than sell you a fix that won’t work.
The Failure That Isn’t A Stuck Event: Not Making It Home
There is a sibling failure worth separating out, because it lands in the same “the run didn’t finish” bucket and has a completely different cause. Your robot cleans the whole house successfully, then strands itself somewhere on the way back to the dock and reports that it can’t find its base. Nothing was wrong with the cleaning. Nothing was physically holding it. It simply could not get home.
In our log this behaved unlike every other class. It correlated with dock placement, not with hazards, and it responded to nothing we did to the floor. Docks need two things people routinely deny them: a run of clear wall to sit flat against, and open floor in front — the robot navigates back by locating the dock’s signal and then making a fairly precise final approach, and it needs room to line that approach up. A dock tucked into a corner, squeezed between a chair leg and a bookcase, or set on a rug that shifts under it produces a robot that homes reliably right up until it doesn’t. The nastiest variant is a dock that gets nudged a few inches during cleaning and no longer matches where the map says it is.
The reason we flag this separately is that it gets misread as a battery problem. The symptom is a robot that dies partway through a return, which looks exactly like a robot that ran out of charge, which sends people shopping for a battery replacement. Check the dock’s surroundings first. If the robot is reaching the dock’s general area and then failing at the last few feet, that is an approach-geometry problem and a battery will not touch it. Move the dock to a clear wall, give it a couple of feet of open floor either side, make sure it is not on a rug that can slide, and re-run the map. That fix took us five minutes and eliminated the class.
Scheduling Is a Hazard Control, Not a Convenience
The last thing our log taught us was about time rather than space, and it is the intervention we recommend most often now because it costs nothing at all.
Our failure rate was meaningfully higher on days when the house was occupied during the run. We initially filed this as noise. It is not noise, and the mechanism is obvious in retrospect: an occupied house has more things on the floor. Shoes get kicked off. Chargers get plugged in beside the sofa. Bags get set down. A robot that runs at two in the afternoon on a Wednesday encounters a floor that has been undisturbed since morning. The same robot running at seven on a Saturday evening encounters an obstacle course that was assembled in the previous four hours by people who were not thinking about it.
This reframes scheduling. Most people set a run time based on noise — when will this not bother me. That is a reasonable goal and it is the wrong optimization. The better question is when your floor is at its cleanest state, which for most households is the middle of a weekday, and which happens to also be when nobody is home to be bothered. If your robot is stuck constantly and you run it in the evenings, try moving it to the middle of the day before you buy or modify anything. It is free, it takes thirty seconds, and in our log the day-of-week effect was large enough that we would try it before any physical intervention on the list.
Frequently Asked Questions
Will a more expensive robot with better obstacle avoidance solve this?
Partially, and less than you’d hope. Camera-based obstacle avoidance genuinely helps with cords and socks — it’s the one area where the premium tier earns its money. But it does nothing about tapering-clearance traps, because entering the sofa was never an error the robot recognized. It does nothing about rug fringe, because the side brush encounters the fringe from the side, not the front. And it does nothing about a dusty cliff sensor. Our honest read: obstacle avoidance shrinks the largest class in our log but leaves classes two through five intact, and it costs several times what a bag of cable clips costs.
Why does the app report a wheel error when the wheel is fine?
Because the robot can only report what its sensors measure, and what a wrapped axle measures as is a wheel that isn’t turning when the motor says it should be. That’s the definition of a wheel error from the firmware’s point of view. It has no way to see the cord. This is the most consistent misdiagnosis in the whole category, and the reason we tell people to flip the robot over before doing anything else with a wheel error.
Should I use no-go zones or fix the physical hazard?
Fix the physical hazard when you can, use zones when you can’t. The reason is that a zone permanently removes floor from the robot’s job, and those zones accumulate — we’ve seen homes where the robot cleans maybe half the floor because every problem got a zone drawn around it. Zones are the right tool for immovable objects. They’re the wrong tool for a cord you could clip to a table leg in thirty seconds.
My robot used to be fine and now it gets stuck constantly. What changed?
Something physical, almost certainly, and in our experience it’s one of three things: a maintenance creep (hair on the roller, a seized caster, a loaded filter), a furniture move that created a new trap, or a new cord in the house. Check in that order. A firmware update can change navigation behavior, but “it got gradually worse over months” is a wear curve, not an update — updates change things overnight.
Is it worth putting the dock somewhere else?
Sometimes, and it’s an underrated fix. Docks want a stretch of clear wall with open floor in front, and a dock crammed into a corner or behind a chair leg produces a robot that cleans fine and then fails to return home, which reads as a navigation failure and isn’t. If your stuck events cluster near the dock specifically, move the dock before you troubleshoot anything else.
Do I actually need to log the events, or can I just fix the obvious stuff?
You can just fix the obvious stuff, and cable management plus rug anchoring will get most people a large improvement without any logging at all. The reason we push the log is that it tells you when to stop — when your remaining events are two per month in one spot you’ve decided to live with, you’re done, and you can stop thinking about it. Without the log there’s no finish line, and people keep buying things.
Methodology and Who Wrote This
This page is built from an incident log kept on a single mid-range LiDAR-navigating robot vacuum with a combination brush, running on one map in one occupied home over several months. We recorded room, position, reported error, and physical contact at each halt, plus incident-free completions to establish a denominator. Interventions were applied as hazards were identified, which means the log is a record of a real remediation process rather than a controlled trial — we can describe what we found and in what order, but we cannot cleanly separate improvements caused by our fixes from any other change over the period.
What we believe transfers: the clustering structure, the dominance of physical causes over navigation causes, the tapering-clearance mechanism, the misattribution of cord wraps as wheel errors, and the fix ordering. What we believe does not transfer: our specific class ranking, which depends entirely on how many exposed cables and fringed rugs a given home contains. A home with no loose cords will find height traps at number one. We have no data on high-pile carpet, on homes with permanent floor-level toy clutter, or on multi-story robot deployments, and we would not extend any of this to those cases.
We are the Smart Home Guide Editors. We write about the smart home from the position of people who run these devices in a normal house and get annoyed by them, and we try to tell you when the honest answer is “this is a limitation, not a bug.” When we link to a product, it is because it appeared in the fix path above, and those links are affiliate links. Nothing on this page is a review, and no manufacturer had any input into it.