Adding PTP and sync free run

[petercheng00]

I wanted to support PTP (#25 might be interested) and also synchronous free run. I have it working here: https://github.com/iron-ox/pylon-ros-camera/tree/petercheng/ptp_sync_free_run

However, the changes are somewhat messy. Sync free run require continuous capture mode and not software trigger mode, and the codebase seems to be built assuming software trigger mode. Do you have any suggestions for how the code could be made cleaner?

I was also considering making it a separate node for continuous capture / sync free run. Perhaps one node could manage multiple cameras to ensure they are all synced simultaneously. However, I couldn't find a good place to split between the node code and the camera code. Any thoughts or suggestions on that?

Thanks

[m-binev]

Hi Peter,
we have decided not to implement the PTP features in ROS at first stage, because we have not believed that anyone would need them in robotics apps.
You obviously prove us wrong now)) May you provide me with some more details on your app and why do you believe that you need PTP?
If you want to sync two cameras, you could trigger the first one by software trigger and connect the HW output of the first camera to the HW input of the second camera - we call that dragchain mode.
Otherwise, you are right. The current ROS implementation considers software trigger mode only. Sync free run would need the cameras to run in a non-triggered mode and share sync packages via a switch... as a said, as we cannot imagine what robotics use case would support that scenario, this is currently not supported in our ROS driver.
Also sending so-called Action Commands or Scheduled Action Commands is not supported and I can hardly imagine this would work on ROS at all.
So getting any insights and further info from you would be nice.
Regards

[petercheng00]

2 reasons:
I was not able to get good synchronization from one camera triggering another. The camera model I'm using only supports trigger output on exposure start, and a trigger input for capture start, which are not quite aligned. I did get better results by instead having one camera send a user signal to then trigger capture start on both cameras. But still somehow not as good as ptp/sync free run. Basler docs recommend ptp in a couple places, so I decided to look into that instead.

2nd reason is that the cameras will be in motion, and we know our position over time. Having good timestamps for when exposure starts/stops is then useful

[m-binev]

Hi Peter,

no doubt PTP is very helpful & useful feature for synchronizing and triggering of multiple cameras and it is fully supported by the Basler pylon Camera Software Suite (but the ROS driver yet).
Again, may you describe your setup (PC, GigE switch, the application use case behind), please?
I try to figure out in what robotics applications PTP is needed and in perticular, I try to understand your app in order to potentially help you in a different way.

[petercheng00]

I have a PC connected to a switch, connected to 2 cameras. These 2 cameras are used for stereo 3d reconstruction. We move the cameras around via a robot to fully scan a scene. Thus we want good syncing between cameras to be able to get good depth data while in motion, and having a synced clock means we get better position information based on robot's location.

[m-binev]

Hi & many thanks for revealing more information on the use case.
Yes, I also think that using PTP synchronous free-run may solve your use case.
To implement the support for synchronous free-run (the camera parameter access) in ROS should be a piece of cake, I think. The more workload would be related to implement free-run instead of software trigger...
We'll check if we could do anything on that in near time/future.

[johnzjq]

@petercheng00 Hi Peter, we have little luck in grabbing the images from multiple cameras simultaneously. In our case, all the cameras are synchronized by ptp4l using the system as the master. By fetching the OffsetFromMaster value, we found multiple cameras seemed to be synchronized (the largest offset is -27 ticks). However, when we tried to retrieve the images the timestamps chunk data suggested there are about 0.1 seconds (1e8 ticks) difference between two images. Would you please provide some suggestions? Thanks! Our grabbing code is similar to this one: https://github.com/MattsProjects/PylonSample_Stereo_Acquisition_PTP/blob/master/source/PylonSample_Stereo_Acquisition_PTP.cpp

[petercheng00]

Hi @johnzjq. I haven't seen that issue in my setup - my image timestamps are all only a couple nanoseconds apart. I am reading timestamps via a CGrabResultPtr from the OnImageGrabbed method of a CImageEventHandler. I notice your link uses timestamps passed via chunk data though. I'm not sure when chunk timestamps are taken, so perhaps that's one thing to check.

[johnzjq]

Hi @petercheng00 , thanks for the reply! The problem has been solved by restarting the computer... The timestamp in the chunk data is given by the camera https://docs.baslerweb.com/data-chunks#timestamp-chunk. And we read the chunk data in the image grabbing loop.

[pablo-quilez]

Hello Peter,

I was taking a look to your branch https://github.com/iron-ox/pylon-ros-camera/tree/petercheng/ptp_sync_free_run
You forked it from the IronOx fork, I think maybe we can try to test and merge a PR from your work into devel. What do you think about it?

