duplicate imu timestamps when capturing ros1-bdata:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAA1oAAAHgCAYAAAC8bBykAAAAOnRFWHRTb2Z0d2FyZQBNYXRwbG90bGliIHZlcnNpb24zLjEwLjgsIGh0dHBzOi8vbWF0cGxvdGxpYi5vcmcvwVt1zgAAAAlwSFlags with dv-ros and dvxplorer-micro

[Erik Schlenzka]

Hello,
I'm using the DVXplorer and DVXplorer micro in combination with dv-ros for recording event data in ros1.bag format. I encountered the problem, that the DVXplorer micro produces rosbags with duplicate imu-timestamps.

In the attached plots you can see the time intervall between 2 sequential imu-timestamps over a 20s bag, recorded with the DVXplorer micro (on a raspberry5).:

As you can see everywhere where the graph hits 0, the timestamps are duplicate.
I also tested the same capturing (identical dv-ros node and same computer) with the DVXplorer(normal) and get a bag with nearly constant time intervalls between timestamps, as visible in plot2.:

What could cause this?
Did anyone encounter a similar problem?

I am thankful for any kind of help!

[Luca Longinotti]

Hello, yes this is expected. The DVXplorer uses an FPGA to read out the IMU and Event data, and then applies the timestamp from the same time source in the FPGA, achieving high accuracy and consistency.

The DVX Micro on the other hand reads the IMU data on a micro-controller and sends it out over USB without timestamping, since we don't have a global time source that can be used for both Events and IMU on its architecture. On the host PC, the last timestamp we get from the Events is then applied to the IMU data. Due to small delays in USB transmission and processing, it is possible to have 1-5µs jitter, as well as some timestamp being assigned equal, both of which you're seeing. Again, this is normal with the Micro architecture, there are some ideas floating in my head on how this could be improved, but time synchronization is a tricky things.

Hope this helps, have a great day!

[Luca Longinotti]

Correction: ~1-5 milliseconds jitter, not microseconds. :-)

[Erik Schlenzka]

Thank you for the fast response!

My naive solution for the imu-timestamp issue right now is to patch dv-ros to detect duplicate timestamps before publishing and increment it by the inverse of my known imu-frequency.

I have another issue with the dvxploerer-micro, I observe high spikes of off-events, when capturing data.

About my configuration:
Because I'm operating on weak hardware running ros1, I took measures to reduce the maximum number of events per second to prevent ros from dropping messages during publishing.

These measures are

- configuring the Contrast Threshold to be maximal (17) in the dv.ros config.

- put a frequency filter (lowpass) after the noise filter implemented in dv-ros, limiting average frequency per pixel to 100Hz.

dv-ros/dv_ros_capture/src/capture_node.cpp:826

"""

while (events.has_value() && !events->isEmpty() && timestamp >= events->getHighestTime()) {
dv::EventStore store;
if (mNoiseFilter != nullptr) {
mNoiseFilter->accept(*events);
store = mNoiseFilter->generateEvents();
}
else {
store = *events;
}
if (mFrequencyFilter != nullptr) {
mFrequencyFilter->accept(store);
store = mFrequencyFilter->generateEvents();
}

if (mEventArrayPublisher.getNumSubscribers() > 0) {
auto msg = dv_ros_msgs::toRosEventsMessage(store, resolution);
mEventArrayPublisher.publish(msg);
}

mCurrentSeek = events->getHighestTime();

std::lock_guard<boost::recursive_mutex> lockGuard(mReaderMutex);
events = mReader->getNextEventBatch();
}

"""

During event capturing I now observe big spikes in event count from lots of off events, as visible in this plot:

Is this behavior expected when changing the Contrast Threshold or is something different at fault?

I'm aware my lowpass-filter can't prevent these spikes because it operates on a per pixel basis, not on the total amount of events per second.

Thanks for any kind of help!