Trying to configurate the stream buffer handling mode

[Cyraneon]

Good day to you.

As written in the title, I am trying to configurate the Stream Buffer Handling Mode to "newest only". This Node can be found in SpinView in the following submenus of Feature : Stream Parameters/Buffer Handling Control/Stream Buffer Handling Node.

I am trying to access to this Node by adding to the standard yaml configuration file the following lines :

  - name: buffer_handling_control
    type: enum
    node: BufferHandlingControl/StreamBufferHandlingMode

And by modifying the launch file by adding the following line in the parameters :

'buffer_handling_control': 'Newest Only',

Yet when launching the node, I obtain the following error :

[camera_driver_node-1] [INFO] [1720183684.466130590] [23574899]: setting StreamParameters/BufferHandlingControl/StreamBufferHandlingMode to: Newest Only
[camera_driver_node-1] [WARN] [1720183684.466213600] [23574899]: setting StreamParameters/BufferHandlingControl/StreamBufferHandlingMode failed: node StreamParameters/BufferHandlingControl/StreamBufferHandlingMode not found!
[camera_driver_node-1] [WARN] [1720183684.466229056] [23574899]: StreamParameters/BufferHandlingControl/StreamBufferHandlingMode set to: UNKNOWN instead of: Newest Only

It seems I failed to access to the Node I want to configure. So I tried to set dump_node_map to True in my launch file, to check the name of this Node, and I was unable to find it.

My question is thus the following : is there a way to configure the Stream Parameters Nodes ? And if it exist, how does it work?

Thanks in advance for your feeback !

System details

• Ubuntu/20.04:
• ROS2 humble
• Blackflys3-19S4

[berndpfrommer]

A) Do you see the node in SpinView? [stupid question, you wrote that you see the node, never mind] B) If yes, you can double-click on the node and get its name as described here?

[berndpfrommer]

I was able to reproduce the issue on my Blackfly GigE camera. It turns out the nodes you can control are only the ones that show up under the camera itself in SpinView, e.g. under Blackfly xxx. The SDK does not show the Transport Layer or the Stream Parameters in the root node.

[Cyraneon]

Thanks for the quick response !

I have little to no experience with the capabilities of the SDK, but I have been using the Python wrapper for some tests. I know that in Python, the library PySpin can set this parameter with the following code :

def init_blackfly():
    # Retrieve singleton reference to system object
    system = PySpin.System.GetInstance()
    # Retrieve list of cameras from the system
    cam_list = system.GetCameras()
    num_cameras = cam_list.GetSize()
    print('Number of cameras detected: %d' % num_cameras)

    # If there is multiple or no camera; we stop the test
    if not (num_cameras == 1):
        # Clear camera list before releasing system
        cam_list.Clear()
        # Release system instance
        system.ReleaseInstance()
        print('Not enough cameras!')
        return None, None, None, None

    cam=cam_list[0]

    try:
        # Retrieve TL device nodemap and print device information
        nodemap_tldevice = cam.GetTLDeviceNodeMap()
        print_device_info(nodemap_tldevice)
        # Initialize camera
        cam.Init()
        # Retrieve GenICam nodemap
        nodemap = cam.GetNodeMap()
        # Retrieve Stream Parameters device nodemap
        s_node_map = cam.GetTLStreamNodeMap()
        ############################################################################################
        #Buffer handling
        # Retrieve Buffer Handling Mode Information
        handling_mode = PySpin.CEnumerationPtr(s_node_map.GetNode('StreamBufferHandlingMode'))
        if not PySpin.IsReadable(handling_mode) or not PySpin.IsWritable(handling_mode):
            print('Unable to set Buffer Handling mode (node retrieval). Aborting...\n')
            return None, None, None, None

        handling_mode_entry = PySpin.CEnumEntryPtr(handling_mode.GetCurrentEntry())
        if not PySpin.IsReadable(handling_mode_entry):
            print('Unable to set Buffer Handling mode (Entry retrieval). Aborting...\n')
            return None, None, None, None

        # Display Buffer Info
        print('\nDefault Buffer Handling Mode: %s' % handling_mode_entry.GetDisplayName())
        handling_mode_entry = handling_mode.GetEntryByName('NewestOnly')
        handling_mode.SetIntValue(handling_mode_entry.GetValue())
        print('\n\nBuffer Handling Mode has been set to %s' % handling_mode_entry.GetDisplayName())

IN the code above these two lines show that the SDK is able to access to the needed node :

        # Retrieve Stream Parameters device nodemap
        s_node_map = cam.GetTLStreamNodeMap()
        ############################################################################################
        #Buffer handling
        # Retrieve Buffer Handling Mode Information
        handling_mode = PySpin.CEnumerationPtr(s_node_map.GetNode('StreamBufferHandlingMode'))
        if not PySpin.IsReadable(handling_mode) or not PySpin.IsWritable(handling_mode):
            print('Unable to set Buffer Handling mode (node retrieval). Aborting...\n')
            return None, None, None, None

Yet I am not sure of how to implement the behavior of these lines above in the ros-drivers of this repository

[berndpfrommer]

Yes, the parameters are accessible from the SDK, but work very differently from the camera parameters. I can implement it but it will take me a couple of days to do.

[berndpfrommer]

Never mind, it was a quick fix. Please check out the stream_transport_layer branch from this PR:

https://github.com/ros-drivers/flir_camera_driver/pull/193

It found the nodes for my blackfly GigE cameras, but I could not confirm if setting the parameter makes any difference.

[berndpfrommer]

oops, merged into humble-devel already....

[Cyraneon]

I pulled the changes you made on the humble-devel branch and can confirm that the camera is now behaving as intended. I am streaming the images coming from a BlackflyS3 19S4 and can see that there is now little to no delay between the capture of an image and its display on my screen.

For a s far as I am concerned, this issue has been properly fixed in a timely manner.

Thanks for your help and quick reaction !