What Is Localisation, and Why Do Robots Get Lost?

Localisation is a robot's running answer to where am I, and robots get lost because wheel counting, cameras and beacons each drift or fail quietly. A better sensor rarely fixes it; the work is picking a method whose failure you can tolerate, and ROS 2 ships those methods while HORUS only carries their answers. What flips this is a space that changes daily, where a stored map stops being true. The rest of this post is for a first robot builder whose machine wanders off course, drives into furniture it already avoided, and cannot say why.

Your robot worked yesterday. It drove the length of the corridor, turned at the end, came back, and stopped where you told it to. Today it drove the same corridor, turned slightly early, and finished a stride short of the door, and you changed nothing in between.

The frustrating part is that nothing looks broken. The motors respond. The distance sensor reports sensible readings. The code that decides what to do is the same code that worked on Tuesday. If you print out what the robot believes about its own position, the numbers look entirely plausible. They are simply wrong, and they get more wrong the longer the machine runs.

So you start compensating. A fudge factor on the left wheel. A rule that says turn a little less than the geometry suggests. The robot gets better for a week and then finds a fresh way to be wrong, usually on carpet, or after somebody moves a chair, or on the fifth lap when the first four were perfect. Eventually the suspicion arrives that the problem was never in the driving code. The robot does not know where it is. It has never known, and everything you built assumed it did.

Do you actually need your robot to know where it is?

Plenty of useful robots never know, and leaving position out is the largest saving available to a first project. A line follower knows only whether the tape lies to its left or its right. A vacuum that bumps, turns and carries on covers a room without ever holding an opinion about which room. An arm bolted to a bench has no position problem at all, because the bench does not move, though its difficulties are considerable and entirely elsewhere. The test is quick: read every instruction you want to give your robot and see whether any of them names a place. Follow the wall until a doorway opens needs no map. Go to the kitchen and come back cannot be obeyed without one. If the naming can be pushed out into the world instead of into the software — tape on the floor, a rail, a hard stop at the end of the run, a docking station that guides the robot in over the last stretch — take that trade every time. Position is not a feature you bolt on. It is a second system with its own sensors, its own failures and its own long evenings.

What is localisation in plain terms?

Localisation is a robot continuously answering one question — where am I, and which way am I pointing, relative to something fixed — and it is a different job from mapping, which is producing the fixed thing to be relative to. Doing both at once, drawing the description while finding yourself inside it, is what people mean by SLAM. The everyday version is walking through your own house in the dark. You take a step and update a guess, the guess grows vaguer with every step, and then your hand finds the doorframe and you know precisely where you are again. Every localisation system on every robot is that same pair: a cheap guess that updates constantly and decays, plus an occasional correction from something the machine can recognise. Counting wheel turns is the guess. A laser scanner matching what it sees against a stored map is the correction. Almost everyone builds the first half, gets a robot that is right for a minute and wrong for an hour, and only then discovers that the second half was the actual job.

What does it look like when a robot gets lost?

A lost robot does not stop and ask for help; it acts confidently and wrongly, which is precisely what makes the fault hard to find. The signs are ordinary. It turns a little early and clips the door frame. It drives into a wall that is drawn correctly on its own map. It steers towards a corner as though a doorway were there. On screen the map smears, or the same corridor appears twice at a slight angle to itself. Sometimes the robot seems to teleport, because the estimate abandoned one candidate and snapped to another. There are two distinct shapes here and it matters enormously which one you have. Drift is smooth: the start of a run is fine, the end of it is not, and the error grows with distance travelled. Divergence is sudden: the estimate leaps somewhere wrong and stays there, unshakeably certain, usually because two parts of the building look identical or because somebody picked the robot up. Gradual failure means nothing is correcting the guess. Sudden failure means the correction was fooled. Those want opposite fixes, and a robot that behaves differently every run usually has the first.

What are the actual ways to tell a robot where it is?

Six families exist, and in practice they are combined rather than chosen between. Wheel odometry counts motor turns and works out where they should have carried the machine, which costs nothing and stays true only briefly. Inertial sensing measures turning and shaking, patching the part odometry is worst at. Installed landmarks — ceiling tags, radio anchors, a reflective strip beside a dock — give an answer that never decays, wherever you were allowed to mount them. A laser scanner matched against a map is the classic indoor route, working because buildings are full of flat surfaces that stay put. Cameras do the same job by recognising the look of a place, trading a cheaper sensor for a hungrier computer. Satellite positioning with a correction signal is effortless outdoors and useless indoors.

