Hi everyone,
We are currently working with a ZED Box Mini equipped with a Jetson Orin NX (16GB) and a ZED X camera, and we are encountering a couple of issues regarding the object tracking and detection module:
-
Persistence issue: The detection bounding box persists even after the tracked item is no longer visible to the camera.
-
Class switching delay/error: When a new or different item enters the scene, the system sometimes struggles to update the detected class. For example, if it was previously detecting a person and a dog enters, the bounding box for the dog is sometimes still labeled as a “person” while retaining the same tracking ID.
Are there specific parameters or configuration settings we can adjust to resolve or mitigate these behaviors?
Thank you very much in advance for your help!
Hi Oscar,
Both are expected tracker behaviour and tunable.
1. Persisting box. When detection is lost, the SDK predicts the trajectory for prediction_timeout_s (default 0.2 s) and the object still reports OBJECT_TRACKING_STATE::OK; after that it goes to SEARCHING, then TERMINATE. Note retrieveObjects()returns those states too — our samples only render tracking_state == OK. If you draw everything in object_list, dying tracks stay on screen. That’s usually the cause. You can also set prediction_timeout_s = 0 to disable prediction, and check objects.is_new (async mode returns the last completed detection).
2. Class switching. filtering_mode defaults to NMS3D, which suppresses detections at the same 3D position as an already-tracked object independent of class. So the dog’s ANIMAL detection is dropped and the PERSON track keeps its ID and label. Switch to NMS3D_PER_CLASS.
Also: SDK 5.2 added per-class ObjectTrackingParameters and fixed random ID swaps — worth upgrading if you’re on an earlier release.
Could you confirm your SDK version, JetPack/L4T, whether you use the built-in model or a custom detector, and your current filtering_mode? A short SVO of both cases would let us reproduce directly.
Best regards,
Tristan