Glossary

Fictionlab > Glossary > Recovery behavior

Recovery behavior

Recovery behavior – definition

In mobile robotics, a recovery behavior is a bounded action executed when the navigation system cannot safely continue its current task. It is used after failures such as an unavailable global path, local controller oscillation, collision risk, blocked costmap cells, or temporary localization degradation.

For ROS-based UGVs, recovery behavior is commonly implemented as part of a navigation state machine or a Behavior Tree. It does not replace obstacle avoidance, localization, or safety supervision. Its purpose is to return the robot to a state in which planning and control can resume, or to stop the task in a controlled manner.

Typical recovery actions include clearing costmaps, rotating in place, reversing, driving forward by a short distance, waiting for dynamic obstacles to move, and aborting the navigation goal. These actions must be constrained by robot kinematics, available free space, sensor coverage, and safety requirements.

Recovery behavior in ROS 2 Nav2

In ROS 2, recovery behavior is most commonly associated with the Navigation2 (Nav2) stack. Nav2 uses Behavior Trees to coordinate planning, control, costmap updates, and recovery actions. A recovery can be triggered when a planner, controller, or progress checker returns a failure condition.

Nav2 distributions based on ROS 2 Humble and later use the nav2_behavior_tree package together with the Behavior Server. The Behavior Server provides reusable actions through ROS 2 actions and plugins. Depending on the Nav2 version, commonly available behaviors include:

  • Spin – rotate the UGV around its vertical axis to observe the environment from a different heading.
  • BackUp – reverse by a configured distance while monitoring collision conditions.
  • DriveOnHeading – move along a specified heading for a limited distance and time.
  • Wait – pause navigation to allow a dynamic obstacle or temporary sensor disturbance to clear.
  • Costmap clearing – remove stale obstacle data from local or global costmaps before replanning. In Nav2 this is done by Behavior Tree nodes calling the costmap clearing services, not by a Behavior Server plugin.

Nav2 recovery logic is configured in a Behavior Tree XML file selected by the bt_navigator node. The default tree can attempt replanning and controller recovery several times before returning failure to the client that sent the NavigateToPose action goal.

Recovery triggers and diagnostic inputs

A recovery action should be initiated from observable navigation failures, not from arbitrary timers alone. The relevant signals are generated by planning, control, localization, transform, and perception components.

Failure condition Typical ROS 2 source Possible recovery
No valid global path Nav2 planner action result, global costmap Clear global costmap, replan, abort if still blocked
Controller cannot make progress Progress checker, controller result Spin, back up, clear local costmap, replan
Oscillation near obstacle Velocity command history, controller status Back up or rotate within a validated free area
Temporary obstacle LiDAR, depth camera, local costmap Wait, then update the local costmap
Invalid TF or odometry data /tf, /odom, diagnostics Stop the robot and reject or abort navigation

A recovery behavior must not be used to conceal persistent sensor, TF, odometry, or localization faults. For example, if the transform between map, odom, and base_link is unavailable, movement should stop rather than initiating a blind reverse maneuver. Frame naming and coordinate conventions should follow REP-105 and REP-103.

Key parameters and safety constraints

Recovery behavior is platform-specific. A differential-drive UGV cannot move sideways, so a reverse or spin maneuver changes the reachable free space differently than it would for an omnidirectional base. Parameters should be derived from the robot footprint, braking distance, wheel slip, sensor field of view, and maximum permitted velocity.

Important configuration parameters include:

  • Recovery distance – the maximum linear distance for BackUp or DriveOnHeading.
  • Recovery speed – a limited linear or angular velocity used during the maneuver.
  • Time allowance – the maximum permitted execution time before the action fails.
  • Footprint collision checking – validation of the full robot footprint against the local costmap.
  • Progress threshold – minimum displacement required within a configured time window.
  • Retry count – the maximum number of recovery cycles before navigation aborts.

The Behavior Server exposes actions through the nav2_msgs interface. Exact action names and plugin identifiers can vary between Nav2 releases, so a deployment should use the documentation matching its installed ROS 2 distribution.

behavior_server:
  ros__parameters:
    behavior_plugins: ["spin", "backup", "wait"]

    spin:
      plugin: "nav2_behaviors::Spin"

    backup:
      plugin: "nav2_behaviors::BackUp"

    wait:
      plugin: "nav2_behaviors::Wait"

This example enables three behavior plugins. It is not a complete safety configuration. Collision checking, robot footprint, velocity limits, sensor observation sources, and emergency-stop logic must be configured separately.

Recovery behavior on Leo Rover and Raph Rover

Leo Rover is a four-wheel differential-drive platform that can use an onboard Raspberry Pi computer and ROS 2. A practical Nav2 recovery sequence for Leo Rover usually begins with local costmap clearing and replanning. If the robot remains blocked, a short reverse or rotation can provide a new LiDAR or depth-camera viewpoint.

Leo Rover is not autonomous out of the box. Recovery behavior requires an integrated navigation stack, valid wheel odometry, a stable odom to base_link transform, and collision-aware perception. When using a 2D LiDAR, the sensor mounting height must be considered because obstacles below or above the scan plane may not be represented in the costmap.

Raph Rover can carry larger sensor payloads and compute hardware. This can support redundant perception, such as combining LiDAR, depth cameras, IMU data, and RTK GNSS in outdoor deployments. Because Raph Rover uses Ackermann steering, it cannot rotate in place, so Spin should be replaced with BackUp or DriveOnHeading in its recovery tree. Its larger footprint and higher mass also require more conservative reverse distances, speed limits, and obstacle inflation settings than a laboratory-scale platform.

ROS 1 and ROS 2 differences

ROS 1 move_base used a recovery behavior mechanism based on the nav_core::RecoveryBehavior plugin interface. Common examples included clear_costmap_recovery and rotate_recovery. ROS 2 Nav2 uses a different architecture based on lifecycle nodes, ROS 2 actions, plugins, and Behavior Trees.

The conceptual purpose is the same in both systems: detect navigation failure, execute a bounded corrective action, and retry planning or control. Configuration files, plugin APIs, action interfaces, and runtime diagnostics are not directly compatible between ROS 1 and ROS 2.

Normative references and technical sources

The following documents define the primary ROS conventions relevant to recovery behavior and mobile navigation integration:

See also