Almost none of that is software you should write yourself. ROS 2 already contains maintained packages for building a map, for matching a scan against one, and for the coordinate bookkeeping underneath both, which is why most localisation questions turn out to be ROS 2 questions. A middleware such as HORUS — open source under Apache-2.0, with Rust, Python and C++ sharing the same shared-memory ring buffers on one machine — is not an alternative to any of that. It carries the finished estimate from the program that produces it to the program steering the wheels, and it supplies no map of its own.

How do the options for knowing your position compare?

Read the third column before anything else, because a method you cannot debug on a bad evening is not really available to you whatever its merits. Then cross out every row whose last column describes your situation today. What survives is normally a pair rather than a winner, and that is the correct outcome: nearly every working robot runs a cheap continuous guess alongside a slower correction, and the interesting choice is which correction. Notice also that the final row is not a lesser answer. Changing the building is the oldest trick in the industry and warehouses full of robots still rely on it.

Which approach fits a first robot in a single room?

Fuse wheel odometry with an inertial sensor, add exactly one thing in the room the robot can recognise, and stop there. The odometry gives a smooth guess that is good over short stretches. The inertial sensor rescues the turns, which is where a two-wheeled robot loses its heading first and worst. The one recognisable thing — a printed tag on the wall above the charging dock, a strip of reflective tape, a distinctively shaped corner — resets the accumulated error every time the robot passes it. That combination is buildable in a weekend, fails in ways you can see with your own eyes, and teaches you the shape of the problem before you commit to anything larger. Resist the urge to start with mapping. A full map of one room solves a problem you do not have yet, brings a scanner, a set of parameters and a viewer you have not learned to read, and hides the thing you most need to develop, which is an instinct for how quickly your particular robot goes wrong and what pulls it straight again.

What does your hardware allow you to do about position?

Your hardware has already narrowed the list, usually more than your preferences have. A microcontroller with no operating system can count encoder ticks and read an inertial sensor, and that is close to the whole menu; anything map-shaped needs a computer it does not have, so plan around landmarks and short routes. A small single-board Linux computer can genuinely run a modest laser scanner and a mapping package, but a camera-based approach on the same board will spend most of the machine on images and leave your control code waiting. Then there is what the robot stands on. Tracked vehicles skid by design, so the wheels lie about distance every time the machine turns. Mecanum wheels slide sideways on purpose and lie constantly. Legged robots have nothing useful to count at all and lean much harder on inertial sensing and vision. If your robot's feet are unreliable narrators, the cheap guess is weaker than the textbooks assume, and you need corrections more often than a wheeled robot on a hard floor would.

How long does it take to get localisation working?

A weekend gets a map on screen, and several weeks get a robot that survives a whole day without a human rescuing it. Those two milestones look close together and are not. The first is genuinely quick with a supported scanner and a maintained package: drive around, watch the room appear, feel briefly like this was easy. Then the long middle begins. The map is fine but the robot loses itself near the glass door. It works in the morning and fails in the afternoon because sunlight changes what the camera sees. It survives most of a lap and loses itself on the next one. Each of those is a day or two of narrowing down, and there is no shortcut because the failures are situational rather than logical. If you have a month and a demo, do not start a mapping project. Install landmarks along the exact route the demo needs, accept that the answer only exists on that route, and spend the time you saved on the behaviour people will actually watch.

How much maths do you need to understand localisation?

None to run it, and a good deal more than you expect the first time it breaks. Running a maintained mapping package needs no probability theory whatsoever; you launch it, drive around and it works. The maths arrives when it stops working, because the failure will not be a crash and there will be no error to search for. To make progress you need a working intuition for three things. First, uncertainty: every estimate has a spread as well as a value, and a system that reports a confident wrong answer is broken in a specific and diagnosable way. Second, coordinate frames: where each sensor sits relative to the others, and how an obstacle can be reported in the wrong place by code that is doing exactly what it was told. Third, time: two readings combined without agreeing on when each was taken will produce a robot that acts on a moment which has passed, and fusing inertial and wheel data honestly is mostly about that. None of this requires a degree. It does require refusing to treat any of the three as bookkeeping.

What do you give up by choosing one of these approaches?

