Unable to pass the ptpAcquisitionGateTime property for fixed rate frame synchronization

[sskulka]

Hello,
My team & I are currently working on a project that involves multiple Mako G319C camera ptp synchronization. The approach we are following is attached in the image below

However once we try to set the PtpAcquisitionGateTime through the configureFeature function, we noticed that no such property exists on the camera config object which is not the case with other properties. We did some digging as to how the properties are created for the config object through parameters from the config cfg file. We are unsure of how these properties are passed on to the camera object to take effect. Could you please make us aware of how the flow of the code is and what would be the best approach to set the ptpAcquisitionGateTime through the ROS driver? (We were able to manually set it in the vimba viewer but that's not what we want)

[icolwell-as]

Hi @sskulka,

Assuming you are talking about the ROS1 version, all configs are defined in the cfg/AvtVimbaCamera.cfg file.
These configs are then received by the mono_camera node via the dynamic reconfigure callback. The callback updates the settings on the camera via the updateConfig function.

So if you'd like to add a new config/feature, you'd need to update the cfg file, then add code in avt_vimba_camera.cpp to apply the config to the camera.

Also, the approach you describe is the same approach that Chris described here. You may have some luck by checking out his fork of the repo, perhaps he already has a solution implemented.

Also, the ROS2 version of this driver creates the ROS parameters dynamically based on the camera, meaning almost every feature/setting the camera supports is available as a ROS parameter. Perhaps that may be an option for you too.

[sskulka]

Hi @icolwell-as ,

Yes I'm writing in context to ROS1, thanks for describing the flow and pointing to Chris' work pertaining that. He's actually our advisor on the project and after speaking with him on this issue, we realized that we don't need to add 'PtpAcquisitionGateTime' to the config since it is a runtime set value.
We are currently focused on updating the 'PtpAcquisitionGateTime' feature through the setFeatureValue function.
We run into the following issue where we are getting the VmbErrorInvalidAccess error code even when the IsWritable is true. We tried to set other int64 type features in the same code black and they are getting set. The camera pointer access is also read and write. Could you please help in identifying the cause of the access issue?



.

[icolwell-as]

Hi @sskulka, your screenshots appear to show me the existing code, but what about the code changes you made?
For example, when/where are you calling the setFeatureValue function to set PtpAcquisitionGateTime?

I ask because the AvtVimbaCamera::updateConfig function stops the camera from imaging before making config changes.
I don't remember if stopping the stream is a strict requirement for all feature types, but maybe you are trying to set the PtpAcquisitionGateTime while the camera is still imaging?

[sskulka]

Hi @icolwell-as ,
So currently we have defined a custom function 'ptpSyncTrigger()' that we are calling in the dynamic reconfigure if our configuration's stereo property is true. We are passing stereo=true and trigger_source="FixedRate" values from the launch file and then updating the config to have those values updating in it.
So what steps would you suggest us to take? In addition to setting the feature's value, should we also add the PtpAcquisitionGateTime to the config and then run updateConfig once again to make the camera stop imaging?
Is there any other way we can modify a feature by stopping the imaging and then restarting it later?

[sskulka]

@icolwell-as
Update: we also tried stopping the imaging using the avt_vimba_camera::AvtVimbaCamera class' stopImaging() method before our function's call and then restarting it using startImaging() method. Still giving the same vmbErrorInvalidAccess.

[icolwell-as]

Hi @sskulka, I've never used the PtpAcquisitionGateTime before so I don't have any experience to offer unfortunately.
The only things I can think of would be to ensure the cameras are ptp synced first before trying to set the gate time (I assume you are already doing that).
Also, you can try reading through the documentation to learn more about the ptp features, here's a snippet for PtpAcquisitionGateTime:

PtpAcquisition trigger time. Used to schedule a synchronized software trigger
on multiple PTP synchronized device. PtpAcquisitionGateTime must be set
beyond current camera GevTimestampValue , for instance GevTimestampValue 
PtpAcquisitionGateTime . If set below GevTimestampValue , image acquisition
stalls. PtpAcquisitionGateTime resets to zero if PtpMode set to Off .

Also, were you able to get it to work from Vimba Viewer? If it also doesn't work from Vimba Viewer, then the issue is unrelated to the ROS driver, and maybe following up with AVT support is the best approach.

[sskulka]

Hi @icolwell-as ,
Yes, we're using ptp before firing up the code and also we are able to set the PtpAcquisitionGateTime feature through Vimba Viewer.

As a sanity check, we set the PtpAcquisitionGateTime entries in the AvtVimbaCameraConfig.h and AvtVimbaCamera.cfg file by mimicking the existing feature entries in those files. Then we tried using the VimbaAPI and getting the value from the feature but it is not showing. Is the feature entry not being present on the config object of the ROS driver a possible cause of issue?
Moreover, I wanted to know what methodology to follow to add a new feature entry to the config object from the code.

We were able to save the config containing PtpAcquisitionGateTime from Vimba Viewer, is there a way in which we can pass the xml file as an input in the constructor of the config object? I didn't find any overload that had a string path in it.

[icolwell-as]

Hi @sskulka, if you added a new field to the AvtVimbaCamera.cfg file and re-compiled, it will auto-generate the AvtVimbaCameraConfig.h file for you. Once you have the re-compiled AvtVimbaCameraConfig.h, then you should be able to use the new field in the updateConfig function along with the other configs.

I also dug up more information on the error you are seeing:

VmbErrorInvalidAccess   = -6,           // Operation is invalid with the current access mode

The driver will always open the camera with VmbAccessModeFull, so I don't see why this would not work. Maybe try opening the camera in a different access mode? maybe the config one?

    VmbAccessModeNone       = 0,            // No access
    VmbAccessModeFull       = 1,            // Read and write access
    VmbAccessModeRead       = 2,            // Read-only access
    VmbAccessModeConfig     = 4,            // Configuration access (GeV)
    VmbAccessModeLite       = 8,            // Read and write access without feature access (only addresses)

Additionally, it might be worth double-checking that the firmware on the cameras are up-to-date.

[sskulka]

Hi @icolwell-as ,
Thanks for describing the procedure, we did successfully add the value to the PtpAcquisitionGateTime feature by modifying the cfg as you described. To verify it, we started the vimba viewer and the camera started acquisition after the delay offset that we provided it from the time of execution of code.
We saw the avt_vimba_camera::AvtVimbaCamera::openCamera() was setting the access mode of the camera at
err = camera->Open(VmbAccessModeFull);
This executed with a success error msg but if we try to query the access mode later in the code at any point, we are getting the VmbAccessModeNone which is confusing.


We tried querying the access mode value at multiple places but are getting VmbAccessModeNone at all of them. This is leading us to have the InvalidAccess return code at the PtpAcquisitionGateTime feature set line even though the feature gets set.

[icolwell-as]

Interesting, I'm not sure why the PtpAcquisitionGateTime feature would return InvalidAccess when trying (and succeeding) to configure it. Perhaps that one feature needs to be treated differently for some reason.

It sounds like you have a working solution for now though?

[sskulka]

Yes, do you think this is a bug of some kind then? Yes, we seemed to have triggered our acquisition after the given offset through the code which means the parameter is taking effect.

[icolwell-as]

It seems like a bug to me, since you clearly have the correct access mode if it was able to apply the feature. Doesn't seem like it should throw that error.
Glad it's working though!

[JanezCim]

I'm actually having trouble configuring my USB cameras as well (afaik, configuring USB cameras should be exactly the same as GigE) and im seeing some very similar stuff:

We saw the avt_vimba_camera::AvtVimbaCamera::openCamera() was setting the access mode of the camera at err = camera->Open(VmbAccessModeFull);This executed with a success error msg but if we try to query the access mode later in the code at any point, we are getting the VmbAccessModeNone which is confusing.

Im seeing exactly the same thing, this is confusing indeed

We run into the following issue where we are getting the VmbErrorInvalidAccess error code even when the IsWritable is true.

Im seeing this even with the default parameters that are enabled by this driver. In fuction VmbErrorType AvtVimbaCamera::setFeatureValue I've added additional error printing code after vimba_feature_ptr->SetValue (which it would probably be nice if it was there anyway):

err = vimba_feature_ptr->SetValue(val); 
if (err == VmbErrorSuccess)
{
  ROS_DEBUG_STREAM("Success setting feature " << feature_str << " value " << val);
}
else
{
  ROS_WARN_STREAM("Faliure setting " << feature_str << ": " << api_.errorCodeToMessage(err));
}

and after launching the driver I get output (see the parameters where it says Invalid access):

The camera was started with R/W access:

[ INFO] [1656678662.426244291]: Found camera named Allied Vision 1800 U-240c:
[ INFO] [1656678662.426354540]:  - Model Name     : 1800 U-240c
[ INFO] [1656678662.426416146]:  - Camera ID      : DEV_1AB25342534567
[ INFO] [1656678662.426467670]:  - Serial Number  : 01VMV
[ INFO] [1656678662.426529787]:  - Interface ID   : VimbaUSBInterface_0x0
[ INFO] [1656678662.426592929]:  - Interface type : USB
[ INFO] [1656678662.426645285]:  - Access type    : Read and write access

To me this seems to indicate that even some default parameters are not being written to camera. I don't know if this is just on my USB camera or this also happenes on GigE cameras?

Also, were you able to get it to work from Vimba Viewer? If it also doesn't work from Vimba Viewer, then the issue is unrelated to the ROS driver, and maybe following up with AVT support is the best approach.

Setting these same parameters from Vimba Viewer works completely fine

The driver will always open the camera with VmbAccessModeFull, so I don't see why this would not work. Maybe try opening the camera in a different access mode? maybe the config one?

When I tried opening with VmbAccessModeConfig, the camera could not be recognised:

[ WARN] [1656679783.490436689]: Could not open camera. Retrying every two seconds ...

any idea what to do next?

[icolwell-as]

Hi @JanezCim, we've noticed that some USB cameras have different feature names than GigE (see here for details).

I suggest using the ROS2 version of the driver if you are able to, or if you must use ROS1, take a look at the forks created by others that have used USB cameras.

[JanezCim]

I see, thank you @icolwell-as

Just as a clue for people still researching this, i think actually been able to solve the Invalid access problem by force stopping camera every time i want to change the parameters by commenting out this conditional:

avt_vimba_camera/src/avt_vimba_camera.cpp

Line 792 in 31f04d4

if (streaming_)

as a result im getting an error

[ERROR] [1657012516.797521013]: Could not stop image acquisition.
 Error: TL error.

but at least all the parameters are set every time without the Invalid access problem.

[dagata-mining]

force

Hi Janez, Same here, I'm having trouble with stopping image acquisition. Any updates on that?

[JanezCim]

@dagata-mining yes, I've ended up solving it in a separate fork https://github.com/flx-robotics/avt_vimba_camera/tree/feature-usbcam-1800u-240 (tested only with 1800u-240 cameras) along with some other problems i had, namely #103
I'm waiting for an answer to that issue before I do a PR.