On Thu, Sep 22, 2011 at 11:25 AM, Jack O'Quin <
jack.oquin@gmail.com> wrote:
> In summary, the more I look the less common code I see. It may be
> possible to create a common service for these kinds of parameters, but
> that looks difficult. I suspect forking these files to the USB driver
> and modifying them to work with the appropriate interfaces would
> actually be easier to do and to maintain.
>
Yeah, unifying parameter behavior over different cameras at the code level
is hard. They all have different features, and even the features they do
share (gain, exposure, etc) tend to have different units, ranges and
interpretations. The common ground ends up being minimal enough that it's
not worth bothering.
In principle we could legislate some common ground by specifying a standard
behavioral model in ROS for camera features, but that's a huge can of worms.
See for example the GenICam Standard Features Naming Convention
(PDF<
http://www.emva.org/cms/upload/Standards/GenICam_Downloads/GenICam_SFNC_1_5_1.pdf>),
which is the most thorough attempt at solving that problem I've seen.
That leaves the problem of modifying both drivers as
> dynamic_reconfigure gradually evolves better support for
> device-dependent parameters. Despite that, I recommend forking the
> code, not creating a common parameter package.
>
I agree. We can at least strive for consistency across camera drivers though
- using the same parameter names and options whenever possible. For example,
in prosilica_camera the auto_XXX parameters are just booleans, whereas in
camera1394 they're an enumeration with several possible states. Probably
prosilica_camera should change - the hardware supports at least OnePush as
well. Binning & ROI parameters preferably should conform to the REP 104
behavior.
We should have an advisory wiki page that lists typical parameter names and
behavior for camera drivers. We can update that over time as we find more
things to agree on.
Cheers,
Patrick
On Thu, Sep 22, 2011 at 11:25 AM, Jack O'Quin <
jack.oquin@gmail.com> wrote:
In summary, the more I look the less common code I see. It may be
possible to create a common service for these kinds of parameters, but
that looks difficult. I suspect forking these files to the USB driver
and modifying them to work with the appropriate interfaces would
actually be easier to do and to maintain.Yeah, unifying parameter behavior over different cameras at the code level is hard. They all have different features, and even the features they do share (gain, exposure, etc) tend to have different units, ranges and interpretations. The common ground ends up being minimal enough that it's not worth bothering.
In principle we could legislate some common ground by specifying a standard behavioral model in ROS for camera features, but that's a huge can of worms. See for example the GenICam Standard Features Naming Convention (PDF), which is the most thorough attempt at solving that problem I've seen.
That leaves the problem of modifying both drivers as
dynamic_reconfigure gradually evolves better support for
device-dependent parameters. Despite that, I recommend forking the
code, not creating a common parameter package.I agree. We can at least strive for consistency across camera drivers though - using the same parameter names and options whenever possible. For example, in prosilica_camera the auto_XXX parameters are just booleans, whereas in camera1394 they're an enumeration with several possible states. Probably prosilica_camera should change - the hardware supports at least OnePush as well. Binning & ROI parameters preferably should conform to the REP 104 behavior.
We should have an advisory wiki page that lists typical parameter names and behavior for camera drivers. We can update that over time as we find more things to agree on.Cheers,Patrick
(text/plain)