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
(text/plain)