Display Rviz Nodes Crash when Depth Quality is 4: Neural and scene is too bright on startup
Closed this issue · 16 comments
Preliminary Checks
- This issue is not a duplicate. Before opening a new issue, please search existing issues.
- This issue is not a question, feature request, or anything other than a bug report directly related to this project.
Description
'Whenever I run the display rviz pkg using the zed 2i launch file while the sensor is outside in high brightness and running depth quality level 4: Neural, the node will crash; however, the work around has been to cover the camera on startup to reduce brightness when the node is starting up and this consistently works. So what could be happening computationally that could cause this? We are running a server mobo with a Nvidia Quadro RTX 6000 gpu.'
Steps to Reproduce
- Run roslaunch zed_display_rviz display_zed2i.launch
- Run using with common.yaml depth quality set to 4
- Run while out in sunlight with a high amount of brightness
Expected Result
Node not crashing.
Actual Result
Node crashed.
ZED Camera model
ZED2i
Environment
OS: Ubuntu 20.04.6 LTS 64 bit
CPU: Intel® Xeon(R) Silver 4108 CPU @ 1.80GHz × 32
GPU: NVIDIA Corporation TU102GL [Quadro RTX 6000/8000] (Quadro RTX 6000)
Memory: 62.6 GiB
ZED SDK: ZED_SDK_Ubuntu20_cuda12.1_v4.0.5
ROS Noetic
Anything else?
No response
Hi @gschelske
is the NEURAL depth AI model optimized? I suggest you optimize it once before using it for the first time:
$ ZED_Diagnostic -nrlo
Is ZED_Depth_Viewer correctly working?
Hi @Myzhar Only output I get is above for the optimization. When I install the sdk, I usually run the optimization too. But tbh the install on this computer I may not have initially.
And Depth Viewer is working. Everything seems to come up in rviz
This issue is stale because it has been open 30 days with no activity. Remove stale label or comment otherwise it will be automatically closed in 5 days
@Myzhar has there been any resolution to this issue or any others experiencing it?
This issue is stale because it has been open 30 days with no activity. Remove stale label or comment otherwise it will be automatically closed in 5 days
Any updates with this issue?
@gschelske we tested your problem with the latest ZED SDK and could not replicate your issue.
Can you please verify if what you describe happens also outside ROS, by using for example the ZED Depth Viewer tool?
If the problem is present also with it please write an email to support@sterelabs.com to discuss it with the ZED SDK team.
@Myzhar I'm not remembering if it was, so will have to check again when I get the chance. Will follow up to that email provided after I check
@Myzhar, it doesn't seem to crash with the depth viewer tool or the explorer tool. So I guess it's something going on with ros. Maybe a dependency? I'll send an email too
Can you try to record an SVO that replicates this behavior? Otherwise it's impossible to debug it
Will do. I'll pass it off to that email
@Myzhar is there a way to record an svo when running ROS? I only see that I’m able with one of the stereolab executables
GitHub issues are not the right place to ask for questions. Furthermore off topic in a closed issue.
Please use the Stereolabs community forum to ask for questions and use Github only to submit bug reports or feature requests.
In any case to start SVO recording you can use the start_svo_recording
servic3
@Myzhar My apologies, I saw your questions earlier so started asking questions myself. I'll keep that in mind. Also, I thought recording this svo was related to troubleshooting this bug, but I'll keep those comments out of this thread. And the issue is closed because it went stale. There wasn't much activity on this for months and I think it went stale when I was out. I'm not really understanding how this rosservice will be running if the node keeps crashing on startup.
I apologize @gschelske I did not see the history of the issue. I did not remember that I replied a few days ago and I thought the question was off topic.
Yes, please use ZED Explorer or one of the ZED SDK examples to record the SVO.
Then use the same SVO with the ZED Wrapper to understand if it causes the crash