call for an official ROS USB camera package

classic Classic list List threaded Threaded
28 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: call for an official ROS USB camera package

Bill Morris
On Mon, 2011-06-06 at 14:53 -0700, Patrick Mihelich wrote:

> On Mon, Jun 6, 2011 at 2:26 PM, Bill Morris <[hidden email]>
> 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/[hidden email]



_______________________________________________
ros-users mailing list
[hidden email]
https://code.ros.org/mailman/listinfo/ros-users
Reply | Threaded
Open this post in threaded view
|

Re: call for an official ROS USB camera package

Eric Perko
On Mon, Jun 6, 2011 at 6:03 PM, Bill Morris <[hidden email]> wrote:
On Mon, 2011-06-06 at 14:53 -0700, Patrick Mihelich wrote:
> On Mon, Jun 6, 2011 at 2:26 PM, Bill Morris <[hidden email]>
> 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/[hidden email]

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?

On Mon, 2011-06-06 at 14:53 -0700, Patrick Mihelich wrote:  
 
+1 on $ROS_HOME over /tmp. /tmp works, as long as you don't reboot :). Otherwise you have to know and remember to change the URL, which can lead to otherwise unnecessary launch file editing. Let's streamline that away.

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 :)

- Eric

_______________________________________________
ros-users mailing list
[hidden email]
https://code.ros.org/mailman/listinfo/ros-users
Reply | Threaded
Open this post in threaded view
|

Re: call for an official ROS USB camera package

Jack O'Quin
In reply to this post by Bill Morris
On Mon, Jun 6, 2011 at 4:26 PM, Bill Morris <[hidden email]> wrote:

> On Fri, 2011-06-03 at 20:33 -0500, Jack O'Quin wrote:
>> Not being a USB camera user, myself, I am not sure what the status of
>> the various driver packages are.
>>
>> Is there one particular version most people use?
>
> I have been using a customized version of usb_cam
> http://www.ros.org/wiki/usb_cam but I think Ken's uvc_camera is a bit
> further along. http://www.ros.org/wiki/uvc_camera
>
> There may be a license issue with the GPL vs BSD.

That issue arose with camera1394 when I made a nodelet implementation
for Diamondback. For that package, we asked all the contributors to
agree to changing the license to LGPL, which seems adequate.

BSD would be best.

>> > I would like to see a system for storing camera calibrations based on
>> The camera_info_manager URL supports any naming scheme desired.
>
> I would like to propose that cameras that can not store calibrations in
> memory store the calibrations in $ROS_HOME/calibration/driver-id.cal
>
> For a USB camera the id could be constructed from the VID/PID/Serial
> number to create a mostly unique identifier.
>
>  idVendor           0x046d Logitech, Inc.
>  idProduct          0x0821
>  iSerial                 1
>
> ~/.ros/calibration/usb_camera-046d08210001.cal

If no ~camera_info_url is specified, we currently use
"file:///tmp/calibration_${CAMERA_NAME}.yaml".

$ROS_HOME would probably be a better choice than /tmp. It's a small
API change, but unlikely to cause much grief.

I wouldn't want to override a user-specified URL, however.
--
 joq
_______________________________________________
ros-users mailing list
[hidden email]
https://code.ros.org/mailman/listinfo/ros-users
Reply | Threaded
Open this post in threaded view
|

Re: call for an official ROS USB camera package

Jack O'Quin
In reply to this post by Patrick Mihelich
On Mon, Jun 6, 2011 at 4:53 PM, Patrick Mihelich
<[hidden email]> wrote:

> On Mon, Jun 6, 2011 at 2:26 PM, Bill Morris <[hidden email]> 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's trivial to implement in a driver, but it would be nice to push the
> name substitution down into CameraInfoManager just to ensure a consistent
> API across camera drivers. In other words, have this just work:
>
> info_manager.setCameraName("depth_B00362708888047B");
> info_manager.loadCameraInfo("/tmp/calibration_%s.yaml");
>
> I'm not attached to "%s", maybe something like "$NAME" would be clearer.

It is a good idea to add this feature in a camera_info_manager, which
is common to many drivers.

$NAME is more flexible if we decide to add other substitution
variables. Maybe ${NAME} to make parsing simpler and substitution more
flexible.

>> I would like to propose that cameras that can not store calibrations in
>> memory store the calibrations in $ROS_HOME/calibration/driver-id.cal
>
> +1 on $ROS_HOME over /tmp. /tmp works, as long as you don't reboot :).
> Otherwise you have to know and remember to change the URL, which can lead to
> otherwise unnecessary launch file editing. Let's streamline that away.

OK with me.

--
 joq
_______________________________________________
ros-users mailing list
[hidden email]
https://code.ros.org/mailman/listinfo/ros-users
Reply | Threaded
Open this post in threaded view
|

Re: call for an official ROS USB camera package

Jack O'Quin
In reply to this post by Eric Perko
On Mon, Jun 6, 2011 at 5:33 PM, Eric Perko <[hidden email]> wrote:

> On Mon, Jun 6, 2011 at 6:03 PM, Bill Morris <[hidden email]> wrote:
>>
>> On Mon, 2011-06-06 at 14:53 -0700, Patrick Mihelich wrote:
>> > On Mon, Jun 6, 2011 at 2:26 PM, Bill Morris <[hidden email]>
>> > 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/[hidden email]
>
> 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
[hidden email]
https://code.ros.org/mailman/listinfo/ros-users
Reply | Threaded
Open this post in threaded view
|

Re: call for an official ROS USB camera package

Jack O'Quin
On Mon, Jun 6, 2011 at 6:38 PM, Jack O'Quin <[hidden email]> wrote:

> 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.

I created a review page for this discussion. Please add yourself to
the list of reviewers and post your comments and ideas. I'd like this
resolved as quickly as possible, since many things depend on the
image_common stack and Electric Emys is not far off.

http://www.ros.org/wiki/camera_info_manager/Reviews/2011-06-06_API_Review

--
 joq
_______________________________________________
ros-users mailing list
[hidden email]
https://code.ros.org/mailman/listinfo/ros-users
Reply | Threaded
Open this post in threaded view
|

Re: call for an official ROS USB camera package

James Ronald
In reply to this post by Jack O'Quin
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 <[hidden email]> wrote:

> On Mon, Jun 6, 2011 at 5:33 PM, Eric Perko <[hidden email]> wrote:
>> On Mon, Jun 6, 2011 at 6:03 PM, Bill Morris <[hidden email]> wrote:
>>>
>>> On Mon, 2011-06-06 at 14:53 -0700, Patrick Mihelich wrote:
>>> > On Mon, Jun 6, 2011 at 2:26 PM, Bill Morris <[hidden email]>
>>> > 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/[hidden email]
>>
>> 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
> [hidden email]
> https://code.ros.org/mailman/listinfo/ros-users
>
_______________________________________________
ros-users mailing list
[hidden email]
https://code.ros.org/mailman/listinfo/ros-users
Reply | Threaded
Open this post in threaded view
|

Re: call for an official ROS USB camera package

Jack O'Quin
In reply to this post by Jack O'Quin
We're coming up on feature freeze for Electric in a couple of weeks.
Should we take this off the list of possible new features for that
distribution?

Maybe the current USB camera drivers are sufficient.
--
 joq
_______________________________________________
ros-users mailing list
[hidden email]
https://code.ros.org/mailman/listinfo/ros-users
12