Fixing ZED ROS2 Wrapper Crash After Resetting Tracking / Odometry

1. Problem Overview

When using the ZED ROS2 Wrapper with positional tracking enabled, everything works normally at first.
However, after running:

ros2 service call /zed/zed_node/reset_odometry std_srvs/srv/Trigger {}
ros2 service call /zed/zed_node/reset_tracking std_srvs/srv/Trigger {}

RViz starts throwing TF-related errors on the next launch, such as:

Frame [map] does not exist
No transform from [zed_camera_link] to [map]
Multiple class_loader crash logs in terminal

At the same time, the ZED node fails to publish the full TF tree.

2. Root Cause

The ZED SDK uses Area Files (.area) to store persistent visual maps for positional tracking.
These files allow the camera to:

Restore tracking state after restart
Maintain a consistent map coordinate frame across sessions

When you call reset_odometry or reset_tracking, the SDK often invalidates or deletes the current .area file.
On the next startup:

The wrapper tries to load the .area file (default behavior)
The file is missing or corrupted
ZED SDK throws "Invalid Area File" error
Positional tracking initialization fails
/map frame is never published → RViz shows missing TF frames
Downstream nodes relying on tracking crash or hang (causing class_loader errors)

3. Emergency Fix

The quickest fix is to disable area file usage entirely in the ZED configuration file.
This forces the SDK to always start tracking fresh, avoiding corrupted .area load attempts.

File modified:
<ros2_ws>/install/zed_wrapper/share/zed_wrapper/config/zed2.yaml

Changes made:

pos_tracking:
  pos_tracking_enabled: true
  publish_tf: true
  publish_map_tf: true
  map_frame: 'map'
  odom_frame: 'odom'
  base_frame: 'base_link'
  imu_frame: 'imu_link'

  area_memory_db_path: ""   # Do not load any area file
  load_area_file: false     # Disable loading
  save_area_file: false     # Disable saving
  area_memory: false        # Disable internal map memory

This disables:

Loading any .area file at startup
Saving new .area files during runtime
Internal map memory for persistent tracking

4. Result After Fix

✅ No more Invalid Area File errors
✅ RViz receives TF frames normally
✅ class_loader crash logs disappear
⚠ Every new launch starts tracking from a fresh /map frame (no persistence between runs)

5. Impact of This Change

Pros

Stable startup even after calling reset_odometry / reset_tracking
No crashes due to broken .area files
Simpler operation for one-time runs or short experiments

Cons

Tracking does not persist between runs
Each launch creates a new /map origin
Not suitable if you need a fixed world reference across multiple sessions

6. Recommendation

If you need persistent mapping: Re-enable area_memory and load_area_file after regenerating a valid .area file using ZED Explorer or a clean SLAM run.
If you only run short-term sessions: Keep this fix — it is simpler and more robust.

Last updated: 2025-08-14
Tested on: ROS 2 Humble + ZED ROS2 Wrapper + ZED2 Camera

1. Problem Overview​

2. Root Cause​

3. Emergency Fix​

4. Result After Fix​

5. Impact of This Change​

Pros​

Cons​

6. Recommendation​