M7-T6 — Recovery Behaviors and Stuck Detection

Learning objectives

After this lesson, you should be able to:

• Define “no progress” as the change in distance to the goal over a time window, and explain why distance driven is the wrong measure.
• Order recoveries (clear, wait, back up, spin) by cost and risk and give each a precondition.
• Explain why a recovery needs a cooldown and a budget, and what escalation looks like.
• List the false alarms that a stuck detector must avoid and how to tell them apart.

The intuition

If you are stuck in a crowd, the signs are easy to feel: your feet move, and you are not getting nearer to the door. Your legs are not the evidence. The evidence is the distance to the door. A robot should judge itself the same way. Wheels turning, odometer counting and velocity commands flowing say that the robot is trying. Only the goal getting closer says that it is succeeding.

That is why a rocking robot is so easy to miss. It covers metres in a few minutes by driving back and forth, and any rule that watches speed or distance driven sees a busy, healthy machine. A rule that watches progress towards the goal over a window of time sees a flat line.

Once stuck is detected, the question is what to try. The chances are better with a short list in a sensible order than with the robot’s whole bag of tricks at once. Clearing the costmap takes a second and cannot hurt. Waiting costs time and cannot hurt. Backing up and spinning move the body and can hurt, so they come later and only if there is room. When the list is spent, the most reliable resource left is a person.

The mathematics

Progress over a window

Let d(t) be the distance from the robot to its goal (straight-line, or along the current path), W a window in seconds and ε the least progress that counts. The robot is stuck at time t if it has at least W seconds of history and

Use the latest sample at or before t − W, not “the sample 10 steps back”, so that the rule survives a change of sample rate. Compare this with the distance driven in the window, L = Σ ‖p_i − p_i−1‖. A robot that rocks has a large L and a progress near zero.

W

window: longer than the longest normal pause, shorter than the time you are willing to wait.

ε

minimum progress in the window, in metres. Larger than sensor and pose noise, smaller than the progress of the slowest legitimate motion.

d(t)

distance to the goal. With a winding path, use distance along the path or progress along it.

A different but common choice, used by Nav2’s simple progress checker, asks whether the robot has moved more than a radius from where it was a time allowance ago. It does not look at the goal, so it tolerates detours that temporarily increase the distance, and it catches rocking only if the amplitude is below the radius. The two rules complement each other. Parameter values (a radius of about half a metre and an allowance of about ten seconds are typical) must be checked in the documentation and tuned for the robot.

Recoveries

To compare them, put cost and risk in the same unit, for example cost in seconds plus a fixed penalty per risk level (lab M7-L4 uses 10 s). Cheapest first then minimises the average cost when the faults are equally likely, and keeps the risky moves for last.

Cooldown and budget

A trigger starts a recovery; the recovery needs time to work, and the detector stays true for as long as the robot has not yet moved. If the detector restarts the recovery every sample, no recovery ever finishes. A cooldown C suppresses a new trigger until C seconds after the last. A budget limits the total number of recoveries per goal; when it is spent, the robot stops trying and asks for help.

A worked example

The detector on Scout. Take W = 10 s and ε = 0.35 m. Three kinds of motion, all with the robot 12 m from its goal:

motion                          distance driven    progress     verdict
rocking ±0.12 m, period 4 s    1.2 m / 10 s       ≤ 0.24 m     stuck
creeping at 0.06 m/s           0.6 m / 10 s       0.6 m        moving
paused 9 s, driving 1 s        0.6 m / 10 s       0.6 m        moving

Rocking drives twice as far as creeping, and is the one that is stuck. A detector based on distance driven with the same 0.35 m threshold calls the rocking robot healthy (lab M7-L4, stage 1). The progress bound for rocking is the amplitude swing: with a ±0.12 m motion along the line to the goal, two samples differ in distance by at most 0.24 m, which is below 0.35 m at every phase.

When it fires. The robot drives at 0.6 m/s until t = 20 s and then rocks. The progress in the window ending at t is 0.6 · (30 − t) while the window still contains driving, which falls below 0.35 m after t = 29.4 s. With one sample per second the detector fires at t = 30 s: ten seconds of lost time. With a cooldown of 15 s it fires again at 45 s and 60 s if the robot is still stuck, a series that a tree can escalate: clear the costmap, wait, back up (lesson M7-T5).

