Implement Precision Time Protocol and Synchronous Free Run options #1
Conversation
- PTP and sync free run can be enabled at startup via ros parameters. They are set up within the gige camera's applyCamSpecificStartupSettings. Controls are not exposed for for further usage like many of the other camera controls though. - PTP startup will block until sufficient clock synchronization is reached, though the detection is not perfect. - Sync free run requires continuous acquisition mode, which does not play nicely with the rest of the code that uses software triggering. To accommodate the 2 acquisition modes, we also switch between 2 grab strategies. - Also some general bugfixes, e.g. always setting bandwidth parameters and device_user_id_
|
@jonbinney @bhomberg Here's changes to the official basler library to implement PTP and synchronous free run. Their camera interaction model is very different from what we're using (they do software-triggered capture and an emphasis on camera control via services). I first added PTP/syncing via those same lines, but it was incredibly messy. So this code just sets up what we need on startup and has minimal effect on the rest of the code. |
|
@petercheng00 could you create an |
| @@ -201,7 +201,7 @@ bool PylonGigECamera::applyCamSpecificStartupSettings(const PylonCameraParameter | |||
| // Check if gamma is available, print range | |||
| if ( !GenApi::IsAvailable(cam_->Gamma) ) | |||
| { | |||
| ROS_WARN("Cam gamma not available, will keep the default (auto)."); | |||
| ROS_INFO("Cam gamma not available, will keep the default (auto)."); | |||
There was a problem hiding this comment.
Why is this switched from WARN to INFO?
There was a problem hiding this comment.
There's a lot of warns that happen on startup which seem left over from debugging and in my opinion are not warn-worthy. We'll see what upstream thinks if/when I do a PR there.
There was a problem hiding this comment.
Gotcha. Since we're upstreaming this, I'd say it's better to stay consistent with the existing codebase (if this were our code, I'd want all of the similar messages to be either all WARN's or all INFO's or DEBUG's and we could decide which to choose based on the context). And honestly if you think these aren't errors maybe they should be DEBUG statements anyway? If you feel strongly about this, I think the right place for it is probably a separate PR changing all of them (I think this was the only one I noticed changed).
| // it as a slave, letting camera B pass this code. Then, camera A syncs to the | ||
| // desired master clock, leaving the 2 cameras out of sync. This and other edge | ||
| // cases should resolve within a few seconds, but it's not ideal. One option could | ||
| // be to have camera nodes communicate between themselves, and all block until all |
There was a problem hiding this comment.
Blocking until all conditions are satisfied simultaneously sounds ideal -- how hard would that be to implement?
There was a problem hiding this comment.
I'm not sure - this is definitely where I have a gap in ROS architecture experience. I'm not sure how each node would know which other nodes or messages to monitor for, and I suspect even then there could still be race conditions.
It's definitely simpler architecture-wise to just pass in the required master clock id, but that's then an extra per-machine config thing to set.
Although, it just occurred to me, if we do a setup where cameras are on separate network interfaces, then it's sufficient to just ensure they are slave clocks and we won't have any issues.
There was a problem hiding this comment.
We have plenty of other configs -- if you think the best way to do this is to pass in a master clock ID, that's fine on our end (not sure how the library feels about it).
Is there any way you can have one node monitor both cameras, or would that be a total re-write of this software?
| @@ -328,7 +328,7 @@ bool PylonCameraNode::initAndRegister() | |||
| return false; | |||
| } | |||
|
|
|||
| if ( !pylon_camera_->registerCameraConfiguration() ) | |||
| if ( !pylon_camera_->registerSoftwareTriggerConfiguration() ) | |||
There was a problem hiding this comment.
Should there also be an option where the registerContinuousConfiguration function is run (probably by default)? Ideally we would keep the default settings the same so that users of the library don't have unexpected changes in what happens.
There was a problem hiding this comment.
So, it used to be registerCameraConfiguration, used for setting software trigger config. Because I added ability to use continuous configuration, I renamed registerCameraConfiguration to registerSoftwareTriggerConfiguration. So nothing has changed here, and default behavior is still software trigger.
PTP and sync free run can be enabled at startup via ros
parameters. They are set up within the gige camera's
applyCamSpecificStartupSettings. Controls are not exposed for
for further usage like many of the other camera controls though.
PTP startup will block until sufficient clock synchronization is
reached, though the detection is not perfect.
Sync free run requires continuous acquisition mode, which does not
play nicely with the rest of the code that uses software triggering.
To accommodate the 2 acquisition modes, we also switch between 2
grab strategies.
Also some general bugfixes, e.g. always setting bandwidth parameters
and device_user_id_