On Fri, Dec 3, 2010 at 4:29 AM, Jack O'Quin <
jack.oquin@gmail.com> wrote:
> On Thu, Dec 2, 2010 at 8:07 PM, Thomas Moulard <thomas.moulard@gmail.com> wrote:
>> On Fri, Dec 3, 2010 at 2:54 AM, Jack O'Quin <jack.oquin@gmail.com> 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
(text/plain)