Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to change parameters such as exposure within the C++ code in ros #1206

Closed
nawara72 opened this issue May 20, 2020 · 10 comments
Closed

How to change parameters such as exposure within the C++ code in ros #1206

nawara72 opened this issue May 20, 2020 · 10 comments
Labels

Comments

@nawara72
Copy link

Hi

I have a D435 and am using "roslaunch realsense2_camera rs_camera.launch" to publish all the topics.

I have listener node which subscribes to the infrared image and displays it.
I process the infrared image and come up with an exposure value that I would like to set the D435 parameter to. I would like to that within my C++ listener code. I couldn't find a way to do that.

I can easily run"rosrun dynamic_reconfigure dynparam set /D435_2/stereo_module exposure 8500" with various exposure values and see the results in the displayed images in the listener, but I don't want to run a command line.

I was able to change the exposure from within the listener code using "system("rosrun dynamic_reconfigure dynparam set /D435_2/stereo_module exposure 100"); but that was extremely slow.

I would appreciate any help to be able to change the exposure values from within my C++ code without effecting the performance. I tried many variations using ddynamic_reconfigure::DDynamicReconfigure ddr ...
but couldn't get it to work. couldn't find a way to set the parameters.

Thanks
Nawar

@MartyG-RealSense
Copy link
Collaborator

MartyG-RealSense commented May 21, 2020

I was able to change the exposure from within the listener code using "system("rosrun dynamic_reconfigure dynparam set /D435_2/stereo_module exposure 100"); but that was extremely slow.

I note that in the quoted example for setting exposure with C++, you are setting stereo exposure to 100, whereas in the earlier example where you set stereo exposure directly with dynamic reconfigure, you set it to 8500 (which is the default stereo exposure value in the RealSense Viewer).

100 seems more typical of the exposure values used in the Viewer for the separate RGB exposure setting, which is 156 by default in the Viewer.

It made me wonder if your C++ code for setting stereo exposure was correct but the 100 value was causing the extremely slow performance.

@nawara72
Copy link
Author

Hi Marty

Thanks for your quick response. It seems the slowness when calling the system call from within my code has nothing to do with the exposure value. It is slow no matter what value I use. I also tried it with other options eg setting stereo_module emitter_enabled
system("rosrun dynamic_reconfigure dynparam set stereo_module emitter_enabled 1"); from within my code, it is also extremely slow. I think the system call is just slowing down everything. Is there any way I can call dynamic_reconfigure directly not as a system call from within my code?

Thanks
Nawar

@MartyG-RealSense
Copy link
Collaborator

I wonder if the listener node is updating the exposure in Dynamic Reconfigure with the same value continuously instead of just writing it once when you change the value. Even the act of continuously updating a value could cause slowdown because it is something that has to be processed.

@nawara72
Copy link
Author

Thanks Marty, I think that's exactly what's happening . I do want to continuously change the exposure, and that is what I am doing, I am changing the exposure for every frame. So I guess what you are saying that the issue is not the system call that's slowing down things but the fact that I am continuously changing the exposure ?
Thanks

@MartyG-RealSense
Copy link
Collaborator

MartyG-RealSense commented May 22, 2020

It may be better to have auto-exposure enabled and let the Vision Processor D4 hardware inside of the camera take care of the calculations involved in exposure changes.

There is also a mode in the SDK for rapidly switching between two values of exposure that only works on D430 / D435, where the laser emitter is very rapidly alternated on / off. The link below has an animated image with a fast-strobing light, so beware if you have epileptic sensitivity. I wonder if that would meet your needs for continuously changing exposure without the processing lag of continuously writing the value with your node script.

IntelRealSense/librealsense#3066

@nawara72
Copy link
Author

Hi Marty

Thanks for your suggestion, but I really want to process every infrared image, come up with a new exposure and then use that for the next frame. So the switching between the 2 values doesn't really help.

I was able to change the exposure from within my listener without using Dynamic Reconfigure . I just used query_devices, then changed the exposure of the desired device for every published frame. However, as you mentioned, I found out that slows down the streaming of the D435. I guess there is not much I can do there.

Thanks for all your help

@MartyG-RealSense
Copy link
Collaborator

You are very welcome. :) I'm pleased that you found a solution. Is it okay to close this case now or do you need further advice? Thanks!

@nawara72
Copy link
Author

Just confirming, is there no way of changing exposure continuously without it effecting the fps quite strongly?

@MartyG-RealSense
Copy link
Collaborator

MartyG-RealSense commented May 28, 2020

If you need to have auto-exposure disabled then you can try to keep FPS constant by using manual exposure values that do not exceed an "upper bound".

IntelRealSense/librealsense#1957

I cannot think of anything else that you could do to increase performance other than offload some of the CPU's processing work onto a computer's graphics GPU.

IntelRealSense/librealsense#4905 (comment)

@nawara72
Copy link
Author

Great thanks for all your help and your prompt help, really appreciate it,, will try out your suggestions :-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants