Thanks Tully, it seems then that the thread I introduced is totally
superfluous and should be removed.

On Sun, Feb 5, 2012 at 4:02 AM, Jack O'Quin <jack.oquin@gmail.com> wrote:
> More questions about the DiagnosticsUpdater:
>
>  * Where does the component name get set? I presume it should be "camera1394"

There is two different names:
1. the hardware id, this one should match the camera id so that messages are not
ambiguous if several cameras are connected. I set it to camera_name
but I am not sure
if this is right or not.
2. the diagnostic message, this one seems to be computed automatically
when a TopicDiagnostic
is used. This one is for the user so it just have to be clear and
consistent between version so
users do not have to change their robot_monitor configure file again and again.

>  * Is the subcomponent automatically set to "Frequency Status"?
>  * Is the status message automatically generated by FrequencyStatusParam()?

Yes I think so.

>  * What should we do for open() errors?

updater_.broadcast allow to send a general error message for a component.
It should be enough to do that.

Regarding the tolerance in the diagnostic, I do not have any better
strategy in mind.
If you look at prosilica node that we should probably try to mimic:
https://code.ros.org/svn/ros-pkg/stacks/prosilica_driver/trunk/prosilica_camera/src/nodes/prosilica_node.cpp

if you grep diagnostic you will see that the threshold is hardcoded to
10%. It is not that nice but
providing the same level of feature than this node is IMHO a
reasonable objective in a first time.

Regarding the Format7 modes either we put a very low threshold (around
1fps) to make sure that the node is still
grabbing something or we just disable the test.

-- 
Thomas Moulard