This is a good guess, but in “2D mode” the data size is the same.
The ZED ROS2 Wrapper forces the 2D mode simply by setting the Z coordinate to a fixed value; the data format is not changed.
That makes sense, Thank you so much for the info!
Hi @Myzhar,
Is there any update/ new findings for this issue? Any updates/workarounds are appreciated. Let me know if more info is needed
Thanks!
Hi @hey_you
We are still working on the code.
Thanks for the update! I will share some new data for debugging over email.
Thanks!
Hi @Myzhar,
I’m hitting persistent Area Memory issues with the latest ZED ROS2 wrapper on an NVIDIA Jetson (L4T 36.4.0 / Ubuntu 22.04 / ROS2 Humble). Running inside Docker, built from the official zed-ros2-wrapper/docker guide.
What’s happening:
-
Save warning:
When Area Memory is enabled with a save path, I get “Failed to save area memory: FILE ERROR” on exit — but a valid.areafile (~60 MB) is still created. For Gen‑3 this can apparently be ignored; does that also apply to Gen‑1 / Gen‑2? -
Segfault on re-runs:
On the second (or later) run with the saved.areafile present, the node crashes after a bit with “Unhandled internal exception (slutils)” and segfault (-11). No issues on the first run or if no.areafile is used.
I used to get solid odometry from the ZED2i, but lately it fails to lock even after adjusting params. My goal is to fuse wheel odom + ZED odom + ZED IMU in an EKF, but right now the ZED odom itself is unstable.
Any suggestions or docs on improving odom fusion or troubleshooting this behavior would be greatly appreciated.
Thanks!