-
Notifications
You must be signed in to change notification settings - Fork 41
SoftwareTrigger for 4 cameras (multithreaded) #69
Description
Hey guys,
our current use case requires triggering 4 cameras simultaneously.
Hardware Setup:
- Compute Platform: Nvidia Jetson AGX Xavier
- Cameras: 4x Alvium USB Camera
- USB Hub to connect cameras to Jetson: link
Software Setup:
We are currently using the vimba python api. Our code is similar to your multithreading example. The multithreading example itself works perfectly fine. However, we do not want to continuously queue the frames, but only when the software trigger (cam.SoftwareTrigger.run()
) is executed. Each camera runs in its own thread. The main thread is managing an event based on which the software trigger in each camera thread is supposed to be executed.
Problem:
Once the event is fired by the main thread (in the dummy test case with a frequenzy of 1 fps), it is also recognized by the threads waiting for the event. The code snipped of the camera threads waiting for the event looks like this:
if self.recordswitch.wait():
self.cam.TriggerSoftware.run()
As I said, the event is recognized and the code block is entered (in each camera thread). However, the frame handler is always just executed by two cameras (the other ones are just ignored). The frame handler is exactly the same as in your multithreading example (I only added two logging statements) and looks like this:
def __call__(self, cam: Camera, frame: Frame):
# This method is executed within VimbaC context. All incoming frames
# are reused for later frame acquisition. If a frame shall be queued, the
# frame must be copied and the copy must be sent, otherwise the acquired
# frame will be overridden as soon as the frame is reused.
if frame.get_status() == FrameStatus.Complete:
if not self.frame_queue.full():
self.log.info(f"{self.name}: Pushing image to queue.")
frame_cpy = copy.deepcopy(frame)
try_put_frame(self.frame_queue, cam, frame_cpy)
else:
self.log.info(f"{self.name}: Queue full.")
cam.queue_frame(frame)
Even if I comment out all of the logic in the frame handler callback, it still only executes for two cameras. Do you have any idea what causes this behavior and how to solve it? Would you recommend a different implementation?
I also tried an implementation where the cameras are not triggered simultatneously but in series with a delay of 1 sec between each camera to ensure that it is not the throughput for the USB hub which is the bottleneck. However, still only two camera threads are executing the frame handler callback.
I already thought that maybe the connection via the USB hub might not work with the software trigger, however this is only a gut feeling and I still do not know how to verify this.
Best,
Lukas