On Sun, Jan 29, 2012 at 6:03 PM, Thomas Moulard
<thomas.moulard@gmail.com> wrote:
> Hello there,
> Here is a very naive implementation of diagnostics support for camera1394.
>
> Rationale: Firewire cameras are often unstable on Linux. It is really bothersome
> to start a demo, launching a bunch of nodes and realizing that the grabbing just
> don't work and you have to reset the bus or worse to recover.
>
> It is a simple use of diagnostic_updater::TopicDiagnostic to make sure
> that if image_raw publishing rate drops
> before a certain rate, it will trigger an error in the diagnostics
> topics. On the same idea, it could as well trigger an
> error when the initialization fails.
>
> The implementation is untested but it compiles. It would like first to
> have feedbacks regarding the patch
> before going further.

Your patch is a big help. I have no previous experience with those interfaces.

The patch creates a separate thread to run the diagnostics updater,
but only for the nodelet implementation. The camera1394_node does not
create this thread or call the updater. I presume that is just a minor
oversight due to the slightly strange camera1394 source file structure
that has evolved.

Multi-threading is tricky in this driver, see the comments in
Camera1394Driver::poll(). I am wondering if we could just call the
updater there in the poll() thread, instead of creating another
thread. Is there any large overhead in calling the updater?

Also, I am still a little confused about how the diagnostics updater
learns the actual frame rate of the camera. Shouldn't there be a
common data structure update? Wouldn't that require a mutex lock?

Regards,
-- 
 joq