Parameters reset after disable and re-enable

[PhilipAtLabrador]

We are using:
D435
Firmware 5.12.8.200
https://github.com/IntelRealSense/librealsense/releases/tag/v2.39.0
2ecaf73

We are using the enable/disable function to save power when we don't need data from the D435. One of the issues we are seeing is that after re-enabling some parameters which had been set, no longer are. In particular we see this with the emitter_on_off parameter, and with the auto exposure parameters. This is not ideal for us because it takes time to switch back into emitter_on_off mode and for the exposure to re-settle.

Other settings we are using:
6Hz
Visual preset 3(high accuracy)
emitter_on_off = true
inter_cam_sync_mode = 1

Our questions are:

1. Is it possible to preserve all parameters across disable/re-enable?
2. What parameters are not preserved? We are interested so we can know what we need to re-set

Thanks!

[MartyG-RealSense]

Hi @PhilipAtLabrador The first point that I would make is that if you are using just one camera then you do not need to set inter_cam_sync_mode. This mode is for setting up hardware sync between multiple cameras, and the '1' mode denotes that the camera is the "master" camera in the multi-camera setup whose timestamp timings the other cameras (set to '2', or "slave") try to follow. The master camera that is set to '1' sends out trigger pulses that the slave cameras that are set to '2' listen out for.

Therefore, if there is only one camera then inter_cam_sync_mode can be left on its default value of '0' (no hardware sync).

If the emitter needed to be kept on 'hot standby' for a fast response then you could use dynamic reconfigure during live runtime to set the laser_power value to '1' (to keep the projector ticking over but not shut off) and set to '150' (the default laser power) just before a capture, then return its value to '1' after capture when minimizing power again. Minimizing laser power would hugely reduce the depth image's detail, but if you are not capturing during the power-down phase then this may not matter.

In regard to your questions 1 and 2, @doronhi will be more familiar than myself with emitter_on_off and the recent pull.

[PhilipAtLabrador]

Hi Marty @MartyG-RealSense Thanks for your response. We are indeed using multiple cameras. I just wanted to specify all of the parameters that we are setting on one of the cameras in case this ends up being an interaction of some of the parameters.

Just to make sure it is clear, my question is not about the emitter_on_off feature. It is about the enable service which puts the whole camera into a standby mode that was recently merged into the development branch with this pull request:
#1313

[MartyG-RealSense]

Thank you very much @PhilipAtLabrador for the clarification. It would be good to seek the input of the creator of the pull.

Hi @doisyg Thanks again for creating the pull. :) Would you be able to assist @PhilipAtLabrador with their questions in this case about the pull please? Thanks!

[doisyg]

Hi,
I have to admit that I am a bit confused by all the parameters related to the emitter.
There are emitter_enabled, laser_power, emitter_on_off and emitter_always_on
In our use case (D435), we don't set value for these parameters (so default) and if checking with rqt_reconfigure we have emitter_enabled: Laser (1), laser_power: 150, emitter_on_off: false and emitter_always_on: false. And the emitter works properly even after many cycles of enable/disable.

[MartyG-RealSense]

Thanks very much for your input @doisyg I appreciate it :)

[PhilipAtLabrador]

Thanks indeed! I believe the difference in our scenarios is that we are setting a non-default parameter for emitter_on_off and it is reliably returning to the default value after re-enable. I suspect this is a behavior of the camera firmware. Our questions remain, which parameter return to their default values after disable/re-enable, and can this behavior be changed?

[MartyG-RealSense]

@PhilipAtLabrador On a case today on the main librealsense GitHub about camera settings resetting to defaults after a disconnection, agrunnet the Chief Technical Officer of the RealSense Group at Intel confirmed that a camera goes to default values after a power-down. You mentioned earlier putting the camera in a 'standby' state, so I wondered if this may be what you are experiencing.

IntelRealSense/librealsense#7680

[PhilipAtLabrador]

Thanks @MartyG-RealSense I had been under the impression that @doisyg 's PR was putting the camera into a standby mode where configuration was preserved. I am now understanding that it fully stops the camera and re-enabling brings it up in a default state where it must be re-configured.

[MartyG-RealSense]

Hi @PhilipAtLabrador Do you require further assistance with this case, please? Thanks!

[PhilipAtLabrador]

Hi @MartyG-RealSense,

I see that the the release notes for 2.2.18 say:
"* Add feature: enable/disable all sensors. Known issues: parameters persistency and not full power drop."

We would love to see the parameters be persistent. I'm not sure how you typically handle issue tickets similar to this one. Let me know if you want me to close the issue, or do something else.

[MartyG-RealSense]

Hi @PhilipAtLabrador As developers find it useful to have feedback about the level of demand for a particular feature, I will tag @doronhi the RealSense ROs wrapper developer to highlight your wish for parameter persistency when enabling / disabling sensors. Thanks!

[MartyG-RealSense]

As parameters persistency is listed as a known issue on the 2.2.18 release notes as you said, this suggests that it is on the ROS1 development radar already in terms of awareness of the issue. So I will close this case. Thanks for the great contributions @PhilipAtLabrador

[doisyg]

Adding to this thread that enabling/disabling the camera seems to reset the visual_preset param

[MartyG-RealSense]

Thanks very much @doisyg for your added knowledge!

[doronhi]

