[ros-users] call for an official ROS USB camera package

[James Ronald]

The PlayStation Eye is supposed to be a pretty descent speed (125 fps)
USB camera.  I know it's quite popular with the OpenCV folks and those
building multimedia interactive coffee tables.


On Mon, Jun 6, 2011 at 7:38 PM, Jack O'Quin <jack.oquin at gmail.com> wrote:
> On Mon, Jun 6, 2011 at 5:33 PM, Eric Perko <wisesage5001 at gmail.com> wrote:
>> On Mon, Jun 6, 2011 at 6:03 PM, Bill Morris <morris at ee.ccny.cuny.edu> wrote:
>>>
>>> On Mon, 2011-06-06 at 14:53 -0700, Patrick Mihelich wrote:
>>> > On Mon, Jun 6, 2011 at 2:26 PM, Bill Morris <morris at ee.ccny.cuny.edu>
>>> > wrote:
>>> >         > > I would like to see a system for storing camera
>>> >         calibrations based on
>>> >
>>> >         > The camera_info_manager URL supports any naming scheme
>>> >         desired.
>>> >
>>> >
>>> > In the unstable version of the OpenNI (Kinect) drivers, I've tried out
>>> > a system for storing calibrations based on serial number. You can pass
>>> > in a URL containing "%s", and the driver replaces that with the camera
>>> > name. The camera name is of the form "[rgb|depth]_[serial#]". For
>>> > example, if you give the driver a URL "/tmp/calibration_%s.yaml" it
>>> > might expand to "/tmp/calibration_depth_B00362708888047B.yaml". This
>>> > makes working with multiple Kinects a lot easier.
>>>
>>> That reminds me that in testing I found that the calibrations are
>>> different at different resolutions and frame rates.
>>>
>>> At least one Logitech camera has a "feature" that it changes it's FOV at
>>> different frame rates.
>>>
>>> So something like this may be more appropriate
>>> ~/.ros/calibration/usb_camera-046d08210001-640x480 at 30.yaml
>>
>> This sounds like a motivation for adding more substitution args to the URL.
>> For example, "/tmp/calibration_$NAME_$RESOLUTION_$FRAMERATE.yaml". However,
>> I feel like this could expand quickly (for example, what about some value
>> for focus for variable focus cameras?), so it could get tricky unless there
>> is a small set of parameters that influence when we can use a given
>> calibration or not. Remember that for each of these substitution args, we
>> would have to add a getter/setter function to the camera_info_manager API.
>> For those cameras that change FOV based on framerate, can the FOV value be
>> read out? Seems like framerate in general shouldn't affect when you can use
>> a given calibration, so it would be better to record the FOV itself. And
>> obviously none of this really helps with things like PointGrey firewire
>> cameras that have separate lenses that can be manually adjusted for things
>> like focus, so we need to not break those use cases of camera_info_manager.
>> So is there a small set of parameters that determine when a calibration is
>> valid? If so, what are they?
>
> We can gradually add substitution variables as their usefulness is
> demonstrated. Resolution is easy to justify. Frame rate may be too
> specific to one camera model to justify a general solution.
>
> Things like Focus and Zoom are worth considering if anyone can come up
> with reasonable device-independent encodings.
>
>> As far as changing the default directory to $ROS_HOME from /tmp, that seems
>> fine with me. We do still need to preserve the setting of a directory from
>> launch files - for example, I would probably set my directories up like
>> "$(find
>> my_robot_configuration_package)/camera_calibrations/$NAME/$RESOLUTION.yaml"
>> and keep that checked into my VCS. Let's not "streamline away" a feature
>> that some people (like myself) actually like :)
>
> I also find it helpful to store calibration files in SVN. The
> "package://my_robot_configuration_package/..." syntax is useful for
> that. That should work fine with the substitution variables proposed.
>
>
> There have been several good suggestions today for extending the
> camera_info_manager URL in useful ways. To get them into Electric
> Emys, we need to have an API review right away and get these ideas
> nailed down. I will go ahead with that, unless there are objections.
> --
>  joq
> _______________________________________________
> ros-users mailing list
> ros-users at code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>