What the choice of W costs. A shorter window finds trouble sooner and also fires during a normal 6 s pause at a door. At W = 4 s the same pause gives progress 0 and a false alarm. The window must exceed the longest legitimate stop, or the mission must tell the detector that a stop is expected (for example “waiting for the lift”).

Which recovery next. Scout is stuck, has cleared the costmap, a person is near, there are 0.3 m behind it and 1.0 m all round. Wait is applicable (person near). Back up needs 0.5 + 0.1 = 0.6 m behind: not available, so it is skipped. Spin needs the circumscribed radius 0.36 + 0.1 = 0.46 m all round: available. After the wait fails, the next recovery is spin.

Engineering implications and limitations

Measure progress where it matters

Distance to the goal is simple but misleads on a winding route: going around a wall increases it. Progress along the planned path, or a combination with the radius test, is more robust. Check both against recorded runs, including ones that were fine, to see how often each fires.

Give the detector context

Many stops are legitimate: waiting for a lift, queueing for a door, letting a trolley pass, charging. If the mission knows, tell the detector, or the robot will interrupt a patient transport to rock and spin. An unexplained stop in a corridor is the case to act on.

Recoveries that move the body need a check

Before backing up or spinning, look at the costmap behind and around the robot. Use the circumscribed radius for spinning and the length of the back-up path for reversing, and add margin for pose uncertainty (lesson M7-T3). Where the robot has no rear sensor, do not reverse blind.

Escalate and then stop

The last rung is a request for help with evidence: where, since when, what was tried and a picture of the costmap. A robot that fails silently turns a minor delay into a lost delivery. Set a budget so that the robot does not keep running recoveries for an hour.

Record and review

Each trigger and each recovery goes in the log with its cause if known. Counting how often each recovery works tells you which to put first on this site (lessons M1-T6 and M9-T5).

Scope

These are engineering patterns for getting a robot unstuck. They are not a safety function. Whether a back-up manoeuvre is acceptable near people is a question for the site’s risk assessment and the standards that apply to the machine.

Common misconceptions

Engineering takeaways

1. Stuck means no progress towards the goal over a time window, not “the wheels are not turning”.
2. Use the latest sample at or before now − W, a threshold above the noise and a window longer than normal pauses.
3. Order recoveries by cost and risk, check preconditions (room behind, room to spin), and use each at most once.
4. A cooldown gives a recovery time to work; a budget makes the robot ask for help instead of trying for ever.
5. Rules for recoveries near people belong to the site’s risk assessment, not to this lesson.

References and further reading

The Office Marathon paper describes the original recovery behaviours; the Nav2 pages describe today’s progress checkers and behaviour server.

• E. Marder-Eppstein, E. Berger, T. Foote, B. Gerkey and K. Konolige, “The Office Marathon: Robust Navigation in an Indoor Office Environment”, IEEE ICRA, 2010.
• Nav2 documentation, “Simple Progress Checker”, “Behavior Server” and “Behavior Tree” pages, docs.nav2.org.
• ROS wiki, “move_base”, “clear_costmap_recovery” and “rotate_recovery” packages, wiki.ros.org.

Knowledge check

Three conceptual questions. Write an answer, then reveal the explanation. Your answers stay in your browser.

What’s next

Next: the worst stuck of all, a robot that no longer knows where it is.

Related content

Nothing below is required to finish this lesson.

• Before
  M7-T5: Behavior Trees for Navigation

  Read and write a small behaviour tree (sequence, fallback, condition, action) that wraps planning and recovery.

• Lab
  M7-L3: Build a Recovery Behavior Tree

  Scout gives up at the first obstacle: build a tree that retries, clears, backs up and then asks for help.

• Lab
  M7-L4: Detect and Escape a Stuck Robot

  Scout rocks back and forth for ten minutes without noticing: detect no-progress and break out.

• Lab
  M10-L1: The Shift Simulator

  Run a full compressed shift with your own planner, controller and recovery logic, scored on hidden shifts.