Given that the camera1394 driver is based off my local ROS node, I'm 
definitely using it to update my very similar swissranger node for 
public use.  I especially want to be able to use testing of the 
camera1394 node to inform changes to the SR node, as I doubt there will 
be as many testers for the SR node.

Thanks for the help and advice.

Blaise Gassend wrote:
> The calibration would be done at a higher level, and the parameters
> passed back to the camera driver whose responsibility it is to publish
> them. So if you just output default values, people will have a hard time
> using the device as a camera.
> 
> You could look at the CameraInfoManager in camera1394. It would be easy
> for you to pull into your driver, and would allow people to calibrate
> the camera just like any other camera. At some point I want to move that
> functionality into some common package, but I haven't had a chance yet.
> 
> Blaise
> 
> On Tue, 2010-03-30 at 11:12 -0500, Patrick Beeson wrote:
>> The swissranger is calibrated at the factory.  They do not provide the 
>> internal optical parameters they use when getting 3D points from 2D 
>> images.  If one wanted to rectify the 2D depth or intensity images, one 
>> could run a checkerboard calibration from the intensity image (I've done 
>> this).  I'm assuming this would be done at a higher level than the 
>> camera communication driver.   So, for now, camera parameters will need 
>> to be set to defaults.
>>
>>
>> Blaise Gassend wrote:
>>> If it looks like a dog, and barks like a dog, why not put it in
>>> dog_experimental?
>>>
>>> So if you are publishing an image and a camera info with the standard
>>> directory structure, it sounds like a good candidate for
>>> camera_drivers_experimental.
>>>
>>> How are you dealing with calibration?
>>>
>>> Blaise
>>>
>>> On Tue, 2010-03-30 at 09:44 -0500, Patrick Beeson wrote:
>>>> I think I'll have some time later this week to update my ROS Swissranger 
>>>> 3000/4000 driver with appropriate image_proc info.  Radu and I had 
>>>> discussed this replacing his older 3K node, as this is basically a port 
>>>> of that to work with the newer Mesa Imaging API.
>>>>
>>>> I think having this driver in the camera_drivers_experimental would be 
>>>> fine, as the device is essentially a camera that publishes multiple 2D 
>>>> images along with a point cloud (I'll make this a runtime option).  Any 
>>>> objections to locating a 3D flash lidar driver in the 
>>>> camera_drivers_experimental stack?
>>>>
>>>>
>>>> Patrick Beeson
>>>> _______________________________________________
>>>> ros-users mailing list
>>>> ros-users@code.ros.org
>>>> https://code.ros.org/mailman/listinfo/ros-users
>>>
>>> _______________________________________________
>>> ros-users mailing list
>>> ros-users@code.ros.org
>>> https://code.ros.org/mailman/listinfo/ros-users
>> _______________________________________________
>> ros-users mailing list
>> ros-users@code.ros.org
>> https://code.ros.org/mailman/listinfo/ros-users
> 
> 
> _______________________________________________
> ros-users mailing list
> ros-users@code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users