[Humble] Acquisition and Trigger

[li-dahua]

#How can I adjust these parameters in sync launch code? Thank you

There are three acquisition modes:

Continuous - acquires images continuously. This is the default mode.

Multi Frame - acquires a specified number of images before stopping acquisition.

Single Frame - acquires 1 image before stopping acquisition.

System details

• operating system/version: ubuntu 22.04
• ROS version[Humble]): Humble
• complete FLIR camera model (e.g. BFS-U3-04S2C-C):BFS usb

[berndpfrommer]

Changing the acquisition mode is not directly supported for the blackfly S cameras. However, you can implement it easily yourself by modifying the blackfly_s.yaml configuration file. Follow the instructions in the README on how to add your own ros parameters, e.g. call it "acquistion_mode". Then you should be able to specify it at launch time by setting your newly created ROS parameter.
The other alternative is defining a user set with SpinView, and then loading that parameter set in your launch file by setting the correct ROS parameters.
I personally would choose the first option.

[berndpfrommer]

Is this still an issue? If not I would proceed to close the issue.

[jeskesen]

Hi @berndpfrommer , I think there is one problem not addressed in the proposed solution: once one gets into Single/Multi Frame acquisition mode, how does one trigger (in software) repeated calls to a single or multi-frame acquisition? I'm a fan of leveraging LifecycleNode states for this purpose: where activate() calls startCamera(), etc.

[berndpfrommer]

Wouldn't that be very heavy weight, just to trigger a frame acquisition? I would gravitate to a topics-based solution, e.g. the server exposes a topic with a suitable message type that then calls the software trigger.
It turns out that at the moment there is indeed a solution, albeit a fairly heavy weight one, too: you can define a "command", like for instance in the oryx.yaml file:

  - name: trigger_software
    type: command
    node: AcquisitionControl/TriggerSoftware

IRRC a parameter update then runs the command, in this case a software trigger.
Pretty it ain't, but it should work.
Oh, and it's not documented. Will fix that.

[berndpfrommer]

See discussion here #163

[jeskesen]

Wouldn't that be very heavy weight, just to trigger a frame acquisition?

Absolutely. I fully admit that I have a preference for all hardware-facing nodes to be Lifecycle Nodes so that I can control their states throughout the application lifetime in a way that is consistent across my entire system. Apologies for the scope creep.

That said, I'm still having problems even getting the camera to behave like its in any other AcquisitionMode other than "Continuous" despite the fact that I does seem to accept the Single/MultiFrame parameter mode. I'm puzzled.

[berndpfrommer]

Please open a separate issue for that, and post the console log.