ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

camera1394 timestamps for Point Grey USB cameras

asked 2011-03-02 17:02:28 -0500

updated 2011-03-03 05:39:14 -0500

I've started to look at using camera1394 for my Point Grey Firefly MV USB camera. This camera implements 1394-over-USB and seems to work fine with camera1394 as far as I can tell, with one exception: The timestamps on the output are incorrect. They are typically sometime in January 1970 :)

  seq: 191
    secs: 34
    nsecs: 533856000
  frame_id: /camera

Looking at the code it seems that the timestamp is generated using data from the camera:

image.header.stamp = ros::Time((double) frame->timestamp / 1000000.0);

I'm not sure why the timestamp is nonzero--it could just be from uninitialized memory. These cameras _do_ have an option to output some kind of timestamp, and I have enabled it, but in their own tool ("FlyCapture2"), the "seconds" and "microseconds" fields are zero even with this option enabled. There are however some other fields, "1394 cycle time seconds", "1394 cycle time count", and "1394 cycle time offset" but this seems to be time since capture started, not since the epoch.

Anyhow the question is, has anyone else using these cameras found a way to have the true timestamp included in the image/camera_info header?

UPDATE: Here is what is printed when camera1394_node is started:

$ rosrun camera1394 camera1394_node _guid:=00b09d010090a878
[ INFO] [1299180874.481328850]: Found camera with GUID b09d010090a878
[ INFO] [1299180874.481629395]: camera model: Point Grey Research Firefly MV FMVU-03MTM
[ INFO] [1299180874.490429490]: [00b09d010090a878] opened: 640x480_mono8, 15 fps, 400 Mb/s
[ INFO] [1299180874.528790077]: feature exposure value not available from device
[ WARN] [1299180874.612162273]: [00b09d010090a878] calibration does not match video mode (publishing uncalibrated data)
edit retag flag offensive close merge delete


Having searched through the libdc1394 source code, I've found the places where frame->timestamp gets set for the native Linux 1394 module, the MacOS module and the juju firewire module, but there's nothing about timestamps in the usb module.
Ken gravatar image Ken  ( 2011-03-03 04:35:28 -0500 )edit
We could add an option to have camera1394 override frame->timestamp with the system time. I don't see any really good way to tell whether a camera is on USB, but we could try using camera->model. When you start camera1394 and it prints out the camera's model name, does that include "USB"?
Ken gravatar image Ken  ( 2011-03-03 04:39:55 -0500 )edit
Yeah that's what I was thinking. Maybe best to just have a parameter to force this behaviour (who knows, maybe even for some true 1394 cameras this might sometimes be the right thing to do--depends on what you are using the timestamp for I guess). I can contribute a patch.
Patrick Bouffard gravatar image Patrick Bouffard  ( 2011-03-03 05:40:43 -0500 )edit
Ok this commenting system is a bit annoying due to the character limit.. Also it probably makes more sense to move to ros-users (-developers?) or email to discuss implementation. I'll drop you a line Ken.
Patrick Bouffard gravatar image Patrick Bouffard  ( 2011-03-03 05:41:58 -0500 )edit
I'm in a favor of a parameter essentially for `use_hardware_time`. Best thing is likely to just open an enhancement ticket against camera1394 and then link to that ticket in an "answer" to this question. Implementation can be discussed there with iterations on a patch.
Eric Perko gravatar image Eric Perko  ( 2011-03-03 05:48:07 -0500 )edit
Good point Eric, I hadn't considered that the ticket can have its own conversation thread!
Patrick Bouffard gravatar image Patrick Bouffard  ( 2011-03-03 05:54:33 -0500 )edit

1 Answer

Sort by ยป oldest newest most voted

answered 2011-03-03 05:56:05 -0500

updated 2011-03-03 06:27:29 -0500

Eric Perko gravatar image

It appears not to be possible with the current driver/dc1394 implementation. A workaround is in the works, see comments above and .

edit flag offensive delete link more


@Patrick Bouffard, go ahead and accept this answer (if you can.. or perhaps an admin can since I seem unable to do it for you). I can't think of a more right answer to this question than go reference the camera_drivers ticket tracking the problem.
Eric Perko gravatar image Eric Perko  ( 2011-03-03 06:02:37 -0500 )edit
Yeah that was my plan but it won't let me accept my own answer!
Patrick Bouffard gravatar image Patrick Bouffard  ( 2011-03-03 06:19:25 -0500 )edit
I went ahead and did the accept
kwc gravatar image kwc  ( 2011-03-03 06:24:06 -0500 )edit

Question Tools


Asked: 2011-03-02 17:02:28 -0500

Seen: 2,609 times

Last updated: Mar 03 '11