[ros-users] Digital Camera 1394 in ROS?

Jack O'Quin jack.oquin at gmail.com
Sat Mar 20 00:49:33 UTC 2010

On Fri, Mar 19, 2010 at 12:46 PM, Blaise Gassend
<blaise at willowgarage.com> wrote:

>> My idea was to use the parameter server for this. Persistent
>> calibration then becomes a matter of using "rosparam dump" and
>> "rosparam load" to save and restore the data. This is useful for much
>> more than just cameras. Many servo devices require calibration. It
>> could also be helpful for parameters tuned via machine learning.
>> This approach works cleanly and transparently in a distributed system
>> environment.
>> Nothing in CameraInfo is too high-bandwidth for the parameter server
>> to become a bottleneck. The camera driver would simply read its
>> parameters as usual. If the CameraInfo is not available it publishes a
>> default setting. (Rviz and other tools should handle that correctly --
>> it's not an error, just a new, uncalibrated device.) When calibration
>> runs, it calls SetCameraInfo. The current instance of the driver
>> stores the data, also writing them back to the parameter server.
>> I like this approach better than the file manager you suggested. But,
>> perhaps there are issues I have not considered. Further suggestions
>> and comments are welcome.
> The thing I don't like about the parameter server approach is that you
> have to manually do the rosparam dump after you have calibrated the
> camera. Your launch file will then probably be loading those dumped
> parameters from a well-known location. So you still have the file, but
> now you additionally need to be taking some extra steps when you do your
> calibration (which in some cases is a good thing).

You are right. File writing is simply pushed to another time and
place. I'd thought about that already. It has to be done somewhere.

Adding an additional step for the user is a more serious problem.

> Perhaps the right answer is for the CameraInfoManager class to be able
> to handle files, parameters and flash, using a url to determine which
> one it wants. In the case of flash, it does a callback to the driver,
> which takes whatever steps are needed to store to flash.
> file:///etc/ros/camera_info/left_forearm.yaml
> parameter:///~camera_info
> flash:///1
> This way even for cameras that have flash, the user has the option of
> picking a different source.

That is certainly a more flexible approach.

I still think saving calibration data is a more general problem than
just cameras. Maybe the parameter server needs a "save persistent
data" request that could be invoked by any node after its calibration
is updated.

I don't know if there have been any discussions along those lines
within WG. Nor do I know if there is any prospect of implementing a
new feature at that level.

So, I'll defer to your judgement about the CameraInfoManager approach.

Since camera1394 is already experimental, I propose to create a
CamerInfoManager{cpp,h} inside it, done so it can easily be moved to a
separate package if it proves generally useful. That way I can play
around with it internally at first and need not introduce an
additional package dependency until it is ready.

More information about the ros-users mailing list