Grab() stalls with area memory, getting worse with speed

Software Python
1

One more finding from the car, separate from the GIL issue.

Setup: ZED X Mini, SDK 5.3.1, SVGA@60, GEN_3, enable_area_memory = True, enable_localization_only = True, a saved .area map of the track (about 54 m loop), enable_imu_fusion = True, depth disabled in RuntimeParameters. Jetson Orin, L4T R36.4.7, jetson_clocks on.

Observation: grab() periodically takes 100–220 ms instead of about 16 ms, and the stalls get more frequent at higher speed:

stalls (grab() > 100 ms) frames dropped
parked, with map about once per second, 110–120 ms about 8%
driving at roughly 75% speed, with map every 0.2–1 s; in the last 1.6 s before LOST: every 0.2–0.3 s, 150–224 ms 48 stalls and about 920 dropped frames in 26 s; about 77 of 95 frames dropped in the 1.6 s before LOST
same speed, enable_area_memory = False, no map 1 stall in about 26 s 62 dropped, startup included

During the stalls the GPU is at 0–7%, and one CPU core goes to 90–95% (tegrastats). Per-thread top with area memory off shows no thread above about 60%. So it looks like CPU-bound map matching running inside grab(). At speed it falls behind, grab() drops most frames, and tracking ends up LOST.

After a reset_positional_tracking() (the call itself takes about 3.1 s; INITIALIZING → KNOWN_MAP then took 0.19 s, so 3.35 s from calling the reset to KNOWN_MAP), grab() stalled about every 0.12 s (about 105 ms each) for the next several seconds.

Questions

  1. With enable_area_memory on and a loaded map, does relocalization / map matching run synchronously inside grab(), or in a background thread that grab() waits on?
  2. Is there a way to limit how often it runs, or how much time it may take per frame, so VIO keeps running at the full frame rate?
  3. Can the VIO pose be read without waiting for map matching? For example, does get_position(…, REFERENCE_FRAME.CAMERA) come from a separate path?
  4. For high-speed use (a small car, several m/s, fast turns), what setup do you recommend for continuous VIO plus map relocalization? Would two SDK instances on a local stream (one VIO-only, one with area memory) be a supported approach, and do IMU data come through the stream?
  5. Is the faster stall pattern right after a reset expected?
  6. The API notes that reset_positional_tracking() “will also flush the accumulated or loaded spatial memory”. With a loaded .area file, does the reset reload the map from area_file_path, and is that why it takes ~3 s? Is there a lighter way to re-seed the pose after LOST without flushing the map?

I can share bags, logs and the tegrastats / top captures if useful.