ZED SDK 5.3 pose_confidence behavior inconsistent between sl::camera and sl::fusion

Software C++
, ,
1

Hi,

I’m testing sl::Pose::pose_confidence on a ZED X Mini using SDK 5.3 on Jetson Orin NX, and I’m seeing behavior that seems inconsistent with the documentation / expected tracking quality reporting.

Setup: ZED X Mini on a Jetson Orin NX running SDK 5.3 with positional tracking enabled.

What I’m observing in a single-camera Camera::getPosition() test:

  • pose.pose_confidence stays locked at 100
  • POSITIONAL_TRACKING_STATE remains OK
  • timestamps continue updating normally

However, this occurs even when the camera is fully covered and moved around in space.

At the same time, the SDK prints internal warnings such as:

[ZED][WARNING] Degraded or noisy image(s) detected on X keyframe(s) in the last tracking interval. These keyframes will be removed from the map to maintain tracking quality.

So internally, the SDK seems to detect degraded image/tracking quality, but pose.pose_confidence still remains at 100.

I’m also seeing a related behavior when using Fusion. If I call fusion.getPosition() and inspect the returned pose confidence, the confidence value does not appear to update at all and remains at 0.

So I’m seeing two different behaviors:

  • Camera::getPosition() returns confidence fixed at 100
  • Fusion::getPosition() returns confidence fixed at 0

Questions:

  1. Is pose.pose_confidence expected to remain fixed at 100 in GEN3 positional tracking?
  2. Is pose.pose_confidence populated/meaningful when using Fusion::getPosition()?
  3. Is this field currently recommended for runtime tracking-quality validation or failure detection?
  4. Is there another recommended metric/API for detecting degraded visual tracking quality in real time?
  5. Is confidence only updated under certain tracking-state transitions or tracking modes?

Right now, it seems difficult to use pose.pose_confidence as a sanity metric, since it does not appear to reflect degraded visual conditions in the direct camera case, and does not appear to be populated in the Fusion case.

Thanks.