Jack, we really appreciate it if you take on something like this.  The
cameras on PR2 are now ethernet-based, so we haven't been as
conscientious as we should be for IEEE1394 cameras.  If the driver
could fit in with the image_pipeline stack, that would make it very
useful, e.g., for doing stereo.

Cheers --Kurt

On Wed, Mar 10, 2010 at 2:36 PM, Jack O'Quin <jack.oquin@gmail.com> wrote:
> 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
> _______________________________________________
> ros-users mailing list
> ros-users@code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>