observability.md

Observability

This document explains where to inspect contract enforcement during replay.

The public wrapper exposes its behavior through:

• console logs
• a stable status summary on /dense_mapping_tsdf/status_text

Console Logs

During replay, the wrapper prints event-level messages such as:

• pose stream connected
• cloud stream connected
• rejected cloud due to missing pose
• rejected cloud due to excessive skew
• accepted cloud forwarded to the backend

These logs are most useful during the first short admissibility test.

Status Topic

Inspect the public status topic with:

ros2 topic echo /dense_mapping_tsdf/status_text

A typical line looks like:

wrapper_status | poses=2850 clouds=283 accepted=281 rejected_missing_pose=2 rejected_pose_skew=0 mean_skew=0.0069 max_skew=0.0282 ...

Common fields include:

• poses
• clouds
• accepted
• rejected_missing_pose
• rejected_pose_skew
• pose_buffer
• relayed_maps
• mean_skew
• max_skew

How To Read It

Healthy replay

Typical pattern:

• poses increases
• clouds increases
• accepted increases
• rejected_missing_pose stays near zero after startup
• rejected_pose_skew stays near zero

Missing-pose problem

Typical pattern:

• clouds increases
• accepted stays near zero
• rejected_missing_pose keeps increasing

Timing problem

Typical pattern:

• poses increases
• clouds increases
• rejected_pose_skew keeps increasing
• accepted remains low

Wrong frame/profile choice

Typical pattern:

• accepted grows
• rejection counters remain low
• the map still looks structurally wrong

This usually points to wrong frame interpretation, wrong backend_pose_mode, or a missing/incorrect extrinsic.