Area Memory ROS2

Upon further debugging with GDB, I think it’s caused by some race conditions that are triggered in the SDK because of the set pose service and its not just on the Jetson devices I could recreate that problem on my x86 based laptop too

Hi @Myzhar, I am aware that it has not been long enough since I reported this problem, but because of this unexpected hurdle, it has brought our progress on a deliverable due next week to a standstill. Any updates, ETAs for fixes, or workarounds would be helpful, and I’d appreciate them a lot.

Thanks!

Hi @hey_you
We are on this. I’ll send you feedback as soon as possible.

@hey_you can you please share the configuration file that you are using?
I mostly need information concerning the configuration of the Positional Tracking module.
It appears to be a bug in the ZED SDK when the Positional Tracking is reset to set a new position of the camera, and we must try to write a native C++ application to try to replicate and debug it internally.

Hi,
Thank you so much for looking into it. I have attached all the relevant config files. Please let me know if more info is needed.
All your help is appreciated.
Thanks!

common_stereo.yaml (18.2 KB)
zed2i.yaml (692 Bytes)
aruco_loc.yaml (1.7 KB)

Hi @hey_you
We are still trying to replicate the issue with no success. Each Positional Tracking call still works as expected.

We do not use OpenCV in the ZED ROS2 Wrapper.
We use it only in a few examples/tutorials in the ZED ROS2 Examples repository.

This seems to be a piece of important information:

Hi,
Thanks for looking into it. Yesterday I completed the setup of Jetson orin NX from scratch and the same issue was visible there was well. Right now I have 3 devices exhibiting the same behaviour for set_pose service. If you don’t mind can you please share the steps you used, to recreate this bug so that I can understand better if there’s something missing? In the meantime I’ll paste the GDB stack trace if that’s helpful and any other piece of information that you need.

Thanks!

This is one of the tests that I performed. It performs 100 Positional Tracking resets for each available mode.

test_pos_trk_reset.zip (4.5 KB)

Can you please try it?

Hi,
Thank you so much for sharing. I tried it on my Jetson device, and it is working as expected. To keep the testing criteria similar and maximize the chance of reproducing the bug, can you please try it with the Aruco example, or run the

ros2 service call /zed/zed_node/set_pose zed_msgs/srv/SetPose '{pos: [0.0, 0.0, 0.0], orient: [0.0, 0.0, 0.0]}'
requester: making request: zed_msgs.srv.SetPose_Request(pos=array([0., 0., 0.], dtype=float32), orient=array([0., 0., 0.], dtype=float32))

Command repeatedly for multiple runs?

I have found 2 instances where people faced similar bugs like here. It is not helpful to solve the bug, but it points out that maybe it has something to do with how the ROS2 app interacts with the SDK. I’m not sure, I’m just sharing some guesses.

I will share the stacktrace in the next few minutes

thanks!

Hi @hey_you
I used the set_pose service to try to replicate the issue too, with no success.
How fast are you calling it? I tried to call it just after receiving a reply.

Yes, you are not the only one affected by this issue, but I think you are the only one who provided good information to fix it.

Hi,
I call it as soon as the previous one returns success. Below, I have attached the stacktrace for the run I did a few minutes back
stack_trace.txt (2.1 MB)
Is it possible to coordinate a time for a small 15-minute video call if that is helpful?

@hey_you I’ve just pushed a new ZED ROS2 Wrapper branch with an improvement and a possible workaround to the ZED SDK race condition.

Can you please test it and send feedback?

We can eventually schedule a meeting in the next few days if required.
You can write to support@stereolabs.com to discuss it.

perfect! Thank you so much for the quick update. I will test and post my results, and if it’s still an issue, I will write to support to schedule a call.

Thanks!

1 Like

A note: I forgot to say the FILE ERROR message can be ignored when using the GEN_3 mode.
It’s a false error message; the area memory file is correctly saved.
It will be fixed with v5.0.4.

Hi,
Thank you so much for the info! I have tested the new patch, and unfortunately, the application is still crashing.
I have attached the new stack trace as well.

Thanks!
stack_race_2.txt (492.7 KB)

1 Like

Thank you, the team is analyzing all the information that you provided and they’re working on a fix.

I appreciate it. For the time being, until we find a fix, I am planning to test out the “world” frame logic purely based on the area file. Is there a way in ROS2 to get the status of tracking, like “searching”, etc., since the status topic always publishes 0 0 0 for me

Thanks!

Yes, you can monitor the status with diagnostics and by subscribing to the topic /zed/zed_node/pose/status of type PosTrackStatus: zed-ros2-interfaces/msg/PosTrackStatus.msg at master · stereolabs/zed-ros2-interfaces · GitHub

1 Like

Thank you so much for the info!

1 Like

Hi,
I just had a thought, could this bug be caused because I am using 2D mode for position tracking but the aruco is resetting the pose to be 3D? I am sure internally it must be suprrssing the Z-axis but could it be because of the Data structure size mismatch?
Thanks