An AI-enabled robot should not ask “what can I do next?” until the system has answered a quieter question:

Can the robot trust the state it is about to act on?

That question belongs between perception and authority. It is not enough for the camera node to publish, the LiDAR to spin, the estimator to output a pose, and the planner to return a path. A robot can have all of those things and still be acting on stale localization, overconfident covariance, a half-dead obstacle layer, a drifting transform, or a perception model that is uncertain in exactly the part of the scene that matters.

For Physical AI systems, mobile robots, inspection robots, robot operator copilots, and ROS 2 autonomy stacks, I would make sensor confidence a gate. The gate does not prove the world is safe. It decides whether the current perception and localization evidence is good enough for the requested level of physical authority.

This article builds on the surrounding control stack: sensor-to-actuator timing budgets, debugging sensor fusion drift, degraded modes for AI-enabled robots, command validation for AI robot agents in ROS 2, runtime assurance for Physical AI robots, and robot autonomy release gates.

The Gate In One Sentence

A sensor confidence gate is a deterministic admission-control layer that checks whether perception, localization, maps, transforms, diagnostics, timestamps, and uncertainty are good enough for a specific robot action before autonomy is allowed to plan, continue, accelerate, manipulate, or recover.

The gate should sit before any authority increase:

1
2
3
4
5
6
7
8
9
10
11
12
13

sensors and drivers
  -> perception and state estimation
  -> confidence gate
       - freshness
       - covariance and uncertainty
       - frame validity
       - diagnostic health
       - model confidence
       - costmap and obstacle health
       - operating envelope match
  -> planner / behavior tree / action server
  -> runtime assurance
  -> controller / MCU / actuator boundary

The confidence gate is not a replacement for runtime assurance, emergency stops, watchdogs, or command validation. It has a narrower job: keep bad state from being treated as actionable state.

That distinction matters. Runtime assurance can veto unsafe motion while the robot is already operating. Command validation can reject an AI proposal before it becomes a ROS 2 action. A confidence gate decides whether the robot’s view of the world is fit for the authority being requested.

Confidence Is Not One Number

Robotics teams often compress confidence into a single threshold. That is convenient, but it hides the important failure modes.

Sensor confidence is a vector:

The gate should evaluate these signals separately before it produces one decision. A single “confidence = 0.82” hides whether the robot is uncertain because the camera is occluded, the map is stale, the transform is invalid, or the AI classifier is unsure.

For a physical system, those differences change the safe response.

Authority Should Decide The Threshold

The same sensor state can be acceptable for one action and unacceptable for another.

A robot may be allowed to speak a diagnostic summary with low localization confidence. It may be allowed to rotate slowly in place with degraded obstacle confidence. It may be forbidden to navigate near people unless localization, obstacle data, speed estimate, and safety scanner diagnostics are all healthy.

Tie confidence gates to authority:

This prevents a subtle failure: reusing a confidence score from a low-risk behavior to justify a high-risk one.

The right question is never “is localization confidence above 0.7?” It is “is this evidence sufficient for this motion, at this speed, in this workspace, with this supervision model?”

The Minimum Confidence Contract

For every motion-capable robot, I would start with a written contract like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44

confidence_gate_id: warehouse-amr-base-motion-v1
applies_to:
  action_names:
    - /navigate_to_pose
    - /inspect_area
  authority_level: supervised_autonomous_navigation
required_inputs:
  localization:
    pose_topic: /localization/pose
    max_age_ms: 150
    covariance_xy_max_m2: 0.04
    covariance_yaw_max_rad2: 0.03
    frame: map
  odometry:
    topic: /odom
    max_age_ms: 80
    required_frame_chain: map -> odom -> base_link
  obstacle_layer:
    costmap_topic: /local_costmap/costmap
    max_age_ms: 200
    expected_sources:
      - lidar_front
      - depth_camera_front
  diagnostics:
    required_ok:
      - lidar_front
      - wheel_encoders
      - imu
      - motor_controller
      - safety_scanner
  qos_events:
    block_on_deadline_miss:
      - /scan
      - /odom
      - /localization/pose
decision_policy:
  pass: allow_normal_navigation
  warn: cap_speed_and_require_supervision
  fail: reject_or_downgrade_to_hold
evidence:
  log_decision: true
  include_latest_diagnostics: true
  include_transform_age: true
  include_covariance_snapshot: true

Those values are examples, not defaults. The important thing is the shape of the contract:

• it names the authority it controls,
• it names the required inputs,
• it gives thresholds,
• it maps uncertainty to action,
• and it leaves evidence behind.

Without a contract, the behavior tree, planner, AI agent, and operator interface will each invent their own version of “good enough.”

Freshness Must Be Explicit

Freshness is the easiest confidence signal to under-engineer.

