[ros-users] call for testing: camera1394 in C-turtle

[Jack O'Quin]

Thanks for the bug report, Hordur.

I just got back from vacation yesterday, please forgive the slow reply.

On Fri, Aug 27, 2010 at 7:05 PM, Hordur Kristinn Heidarsson
<heidarss at usc.edu> wrote:
> Hello,
> I've been testing out the driver with a couple of Videre STH-DCSG-VARX-C
> cameras. The node started out without a problem, but I only got empty/black
> frames from the camera. After messing around and looking through the code, I
> tried commenting out the part where the camera is reset:
> //  if (DC1394_SUCCESS != dc1394_camera_reset(camera_))
> After commenting that out the driver works fine with the cameras. So I did a
> simple fix that checks if the manufacturer and type is VIDERE_DESIGN and the
> model is MDS and skip the reset if that's the case.

I opened a ticket on this defect (#4396), assigned to me.

As you probably noticed, there is some question in the code whether
this reset is actually required. We had discovered a problem with some
AVT f145c2 cameras requiring a retry after the initial reset fails.

That was discovered late in the release testing cycle, and I was
reluctant to remove the reset entirely. If I had, it probably would
have fixed your problem, but there is no telling how many other
cameras might require it, so I chose not to take the risk.

For the next release (Diamondback) removing the reset entirely might
be worth trying, but I'd hate to make a change like that in the
current (C-turtle) release, since it might break other users whose
cameras were working already. I'll look into this further, and
experiment with the cameras available here for regression testing.

If you have a patch that is specific to your Videre model, please send
it to me, for use as the basis of a C-turtle-specific bug fix.

> ps. where in the pipeline would I correct for one camera being mounted
> upside down?

I have no experience with image_rotate, but it looks like it might
handle an upside-down camera, though presumably with additional
message and processing overhead. But, note the warning that it is
mostly for visualization and not recommended as the basis for further
computation.

  http://www.ros.org/wiki/image_rotate

For the special case of an upside-down camera, it would probably be
better to write an intermediate node that just shuffles the bytes
around in the image.

Maybe others can suggest a better solution.

Regards,
-- 
 joq