I think it's a good point. Though if you enforce that the timestamps be
very close, I think it shouldn't be a big issue. Some setups will have
two different kinds of cameras (for good reason) that you may want to
gather some occasional stereo information from (unfortunately, there
seems to be an assumption that both cameras have the same resolution in
the python calibration code).
In any case, the problems I am seeing *may* stem from forcing my cameras
(which are 1280x960 native resolution) into 640x480. So, as of now,
I'm going to put this on the back burner -- really all I wanted to know
was the transform from 1 camera to another, which is working.
Blaise Gassend wrote:
> With two threads this morning discussing calibration with unsynchronized
> cameras, I can't help wondering how well the camera_calibration code
> will work if the cameras aren't being triggered simultaneously. If
> camera_calibration decides to use a pair of frames in which the
> checkerboard was moving, I imagine that you might be trying to match
> checkerboards that were actually at different positions, which would
> certainly lead to poor calibration.
>
> I have no idea if this is a reasonable worry to have, and James could
> probably say more about this than I could. I imagine that motion blur
> would tend to discourage the use of frames in which the target is
> moving.
>
> On Tue, 2010-04-06 at 15:31 -0500, Patrick Beeson wrote:
>> I'm trying to calibrate two identical 1394 cameras that are sitting next
>> to each other. The stereo calibration from camera_calibration converges
>> to VERY bad R and T matrices, rotating the frames and
>> the warping the images drastically. I've tried several times, with no luck.
>>
>> _______________________________________________
>> ros-users mailing list
>> ros-users@code.ros.org
>> https://code.ros.org/mailman/listinfo/ros-users
>
>
> _______________________________________________
> ros-users mailing list
> ros-users@code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
(text/plain)