@PhilipAtLabrador , Looking at the parameter: enable_auto_exposure, I fail to reproduce the issue. Tried the set of commands:
rosrun dynamic_reconfigure dynparam set /camera/stereo_module enable_auto_exposure 0
rosrun dynamic_reconfigure dynparam get /camera/stereo_module | grep -i -o -P "enable_auto.*? [TF]"
enable_auto_exposure': F
rosservice call /camera/enable false
rosservice call /camera/enable true
rosrun dynamic_reconfigure dynparam get /camera/stereo_module | grep -i -o -P "enable_auto.*? [TF]"
enable_auto_exposure': F
rosrun dynamic_reconfigure dynparam set /camera/stereo_module enable_auto_exposure 1
rosrun dynamic_reconfigure dynparam get /camera/stereo_module | grep -i -o -P "enable_auto.*? [TF]"
enable_auto_exposure': T
rosservice call /camera/enable false
rosservice call /camera/enable true
rosrun dynamic_reconfigure dynparam get /camera/stereo_module | grep -i -o -P "enable_auto.*? [TF]"
enable_auto_exposure': T

(Feel free to improve on my regexp, I gave up on the attempts to print the whole "True" and "False" words...)

Regarding the emitter_on_off - I think I noticed an issue even starting it for the first time in the launch file. It seemed to me that the value is set correctly but the pattern isn't flickering the way it does when the parameter is set interactively. If you can confirm and open another issue I'll be obliged. It could be just something I did wrong here but if that is your case, it means it is not related to the "enable/disable" feature.

@doisyg , same goes with the "visual_preset" parameter - I can't reproduce:
rosrun dynamic_reconfigure dynparam set /camera/stereo_module visual_preset 4
rosrun dynamic_reconfigure dynparam get /camera/stereo_module | grep -i -o -P "visual.*?\d"
visual_preset': 4
visual_preset': 4
rosservice call /camera/enable false
success: True
message: ''
rosservice call /camera/enable true
success: True
message: ''
rosrun dynamic_reconfigure dynparam get /camera/stereo_module | grep -i -o -P "visual.*?\d"
visual_preset': 4
visual_preset': 4

Am I doing something different?
Tested using D435I
ros-melodic on Ubuntu1 18.04
RealSense ROS v2.2.22
Built with LibRealSense v2.42.0

Running with the following command:
roslaunch realsense2_camera rs_camera.launch enable_infra1:=true infra_width:=848 infra_height:=480 infra_fps:=30

[doronhi]

Tested also with parameter "/camera/stereo_module emitter_enabled". Value remains after cycles of disable-enable.

[MartyG-RealSense]

Hi @PhilipAtLabrador and @doisyg Do you require further assistance with this case, please? Thanks!

[PhilipAtLabrador]

@doronhi We also saw that dynamic_reconfigure indicated that the setting was preserved across disable/enable, however the camera was not actually in the mode indicated by dynamic_reconfigure. We have implemented work arounds now to detect that the camera is not in the mode that the driver thinks it is and re-configure it. For example with the emitter_on_off mode, if we receive too many frames in a row without the meta-data indicating that the emitter has changed states, we reset this parameter.

[doronhi]

Thanks, @PhilipAtLabrador. Did you happen to see this phenomenon with any other control besides the emitter_on_off?

[PhilipAtLabrador]

I believe this was also happening with the intercam_sync_mode and visual_preset, but my recollection is less certain about them. intercam_sync_mode, visual_preset, and emitter_on_off are the three non-default parameters we use. We use three workarounds which appear to make them work reliably when using enable/disable.

1. Re-set all non default parameters inside of SetupDevice which is called when the sensor is re-enabled.
2. When emitter_on_off mode is enabled as far as librealsense knows check that not more than N frames are received in a row with either the emitter on or off in order to detect that the camera is actually running in the emitter_on_off mode. Re-set the emitter_on_off mode if it is not behaving correctly.
3. Check that it has not been more than N seconds since a frame was received when the camera is supposed to be enabled. We have seen sometimes that the camera is stuck in a way where it is not producing frames. If it is disable and re-enable the sensor.

All of these issues appear to us to be related to disabling and re-enabling the sensor as we did not see them before we started using this functionality.

[doronhi]

Thanks for all the info. I will try to attend again soon.

[MartyG-RealSense]

Hi @doronhi Does this case about togglng the IR emitter on-off in ROS1 Melodic still need to be open please? Thanks!

[doronhi]

It is dragging and also documented as DSO-16964 but I guess until it is resolved it should remain open.

[MartyG-RealSense]

Thanks very much @doronhi - I have added an Enhancement tag to this case as a reminder to keep it open due to being associated with a DSO.

[doronhi]

The source of this behavior was found to be in the firmware. A fix was introduced (DSO-17396) and I expect it to be released soon.
Will keep this issue open and updated until then.

[PhilipAtLabrador]

Thanks for the update!

…

On Mon, Aug 2, 2021 at 9:09 PM doronhi ***@***.***> wrote: The source of this behavior was found to be in the firmware. A fix was introduced and I expect it to be released soon. Will keep this issue open and updated until then. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1472 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AIQPLLZV7QUB6SH7OHQ5QGTT25TXXANCNFSM4TCVBW6A> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email> .

-- Philip Case 404-210-4923 Senior Robotics Engineer

[MartyG-RealSense]

As a fix for the issue in this case was implemented on 3 August 2021 in DSO-17396, I will close the case. Thanks again @PhilipAtLabrador for your report!