[Humble] ROS2 service call for DeviceReset

[Likhith-Sugganahalli]

Hi,

Thanks a lot for your work on this project.

I am using a blackfly_s and have been encountering an issue with the FPS suddenly dropping to ~2 on a start, out of the blue, while it is generally ~16. Whenever this issue happens, it also reflects in the SpinView application and the only solution i have found is to unplug the camera and plug it back in.

Hence, i wanted to check if i can reset the camera from code itself, i see that the spinnaker API lists DeviceReset, but i am unable to find it being used in this project, is there any other way i can accomplish this?

Thanks

[berndpfrommer]

I added a service call to the driver to call the DeviceReset, but it's obviously not that easy:

[camera_driver_node-1] [INFO] [1738243628.610429859] [20435008]: rate [Hz] in  40.00 out   0.00 drop   0%
[camera_driver_node-1] WARNING: acquisition timeout, restarting!
[camera_driver_node-1] terminate called after throwing an instance of 'Spinnaker::Exception'
[camera_driver_node-1]   what():  Spinnaker: Camera is disconnected [-1014]
[ERROR] [camera_driver_node-1]: process has died [pid 59396, exit code -6, cmd 

Rebooting the camerat while keeping the driver running is tedious to develop, and in the end it's a band-aid to work around an issue without understanding the root cause of it.
Can you say more about your configuration (what camera model)? There is a reason why I added the issue template...

[Likhith-Sugganahalli]

@berndpfrommer

Heyya, sorry for not using the template, adding the information here.

Is this behavior also observed when using SpinVIew?
The bug where out of the blue the driver starts with low FPS is also observed when i run the SpinView (after having observed the issue with the ros2 driver). When i execute the DeviceReset from the SpinView, it starts running at the correct FPS, also works when i unplug the usb cable and put it back in.

Describe the feature
A service call that executes the DeviceReset as seen in the SpinView

Useful logging output
Do not have any useful logs for this

System details

• operating system/version: Ubuntu 22.04
• ROS version (please prepend to issue title in square brackets, e.g. [noetic]): humble running the humble-devel branch
• complete FLIR camera model (e.g. BFS-U3-04S2C-C): BFS-U3-200S6M

[berndpfrommer]

Can you check out PR #227 ? It does reboot the camera. For me however that changes the frame rate because apparently some settings are not defaulted.

But back to your problem. I see you have a very high resolution camera. Check the quality of your USB3 cable, and for errors via journalctl -f

Is the camera externally triggered or free running? Is auto exposure switched on? If the exposure time is longer than 1 / fps the frame rate will drop, so beware of that. Disable auto exp and see if that fixes the problem.

[Likhith-Sugganahalli]

@berndpfrommer I will try out the PR, thanks for that.

I do have a good quality usb3 cable, i was able to verify using syslogs that the usb connection was for super high speed or something of that sort.

The camera is free running, exposure time is set much lower than 1/fps.

[berndpfrommer]

You should see errors somewhere if the USB cable is bad. I only use FLIR cables b/c the cheap cables did not work for me.

I don't ever recall a case where a FLIR camera would spontaneously change frame rate, except for exposure time related issue. Could the camera be overheating? Do you see the same drop in frame rate when you run on SpinView for a while?

[Likhith-Sugganahalli]

@berndpfrommer
Yeah, this issue has stumped flir support as well, there is no error of any sort, in the ros2 driver log, it says that it's starting with fps of 19, but when the acquisition logs start printing, it's 2 fps instead.

I am using flir cable as well,no overheating as well

I do see the same issue with SpinView, but then, the application loads the ros2 driver and when there's this fps drop, I check again with SpinView, so I can't say if this drop wouldn't happen if I only ran SpinView.

Also, this issue doesn't seem to be related to how long I run the system, I haven't been able to spot any pattern to when the issue pops up.

Do you know where the SpinView saves exhaustive logs on Ubuntu? I found some logs in .config folder, but they seem to be useless, maybe if I catch this issue in SpinView and check the logs, it might shed some light on it.

Thanks a lot for your help, really appreciate it!

[berndpfrommer]

Hmm. You have a second camera to play with? Usually FLIR cameras are very reliable, but this could be a bad apple.

Does the drop only happen on ROS2 driver startup, never while the driver has been running a while? Then it could be a race condition when the parameter setting is passed to the camera. Not sure exactly how that would be able to screw up the camera to the point that you need to power cycle, but that would be my hunch then. I remember when developing the ROS2 driver's user setting load feature that I screwed cameras up badly, to the point they needed power cycle and firmware reflash. Are you loading back user settings by any chance?

I didn't even know about the SpinView logs. I already moved on to Ubuntu 24.04 (noble), so I haven't been running SpinView lately.

[Likhith-Sugganahalli]

@berndpfrommer

Heyya,

I do not have a second camera to play with, i will see if i can try something out there.

the drop only happens at startup, never while the driver has been running a while. I am not loading user settings, i am explicitly setting each parameter, i will check if maybe the order in which I am setting them makes it more likely that this happens once in a while.

I will test out the DeviceReset service call and update on this thread shortly.

[berndpfrommer]

If this fps drop always happens at startup, then almost certainly it has to do with the ROS2 driver somehow setting one parameter wrong, or the SDK having a bug that screws up the parameter in the camera memory.
I don't think resetting the device from the ROS2 driver is a good idea. What I implemented so far does not re-apply the parameters so the camera will come up in a different state than before the reset, and you'll have to set the parameters again manually. I don't want to add more complexity to the driver to work around this issue.
Do your camera parameters stay the same? Then try the "user settings" feature of the camera: in SpinView, set up the parameters to your liking, then save them as a user setting. With the ROS2 driver, don't set any parameters but load the user settings (there is a parameter for that, see the driver_node.launch.py file.
OOPS: Just saw that the default launch file loads user set 0. Do you have that enabled? That could cause a race condition and possibly mess up the camera. If you have that enabled, please try first removing the loading of the user set.