Adding External Trigger Support in Official Ros driver

[bangyan liao]

Hi,

I'm using the DVXplorer with 30Hz PWM privided by STM32. We have successfully witnessed the trigger msg from the official ros driver dv_ros_capture by playback of the aedat4 file. 

However, we still need the official Ros Driver dv_ros_capture to publish a trigger msg every time a rising edge is received in sign_in. We carefully read the associated codes in dv_ros_capture and dv_processing and find that in dv_processing, there are no API functions for dv_ros_capture to turn on the  external trigger detector. 

But in your official docs, you have mentioned that libcear provides such API to turn on the external trigger detector. I want to turn on the external trigger detector by adding the following codes in the file dv-processing/include/dv-processing/io/camera_capture.hpp line 499.

device->configSet(DVX_EXTINPUT, DVX_EXTINPUT_DETECT_RISING_EDGES, true); device->configSet(DVX_EXTINPUT, DVX_EXTINPUT_RUN_DETECTOR, true);

Please let me know if it is feasible to do so.

best,

Bangyan Liao

Nail Lab, Hunan University

[bangyan liao]

Oops, the above method doesn't seem to work. We are still not receiving any trigger signals from ros driver. Is there any other way to solve it?

[Luca Longinotti]

Hello,

sorry for the late reply.

That code is correct to enable the trigger detection, you can also put it in the ROS driver itself since there is a deviceConfigSet() function that is available to CameraCapture class users.

I've attached a patch for that. You have to then recompile the ROS driver.

Then you also have to enable triggers in the ROS settings, this should already be the case by default in config/settings.yaml and it should print "Triggers enabled: yes" when you start your ROS node.

I've just fixed a small bug that didn't properly set the CameraDiscovery.msg publishingTriggers variable.

Hope this helps, have a nice day!

-- 

Luca Longinotti (llongi)

Head of Embedded Platforms
iniVation AG - https://inivation.com/
Zurich, Switzerland
Office: +41 44 500 32 14

[bangyan liao]

Hi Luca!
Nice to see you again, we really appreciate your help. But the trigger msg still missing.
We checked again the connection between our PWM generator(STM32) and DVXplorer, we can witness the trigger msg from the official ros driver dv_ros_capture by playback of the aedat4 file. This means that our connection is good.
Then, we git clone the latest dv-ros package, and add the associate codes in dv_ros_capture/src/capture_node.cpp with the help of your trigger-enable-camera.patch. And recompile the whole project.
But, we can not see any trigger msg coming from the ros driver dv_ros_capture /(ㄒoㄒ)/~~.
 I am really confused about this problem and can you tell us some possible reasons?

best,
Bangyan Liao
Nail Lab, Hunan University

[Luca Longinotti]

Hello, I'm not sure what the issue is myself.

Since live triggers were not designed for initially in the ROS driver, they were never tested, so there's surely a bug somewhere.

I'll try to reproduce a full ROS setup tomorrow to debug this.

Thank you for your patience!

-- 

Luca Longinotti (llongi)

Head of Embedded Platforms
iniVation AG - https://inivation.com/
Zurich, Switzerland
Office: +41 44 500 32 14

-----Original Message-----

From: bangyan liao <lbyn...@gmail.com>

To: Luca Longinotti <luca.lo...@inivation.com>

Subject: 与“[davis-users] Re: Adding External Trigger Support in Official Ros driver”相关的私人帖子

Date: 03/08/2023 09:53:41 AM

Hi Luca !

Nice to see you again, we really appreciate your help. But the trigger msgs are still missing.

We checked again the connection between our PWM generator(STM32) and DVXplorer, we can witness the trigger msg from the official ros driver dv_ros_capture by playback of the aedat4 file. This means that our connection is good.
Then, we git clone the latest dv-ros package, and add the associate codes in dv_ros_capture/src/capture_node.cpp with the help of your trigger-enable-camera.patch. And recompile the whole project.
But, we can not see any trigger msg coming from the ros driver dv_ros_capture /(ㄒoㄒ)/~~.
I am really confused about this problem and can you tell us some possible reasons?

best,

Bangyan Liao

Nail Lab, Hunan University

在2023年3月7日星期二 UTC+8 23:21:40<Luca Longinotti> 写道：

Hello,

sorry for the late reply.

That code is correct to enable the trigger detection, you can also put it in the ROS driver itself since there is a deviceConfigSet() function that is available to CameraCapture class users.

I've attached a patch for that. You have to then recompile the ROS driver.

Then you also have to enable triggers in the ROS settings, this should already be the case by default in config/settings.yaml and it should print "Triggers enabled: yes" when you start your ROS node.

I've just fixed a small bug that didn't properly set the CameraDiscovery.msg publishingTriggers variable.

Hope this helps, have a nice day!

--
Luca Longinotti (llongi) Head of Embedded Platforms iniVation AG - https://inivation.com/Zurich, Switzerland Office: +41 44 500 32 14

[Luca Longinotti]

Hello, managed to reproduce the issue and committed a fix for it:

https://gitlab.com/inivation/dv/dv-ros/-/commit/3b325aff6a1354164c78fc3487a76609c2006a89

