On Wed, Mar 10, 2010 at 11:43 AM, Ken Conley <kwc@willowgarage.com> wrote:
> From Rosen
>>If it makes a big difference for your team that the cameradc1394
>>resided on WillowGarage's servers rather than sourceforge's, then I'm
>>sure WillowGarage would be happy to host it.
>
> From  Jack O'Quin
>> Ideally, it should be part of the camera_drivers stack, but that's
>> another discussion.  :-)
>
> If people in the community are interested in working together to
> develop a low-dependency, fully-featured 1394 driver, we're happy to
> host it on ros-pkg and provide release support, including getting it
> into camera_drivers when it is stable. We're also happy to help people
> use it where-ever it lives. The reason it was removed from ros-pkg
> earlier was that WG couldn't maintain a driver for a device we weren't
> using.
>
> We setup the ros-pkg repository separately from wg-ros-pkg so that it
> could be community-owned, rather than the expression of a single
> institution. That said, it's always a careful balance; the federated
> model of ROS repositories is very important to us. It allows, for
> example, people to start building functionality on top of Brown's Nao
> and Create drivers, without WG acting as a gatekeeper. We don't want
> to be in the position of suggesting that all commonly used packages be
> moved to ros-pkg, and we've built tools like rosbrowse and roslocate
> so that users don't have to care where a package is stored. Although
> duplication can be confusing, it allows better packages to come along
> (e.g. Rosen's cameradc1394) and replace one's that aren't being as
> well-maintained.

I fully agree about the advantages of the "federated" package development.

My feeling is that the ROS community does need a simple DC1394 driver
that supports the same interface as the other camera drivers and can
be used interchangeably with higher level packages (calibration,
viewing, opencv, etc).  Support for this particular device is
sufficiently important to be an exception to the general rule of
federated development. Since so many people need it, there should be a
well-supported version in ros-pkg. If others want to build value-added
alternatives (with built-in calibration and other benefits), that's
fine.

I've been doing open source development for many years. I try to
contribute to the community, and not just whine about things I don't
like (though that can be fun sometimes). So, I'll volunteer to
shepherd such a package through the review, documentation, testing and
maintenance process with a goal of being accepted to the
camera_drivers package when it's ready.

If someone else would like to do that, go ahead. I'll help. It won't
hurt my feelings at all. Most of the people on this list probably know
more about digital cameras than I do. While probably competent to do
the documentation, packaging and testing, I'll need guidance and
feedback from many of you on how to handle various technical
trade-offs.

As mentioned earlier, we have enough cameras and people working with
them at UT Austin to provide regression testing for future ROS
releases. Willow Garage is right to be concerned about that
requirement. It will be a lot more work in the long run than just
writing some code. Since I need to be doing much of that for the
foreseeable future anyway, we might as well make it official.

The first task would be to select which driver to use as a starting
point. The three that were mentioned today are: (1) Rosen Diankov's
cameradc1394 from cmu-ros-pkg; (2) Patrick Beeson's ROS port of the
Player 1394 camera driver; and (3) the probe driver from brown-ros-pkg
mentioned by Trevor Jay. Perhaps there are other candidates as well.
All seem to offer some advantages, and to need additional work to fit
the proposed niche.
-- 
 joq