Every method buys certainty in one place and spends it somewhere else, so the choice is which cost you would rather carry. Odometry is free and stops being true almost immediately. Landmarks give an answer that never decays and require you to own the building, mount hardware and record where each piece went. Laser mapping is general and brings a heavier sensor, a longer list of parameters, and an assumption that the space has structure to match against. Cameras are cheap to buy and expensive to run, and they have opinions about lighting that you will discover in the afternoon. Satellite positioning is effortless and disappears indoors. Beyond the individual trades there is a shared one: the moment a robot holds a position, that position becomes a permanent dependency. Every new sensor must be positioned relative to the others, every reading needs an honest timestamp, and every behaviour you write is now allowed to assume something that will occasionally be wrong. That last part is the real bill, and it does not appear until the robot is already useful.

When is ROS 2 the better choice?

ROS 2 is the better choice for almost any robot whose central difficulty is knowing where it is. Mapping, scan matching against a map, recovering from divergence, planning a route across the result and the coordinate bookkeeping holding it together are years of specialist work by people who do nothing else, and they are available, maintained and free. If your robot must drive to places a human names, use ROS 2 and stop deliberating, because the alternative is reproducing a research field badly. If your laser scanner's only working driver ships as a ROS 2 package, that settles it too. If you need to see what the robot believes about the room, ROS 2 has the viewer, and being able to watch a wrong belief is most of debugging. And if the robot is one of several machines that must agree about a shared space, ROS 2 has lived in that world for years. HORUS is not the answer in any of these cases; a messaging layer moves an estimate around and cannot produce one, which is also the honest summary of what a mobile robot really needs.

Does a better sensor fix a robot that keeps getting lost?

No, and here is why: getting lost is a failure of interpretation, and a sensor only supplies material to interpret. The usual story runs like this. A builder whose robot drifts buys a laser scanner, fits it, and finds the robot still ends up in the wrong place — now with more data and a longer list of things to blame. The drift was never a shortage of measurements. It was that nothing in the software combined the measurements with the guess, or that the two disagreed about when each was taken, or that the map on disk describes a room that has since been rearranged. Upgrading only helps when the missing ingredient was information the old sensor could not physically provide, and that is a much narrower case than it feels like at the moment of ordering. Before spending anything, run one test. Drive the robot in a square back to its starting point and see how far the estimate says it is from where it visibly is. If that error grows smoothly, you need a correction, not a better guess.

Have learned models made localisation a solved problem?

Partly, but not the way you think. Learned models are genuinely good at recognising a place from an image, and that has made camera-based localisation practical in buildings where it used to be hopeless. What they do not provide is the continuous estimate underneath. Recognition tells you that this looks like the corridor by the lift; it does not tell you where you are between recognitions, it arrives too slowly for a control loop that must decide what the wheels do next, and it fails silently in exactly the situation that hurts most, which is a building with repeated identical spaces. So the classical filter is still there, holding the running guess and being corrected by the model rather than replaced by it. There is a further catch that shows up on real floors: a model that knows your building learned it from your building, so the day the furniture moves is the day recognition quietly degrades. That is the same gap described in why a robot that works in simulation fails in your kitchen.

How do you decide which approach to build on?

Start by writing down what the robot must be able to do that requires a position at all, and be strict about it. If the list is empty, you have just saved yourself a month. If the list is short and the route is fixed, put landmarks on the route and treat the whole question as an installation job rather than a software project. If people will name places the robot has never been told about, you need a map, and you should take one from ROS 2 rather than write one. Then ask the shape questions. How long does the robot run between human contact, because that sets the drift you can tolerate? Does the space stay still, because a map of a room rearranged hourly is a liability rather than an asset? Indoors or outdoors, which decides half the list on its own? And how many programs, in how many languages, must agree about the answer?

Decide by situation rather than by principle:

• If your robot never needs to be sent to a named place -> no localisation at all, because the cheapest system is the one you did not build.
• If the route is fixed and you control the building -> installed landmarks, because an answer that does not decay is worth a few brackets and an afternoon.
• If people will name places freely indoors -> ROS 2 with a laser scanner, because mapping and recovery are already written and hard.
• If the machine works outdoors in open ground -> satellite positioning with correction, because nothing else is close for the money.
• If the estimate must be shared between Python vision code and a C++ or Rust controller on one computer -> a shared-memory middleware, because the language boundary is the part that costs you.

When two of those lines describe you, weigh them on the five axes of the HORUS Fit Framework — ecosystem size, setup effort, team size fit, deployment target and licence — and keep whichever loses on the fewest. No score, no numbers: five honest questions about your situation rather than about the software. If your answers keep landing on one computer, more than one language, and a pose estimate that several programs must see at once, star HORUS on GitHub so it is in your list when you start building.