This also includes the previous patch to turn triggers on in the first place.

Fundamentally the issue was that, if an empty trigger packet came in, which is possible on live camera usage if the frequency is <100Hz, the publisher thread would lock up.

Thank you for the reports and your patience, have a great week-end!

[bangyan liao]

Hi Luca!
We appreciate your hard work very much!
We have successfully witnessed the trigger msg from the dv-ros-capture node.
o(*￣▽￣*)ブ
Thanks again for your contribution to the event-camera community.
 
And there is another question about the ros driver time latency.
Since the dv-ros-capture publish trigger and event msg using the ros official timer, I am wondering if there exists a latency time.
If there exists. I am wondering about the magnitude of that time since in our computer this latency is about 4-16ms, and we are not sure whether this comes from the ros driver.

best,

Bangyan Liao

Nail Lab, Hunan University

[Luca Longinotti]

It looks like this should be controlled by the 'timeIncrement' parameter (in microseconds) from settings.yaml.

So by default the ROS thread spins at 1000Hz (timeIncrement is 1000µs -> 1ms -> 1000Hz frequency).

But the libcaer backend only delivers data at 100Hz (10ms intervals), which looks like what you're seeing.

I've committed a small patch to configure libcaer to use the same time interval as the ROS thread, please git pull and recompile.

Thank you for the report and have a great week!

-- 

Luca Longinotti (llongi)

Head of Embedded Platforms
iniVation AG - https://inivation.com/
Zurich, Switzerland
Office: +41 44 500 32 14

-----Original Message-----

From: bangyan liao <lbyn...@gmail.com>

To: davis-users <davis...@googlegroups.com>

[bangyan liao]

Hi Luca!

Thanks very much for your answer (✿◕‿◕✿)!

We git pull and recompile the dv-ros-capture node. 

But we don't think the time increment parameter is the answer to the time latency

After some deeper investigations, below we show a time comparison record between the Trigger record time and the Driver msg receive time.

There are three observations:

1. First is the fixed time delay magnitude during one capturing thread and the different fixed time delay magnitude in different capturing threads  

    which implies the fixed time delay between different time systems.

2. Second I am really confused about the source of the trigger time (＠_＠;),

    I guess the Trigger record time must come from Ubuntu system time since sometimes the Trigger record time is even ahead of the Driver msg receive time.

3. Finally there are some bugs in the ros driver, the Trigger record time sometimes has significant changes.

So, I am interested in 

1. the theoretical time delay between Trigger record time and Driver msg receive time.

2. whether it is possible to align the time system of Trigger record time to ros system time.

best,

Bangyan Liao

Nail Lab, Hunan University

[Luca Longinotti]

Hello, could you repeat your test using native DV time?

Use "trigger.timestamp" directly, as well as "dv::now()", and their difference.

These are all 64bit integers, so you can print them directly.

The values at the start of your test look okay, 1-2 ms difference is completely plausible for data to get to ROS, if you set "timeIncrement" to 1000 then 1ms of data gets accumulated in the libcaer driver and then forwarded, and the ROS driver has its own queues etc., so that's pretty much the expected value given than nothing here is hard or soft-realtime. In theory there are no guarantees about when you receive your data, just that the timestamp is correct. It can still take tens of ms for the data to appear in some ROS module, given all the queues and other programs running on the same system. It's all normal Linux running normal programs, so nothing gives you any hard guarantee. Now in our experience if the system is not under significant load, the delay value is in the 1-5ms range.

In any case the value itself is synchronized with system time (the same time Ros::now() gives you, or the system clock would) at the earliest possible point to give the most accurate result.

The massive jump of -2090 seconds and then the remainder of 57 seconds look a lot like an overflow somewhere, given that 2147 seconds (2090+57) is exactly the overflow value for a 32bit integer, it's a bit too much of a coincidence. But it could still be. The test suggested above will show us if the problem comes from DV time keeping or the ROS conversions.

Does this only happen once at startup, or often? If it only happens once at startup it's most likely some bad interaction with the TIMESTAMP_RESET trigger at startup which can happen. I'm looking into ways to fix that.

[Luca Longinotti]

Hello, please try the attached patch.

It will patch the dv-processing/io/camera_capture.hpp and stereo_capture.hpp files to fix the timestamp reset issue that can sometimes happen at startup, as well as a few other minor issues.

You can just patch the system files installed in /usr/include/dv-processing and recompile the latest ROS driver.

A bug-fix release 1.7.9 of dv-processing is planned for next week.

Let me know your results, thank you and have a great week!

[bangyan liao]

Hello Luca,
sorry for the late reply (┬┬﹏┬┬).
Since the last reported issue, we found by chance that the jump in its time difference was caused by the unstable connection of the trigger line (Vdd line).
Sorry again for the mistake report issue.
We have successfully built up the ms-level hardware time synchronization between the frame camera and the event camera.
We will give additional acknowledgements for your support of our project in our following article.

Thank you again and have a nice weekend ヾ(≧▽≦*)o ! 

best,

Bangyan Liao

Nail Lab, Hunan University