On Fri, Dec 3, 2010 at 4:29 AM, Jack O'Quin wrote: > On Thu, Dec 2, 2010 at 8:07 PM, Thomas Moulard wrote: >> On Fri, Dec 3, 2010 at 2:54 AM, Jack O'Quin wrote: >>> Since two cameras on the same bus are synchronized automatically, it >>> may just work, even with separate processes. >> >> As long as you synchronize the acquisition with some interprocess locking. >> The context switch may also introduce a delay between the two acquisitions. >> >>> Just to see what happens, could you try running two driver nodes each >>> connected to a single camera? Capture some images in a bag and check >>> the timestamps when they are published. That is easy to do with >>> "rxbag". >> >> They are close but not identical (nsec are different). > > Looks like it's working fine in the bag you captured. The differences > between frame times are in tens of microseconds, better than the 125 > usec maximum deviation claimed by Point Grey. > > The camera drivers are not doing any synchronization, it's provided by > the bus. Note that this synchronization would not happen if the > cameras were attached to different 1394 buses. > > This is close enough for stereo processing. Since the time stamps are > not identical, our current stereo_image_proc rejects them. But, the > proposed approximate time stamp matching ought to work great for this > device. > > I would expect about the same results with a nodelet implementation. > > Thanks for running the test... And thanks for taking the time to check the bag! Seems like using ApproximateTime in stereo_image_proc is the ideal solution in my case. Thanks again. -- Thomas Moulard http://www.linkedin.com/in/moulard