ROS 2 gives teams useful tools here. The ROS 2 design note on deadline, liveliness, and lifespan QoS frames deadline as a maximum interval between messages, liveliness as a way to know whether an entity is still alive, and lifespan as the period during which a message remains valid. Those are not only communication settings. For robots, they are confidence inputs.

A confidence gate should know:

A stale LiDAR scan, stale costmap, stale transform, and stale localization estimate are different failures. They may all produce the same visible symptom: the robot moves as if the world has not changed.

So the gate should log the actual ages it used:

1
2
3
4
5
6
7
8
9
10
11
12

{
  "gate": "base_motion_confidence",
  "decision": "fail",
  "reason": "LOCAL_COSTMAP_STALE",
  "values": {
    "localization_age_ms": 74,
    "odom_age_ms": 21,
    "tf_age_ms": 18,
    "local_costmap_age_ms": 480,
    "max_local_costmap_age_ms": 200
  }
}

This is much more useful than “navigation failed.”

Covariance Needs Policy

Covariance is often treated as estimator plumbing. It should be part of the authority contract.

ROS messages already make uncertainty part of the data model. The sensor_msgs/Imu message documentation, for example, describes covariance fields for orientation, angular velocity, and linear acceleration, and it distinguishes unknown covariance from unavailable estimates. nav_msgs/Odometry carries pose and twist with covariance. That information should not disappear before the autonomy layer makes decisions.

The policy does not need to be complicated:

The anti-pattern is overconfident input. A filter that says “I know exactly where I am” while the robot is on a reflective floor with wheel slip and poor visual texture is not confidence. It is a missing warning.

A good gate can be boring:

1
2
3
4
5
6

If pose covariance exceeds the navigation threshold:
  stop accepting new navigation goals
  allow low-speed hold or relocalization behavior
  publish confidence-gate diagnostic WARN
  record the last healthy and first unhealthy values
  require recovery evidence before returning to normal mode

This connects confidence to behavior instead of letting uncertainty sit unused in a message field.

Diagnostics Are Not Safety, But They Are Evidence

ROS diagnostics are useful, but they are easy to misuse.

REP-107 describes a diagnostic system intended to report robot component status, support quick operator awareness, and preserve historical evidence. It also warns that diagnostics are not a halt mechanism and should not be treated as a tight keepalive.

That distinction is exactly right for confidence gates.

Diagnostics should feed the gate as evidence:

• camera driver warning,
• LiDAR packet loss,
• IMU saturation,
• encoder error count,
• motor controller temperature warning,
• safety scanner state,
• dropped-frame counter,
• clock-sync warning,
• GPU memory pressure,
• perception model health.

But a diagnostic warning should not be the only protection between the robot and unsafe motion. The gate should combine diagnostics with freshness, covariance, frame validity, and task authority.

For example:

Diagnostics help explain the decision. They should not be the only decision.

Costmaps Need Confidence Too

Navigation stacks often treat the costmap as if it were simply “the map.” It is better to treat it as a time-bounded belief about occupied, free, and unknown space.

The Nav2 obstacle layer documentation exposes parameters such as observation sources, expected update rate, observation persistence, marking, clearing, and obstacle ranges. Those settings are confidence policy hiding in configuration. They decide how long obstacle evidence persists, what counts as an observation source, and whether stale or missing data continues to influence planning.

A confidence gate should ask:

• Which sources are required for this behavior?
• Which sources are optional or redundant?
• How old can each source be?
• Is the robot allowed to clear obstacles with this sensor?
• Is unknown space treated as blocked, cautious, or free?
• Does the current speed require a longer perception horizon?
• Was the relevant workspace actually observed recently?

This matters because costmap failures rarely announce themselves politely. A planner can return a valid path through an area that has simply not been observed recently. A depth camera can be blocked by glare while the local planner still has a smooth costmap. A LiDAR can keep publishing while part of the scene is outside its useful field of view.

The gate should be conservative near the edge of observation:

The planner can still optimize paths. The confidence gate decides whether the planner’s input world is trustworthy enough.

Frame Confidence Is A Gate Input

The robot cannot trust a measurement if it cannot trust where that measurement lives.

REP-105 is still one of the most useful documents for mobile robot state: odom is continuous but drifts, map is globally meaningful but can jump, and each frame has a parent in the transform tree. That is not naming trivia. It is authority policy.

The confidence gate should check:

• required frame chain exists,
• transform timestamps are fresh,
• no duplicate authority is publishing the same transform,
• map, odom, and base_link are being used for their intended roles,
• static sensor transforms are loaded,
• localization jumps are handled before motion resumes,
• frame changes across maps, floors, or sites are explicit.