Cheers,
Pablo

[petercheng00]

I am not actually using that code anymore - I wasn't that happy with how messy some of the integration was, so I decided to write a separate minimal ROS node specifically for PTP for my current application.
In the next few months though, I will need some more camera features accessible, and will probably look into integrating with this library again.
So, right now I don't have much desire to get that code merged (though if others are interested, we can do so). And if not, feel free to close this issue, I can reopen if/when I make another attempt.

[chentairan]

Hi @petercheng00

My application has a great demand for PTP synchronization, and noticed that there is an implementation of PTP under your fork. And I have some questions about this.

How can I get the timestamp after synchronization？
Could you add some documentation about camera settings and parameter settings ?

Thanks,
Tairan Chen

[petercheng00]

@chentairan I'm no longer using that fork - I've switched to a minimal stand-alone node instead, perhaps it will be useful to you: https://github.com/iron-ox/basler_camera/blob/iron-kinetic-devel/src/basler_synced_cameras_node.cpp
The PTP time is passed along in the image header there.

As I mentioned above though, I do want to return to using this library, and I think the better way to include PTP would be to just expose the relevant pylon api calls, and let users externally handle syncing, capture strategy, etc. I hope to make a PR for that soon, it should be pretty simple.

[nachovizzo]

@m-binev Is there any plan to add support for this? After 2 years of struggling with PTP problems, we are thinking if we should change the cameras in our robots...

In one of our applications, there are 4 Basler cameras that are "fighting" against our PTP master to become masters themselves. With other sensors, we just set the sensor to be on slave-only mode, and everything works as expected with no complications. Is there any way I could help implement this feature?

[m-binev]

@nachovizzo Hi, thank's for your message. And I beg a pardon, I've never been aware of your problems with PTP. Looking at the current issue, I think other users get PTP working fine already. Regarding the slave-mode, you can configure the cameras as slaves either. Please check the Basler documentation on: https://docs.baslerweb.com/precision-time-protocol
Or are you expecting that the admin adds the related params to do so? Regards
@FrancoisPicardDTI FYI

[chentairan]

Hi @m-binev , we encountered the same problem when using the camera, especially when the cameras were on a LAN formed by a switch. Once the last time the camera was the master clock, the camera will always be the master clock thereafter.

Our solution is to have the PTP master clock connected directly to the camera to "reset"(I guess) the state of the camera clock.

[m-binev]

@chentairan , @nachovizzo Hi, to be honest I am not sure if we speak about right/wrong camera configuration or a camera issue. As it would be difficult to figure this out here (no proper equipment to do so), I would recommend you to open a standard support case (support.europe@baslerweb.com) while providing the Linux OS version, camera models/serial numbers, pylon version, setup description. I would not mention ROS yet, because you need a clarification on the camera configuration and behaviour first. According to the documentation though, you should be able to configure the cameras to accept an external master clock. Regards
@FrancoisPicardDTI FYI

[nachovizzo]

@m-binev We already contacted support many times. I thought of reaching out here to the community to see if someone had an alternative (not official) solution. Since it looks like BASLER is not interested in fully supporting the IEEE1558(PTP) protocol...

According to this thread @petercheng00 also struggled with the same and we found a similar solution to the one we have right now... just wait until the cameras give up con fighting to be the master, as you might expect, is not acceptable :)

If we find an alternative solution we will post it here for the benefit of the community, but so far looks like we won't be able to do it/

[m-binev]

@nachovizzo Hi, may you name the support case number after having contacted the Basler support, please? I've just checked the support data base and found no support cases associated to you. Alternatively, please simply create a new support case and I'll make sure to give it some attention. Just pretending the cameras are not fully supporting PTP is not okay... Regards

[nachovizzo]

@m-binev Apologize for the trouble, I will ask the person on my team who has been following this on the Basler side, and ask for the support case. As far as I remember we got redirected to Rauscher that might explain why you can't find information on your system.

Thanks for taking care of this issue

[FrancoisPicardDTI]

Hello

The ROS2 pylon driver v1.1.0 (branch galactic) gives now access through services to PTP related parameters and commands, allowing to enable PTP synchronization, to issue scheduled or not action commands, to use the periodic signal camera feature for ACE2 and the synchronous free-run feature for ACE1.
I am thus closing this issue.

[farhad-dalirani]

I am using two Basler cameras as a stereo system for a car. The hardware synchronization is necessary for me. How can I do that with the ros package?