[ros-users] Request for Clue: OSX-specific linker flags, dependency resolution

[Jack O'Quin]

On Mon, Jan 17, 2011 at 4:15 PM, Nicholas Butko <nbutko at ucsd.edu> wrote:
> Jack,
>
> Thanks for the tip about dynamic_reconfigure.
> It looks like there was an update to OSX libdc1394 and now my "unexpected
> sync" message is gone. I'm still getting warning messages at 30fps about
> {{{
> libdc1394 warning: packet 479 had error status 0
> }}}
> but I am getting output from my iSight. The output is only *good* output
> when the camera is set to the YUV settings. Otherwise it's quite distorted.
> Is there a good way to automatically detect when the camera is in some
> unsupported mode, and only use supported modes?

Funny you should ask. Over the weekend I implemented that in SVN
trunk, so it will be included in the Diamondback versions (coming
soon). It seems to work fine, at least in my unit tests with three
different cameras.

This will not be supported for the cturtle version, that is why I
recommended using coriander to explore the different modes and
discover useful settings. That is still a useful tool on Linux, where
it's typically a single install, but not worth building by hand on OSX
if there's not a copy readily available.

> Is there a way to get rid of these warnings? If I was seeing them in OpenCV
> they would make my programs useless, because any information that gets print
> out is swamped by the warnings.
> I'm not sure how involved with the development of libdc1394 you are, or if
> you are in a position to do things like make changes to warnings about error
> statuses.

I am not involved in libdc1394 development at all. Camera1394 is just
uses that library. I do try to follow their mailing list, which has
not been very active lately. I suspect Damien Douxchamps has been busy
with other things lately.

I did hear a report last summer about known problems in some macports
version of libdc1394. It might be worth googling to what patches there
are. (I tried that and the first report that came up was from you. :-)

Ideally, I would prefer that library code almost never print error
messages. They should return error status to the caller, who can
decide where it ought to go.

But, the occasional libdc1394 message has not been much of a problem
for camera1394 driver development, because I use ROS logging
facilities instead of printf, even for debug output. The ROS tools
(rxconsole, etc.) do a good job of keeping the relevant messages from
being lost in the noise. The stdout messages do get captured in the
log when running with roslaunch, but I seldom find myself looking at
them.

If you run OpenCV using the ROS package interface, that approach might
work well for you, too. It's easy to convert printf() into an
equivalent ROS_INFO() or ROS_DEBUG().
-- 
 joq