Driver does not support Trigger over Ethernet

[cparedis]

We are working with Mako G-319C cameras and would like to use their trigger over ethernet capability to synchronize multiple cameras. This can supposedly be achieved by using Action Commands. Does anybody have experience using this capability?
It seems like it will require several changes:

• Adding the TriggerMode Action0 and Action1
• Adding parameters for ActiondDeviceKey, ActionGroupKey and ActionGroupMask
• Creating the capability to send the corresponding Action Commands -- this may be best done as a separate ROS node that can trigger any number of cameras.

My students and I are willing to put in the effort to implement this, but before we get started, it would be good to discuss the approach with somebody who is more familiar with the details of the current implementation.

[icolwell-as]

Hi @cparedis, before starting work on this, can you or your students first review and test this PR with your hardware?
#21

I believe it already achieves the desired functionality.

[cparedis]

@icolwell-as, after some further exploration and discussion with folks at Autoware, we have changed our mind on this. It turns out that if the cameras only need to run at a fixed framerate, it is sufficient to synchronize the triggering among them only once. Through PTP, their triggering will remain synchronized from then on forward. For one-time trigger synchronization, there is a more accurate and simpler implementation possible.

We are currently implementing the following:

• An additional topic the cameras subscribe to for synchronization purposes.
• A sync node that will publish this topic and broadcast PtpAcquisitionGateTime to all cameras.
• All cameras that need to be synchronized will listen to this topic and when a new PtpAcquisitionGateTime is received, will momentarily stop the frame acquisition until the until the camera's TimeStampValue reaches PtpAcquisitionGateTime and then all simultaneously start triggering again.

We were able to verify (using a oscilloscope) that this leads to trigger signals that are synchronized within 100 ns and remain synchronized pretty much indefinitely. The actual image acquisition start event varies a bit more due to the jitter caused by the fact that acquisition can only start at the beginning of a new line -- which for the Mako G-319C camera is about every 17 us. Due to slight variations in the clock frequency of different cameras, the image acquisition time tends to drift slightly within this 17 us window. Still for most applications, synchronization within 17 us is likely to be sufficient.

We will submit a PR once the code has been tested.

[icolwell-as]

Thanks @cparedis for the detailed report on your findings! Very useful.

[GarethZhang]

Hi @icolwell-as ,

I want to follow-up a bit with this topic.

Do you know if the proposed method using PtpAcquisitionGateTime to synchronize all cameras is now implemented in the current version?

I can't seem to find any code related to PtpAcquisitionGateTime in the driver.

Thank you!

[icolwell-as]

Hi @GarethZhang, there has not been any PR submitted by @cparedis for the described functionality.

At the moment, there is a trigger node, but this sends ethernet-based action commands to trigger the camera, which is different than the PtpAcquisistionGateTime method.

[GarethZhang]

@icolwell-as Thank you for the update!