search

anqixu / ueye_cam

A ROS nodelet and node that wraps the driver API for UEye cameras by IDS Imaging Development Systems GMBH.
Other
60 stars 102 forks source link

ueye_cam timestamp is 3600 seconds old #36

Closed falkoschindler closed 8 years ago

falkoschindler commented 8 years ago

I'm running a ueye_cam node as follows:

<node pkg="nodelet" type="nodelet" name="nodelet_manager" args="manager" />

<node pkg="nodelet" type="nodelet" name="ueyecam" args="load ueye_cam/ueye_cam_nodelet nodelet_manager">
    <param name="camera_name" value="ueyecam" />
    <param name="image_width" value="1600" />
    <param name="image_height" value="1200" />
    <param name="frame_name" value="ueyecam" />
    <param name="camera_intrinsics_file" value="ueyecam.yaml" />
    <param name="frame_rate" value="15" />
    <param name="exposure" value="10" />
</node>

But in contrast to other nodes and the official unix timestamp, the timestamp of the /ueyecam/image_raw message is 3600 seconds (=1 hour) old.

I asked the IDS support if this might be a camera-specific setting. They replied referring to the u64TimestampDevice and TimestampSystem fields of the UEYEIMAGEINFO structure: https://en.ids-imaging.com/manuals/uEye_SDK/EN/uEye_Manual/is_getimageinfo.html.

Is the ueye_cam node evaluating these information correctly? Where can the offset of one hour come from?

Edit: I'm from Germany. My local time is Central European Time (UTC+01:00) and the offset could arise from wrong time zone settings.

gavanderhoorn commented 8 years ago

Related ROS Answers question: ueye_cam timestamp is 3600 seconds old - How to correct?

anqixu commented 8 years ago

ueye_cam is indeed using time information from the UEYEIMAGEINFO: https://github.com/anqixu/ueye_cam/blob/master/src/ueye_cam_driver.cpp#L1289 https://github.com/anqixu/ueye_cam/blob/master/src/ueye_cam_nodelet.cpp#L952 https://github.com/anqixu/ueye_cam/commit/a89b4f1008b110295cd48dd12afb1cd918e8f309

The u64TimestampDevice field is meant to obtain relative times, and from my understanding, does not entail absolute time but rather cycle tick counts.

I have previously tested the frame timestamps from ueye_cam, and did not observe such a discrepancy.

At this point, the most likely suspect is the recent shift of daylight saving from 3 days ago. Given the sudden large change in time, the IDS camera may be refusing to automatically synchronize with the system clock. I seem to recall ueyedemo allowing you to manually force synchronization, so I would try that.

I don't think the uEye camera internally stores timezone information. From is_GetImageInfo's docs: "The timestamp is synchronized with the PC's system time", which I'd assume to literally mean "synchronizing to date/time obtained from 'date'".

Other than the above, or implementing an ugly hack in ueye_cam to subtract 3600 seconds from the timestamp manually (which is generally non-recommended), I do not know if there is another solution.

falkoschindler commented 8 years ago

I'd like to add that the offset is unlikely caused by daylight saving time, since I'm observing this problems for weeks now - and Germany won't be changing to daylight saving time before end of March.

I'll check ueyedemo for a manual time synchronization function. Otherwise, it looks like I need to stick with my hacky time-conversion node as a workaround.