Frame failures are nasty because they can produce plausible values in the wrong place. A camera detection can be correct in camera coordinates and dangerous after a stale transform. A global pose can be valid in map and unsuitable for local control if the map -> odom update just jumped. A planner can be mathematically correct and physically wrong.

Frame confidence therefore belongs in the same gate as perception confidence.

AI Perception Should Not Bypass The Gate

Vision-language models, object detectors, segmentation models, scene classifiers, and learned policies can add useful perception to robots. They also introduce a confidence vocabulary that is easy to over-trust.

An AI model saying “I see a pallet” is not enough. The gate should ask:

For most robots, AI perception should produce evidence for a gate, not override the gate.

A useful pattern is:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

AI perception proposes:
  object_type = pallet
  detection_confidence = 0.91
  bounding_region = camera_frame polygon
  timestamp = t
  supporting_depth = available

confidence gate checks:
  frame transform fresh
  depth geometry plausible
  region intersects planned path
  obstacle layer updated
  robot speed compatible with perception horizon
  diagnostic state OK

The model contributes a signal. It does not grant authority.

Degraded Modes Are The Product Of Confidence Gates

A confidence gate should not only return pass or fail.

Robots need intermediate behavior:

This is where degraded modes become concrete. Instead of “camera bad, robot confused,” the system has a predictable transition:

1
2
3
4
5
6
7
8

front_depth_camera WARN
  + lidar fresh
  + localization healthy
  + low-speed aisle inspection requested
  -> pass_with_constraints
  -> max_speed = 0.2 m/s
  -> no autonomous docking
  -> require operator supervision near unknown space

The confidence gate is not just a safety feature. It is a way to keep the robot useful while being honest about its evidence.

The Evidence Packet

Every confidence decision that blocks, degrades, or grants physical authority should be reconstructable.

At minimum, log:

Example:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

{
  "event_type": "sensor_confidence_gate_decision",
  "gate_id": "warehouse-amr-base-motion-v1",
  "gate_version": "2026-09-11",
  "requested_action": "/navigate_to_pose",
  "authority": "supervised_autonomous_navigation",
  "decision": "pass_with_constraints",
  "reason_codes": ["DEPTH_CAMERA_WARN", "UNKNOWN_SPACE_AHEAD"],
  "constraints": {
    "max_speed_m_s": 0.2,
    "requires_operator_supervision": true,
    "blocked_skills": ["autonomous_docking"]
  },
  "input_age_ms": {
    "localization": 63,
    "odom": 18,
    "tf_map_odom": 22,
    "local_costmap": 141
  },
  "uncertainty": {
    "pose_covariance_xy_m2": 0.018,
    "yaw_covariance_rad2": 0.011
  },
  "diagnostics": {
    "lidar_front": "OK",
    "depth_camera_front": "WARN",
    "imu": "OK",
    "wheel_encoders": "OK"
  }
}

This is the kind of evidence that makes field debugging and release reviews less mystical.

The NIST Performance Assessment Framework for Robotic Systems is useful background because it treats robot performance as composed evidence across perception, mobility, dexterity, and safety. Confidence gates are the runtime version of that mindset: do not collapse a robot’s state into one demo outcome.

Test The Gate Like A Product Surface

The confidence gate needs its own tests. Do not assume it works because perception and planning work separately.

A practical test plan:

The last row is important. Confidence should not instantly bounce back to normal after one good sample. A robot that oscillates between normal and degraded authority can be worse than a robot that simply stops.

Use a stability window:

1
2
3
4
5
6

restore normal navigation only after:
  localization healthy for 2 seconds
  required obstacle sources healthy for 2 seconds
  pose covariance below threshold for 2 seconds
  no relevant QoS deadline event during the window
  runtime assurance monitor available

That turns recovery into an engineered transition instead of a lucky moment.

Where The Gate Belongs

In ROS 2 systems, the confidence gate can live in several places depending on the architecture:

My default would be a supervisor-owned confidence service plus event stream:

1
2
3
4
5
6

confidence supervisor
  subscribes to required state, diagnostics, QoS events, TF age, costmap metadata
  exposes read-only confidence state
  answers admission checks for action goals
  publishes gate decisions and degradation events
  never performs heavy perception inference itself

Keep the gate boring. It should evaluate evidence, not run the autonomy stack.

The Design Rule

The design rule is simple:

Do not let autonomy consume perception as if publication meant truth.

Publication only means data exists. Confidence gating asks whether the data is recent, healthy, geometrically valid, uncertain in a known way, relevant to the action, and sufficient for the authority being requested.

That is the gap many Physical AI systems hit between a good lab demo and a reliable robot. The demo shows that perception can work. The gate decides when perception is trustworthy enough to act.

For a real robot, that difference is not academic. It is the line between an autonomy stack that is merely impressive and one that can degrade, explain itself, recover, and earn more physical authority over time.