[ros-users] Multiple packages with similar functionalities (ueye camera)

Thu Feb 20 11:50:02 UTC 2014

We've been using the USB3 CP model and had some issues. Part of the reason
is that it doesn't fit my particular use case, and another part of the
reason is that we had trouble with USB stability (which may or may not be
caused by the PC we connected them to, it is unclear).

Regarding my use case: I want YUV data (because I'm encoding the data into
a video stream), and the ueye can't deliver that natively, conversion is
done on the PC, and it is *really* slow if you use their libs, so I had to
roll my own. If you only want RGB, that works better, but be advised that
debayering is also done on the PC-side. I am used to work with cameras from
other manufacturers, e.g. PtGrey, which provide both of these functions in
camera, so I wasn't happy about that.

Imaging performance is fine, though.

On Tue, Feb 18, 2014 at 3:59 PM, Kelsey Hawkins <kphawkins at gmail.com> wrote:

> Since it seems like there is growing community around this sensor, I'm
> curious if people have been generally pleased with the ueye cameras. What
> is the ballpark cost/model people are typically using and would they
> recommend?
>
> -Kelsey
> On Dec 5, 2013 3:07 PM, "Tully Foote" <tfoote at osrfoundation.org> wrote:
>
>>
>>
>>
>> On Wed, Dec 4, 2013 at 9:00 AM, Isaac Isao Saito <130s at lateeye.net>wrote:
>>
>>> # Apologies if multiple posts come in; looks like I'm having trouble
>>> in posting to ros-users with my other email account.
>>>
>>> Following Kevin Hallenbeck's offering, I suggest to borrow his
>>> repository to continue further discussion about unifying features that
>>> are distributed over multiple ROS packages.
>>>
>>>
>>> https://bitbucket.org/kmhallen/ueye/issue/7/merge-features-from-other-ueye-related-ros
>>>
>>> Please note, with a risk of sounding contradictory, that I'm not
>>> forcing to merge multiple packages with similar features into a single
>>> package (if I was doing so, that would be a very good counter example
>>> of opensource advocate).
>>>
>>
>> It's actually a good thing to consolidate efforts and work together to
>> merge implementations if they are compatible. This allows greater
>> productivity through collaboration and deduplicates efforts of maintaining
>> multiple copies in parallel.  The beauty of open source is that if you feel
>> that you need a different direction you can again fork the development. But
>> most of the time for things like this driver it is in everyone's interest
>> to have a single good driver than have many mostly functional drivers.  An
>> example very close to this that went very well was the effort to
>> consolidate the various firewire camera drivers.  After a long discussion
>> on the mailing list Jack O'Quin took the lead and offered to consolidate
>> the drivers.  The first thread was here:
>> http://ros-users.122217.n3.nabble.com/Digital-Camera-1394-in-ROS-td439620.html and
>> the results you can find in the camera1394 review pages:
>> http://wiki.ros.org/camera1394/Reviews
>>
>>
>>
>>
>>
>>>
>>> If there's any good practice/mechanism in ROS or in opensource in
>>> general to avoid package-collision like this, I think more than a few
>>> of us would get interested in it (surprisingly Googling is sometimes
>>> not just enough).
>>>
>>
>> The most important thing to do is to communicate effectively.  Publicly
>> releasing and indexing software is the most critical element of this.
>> Usually if there is an open source implementation with a compatible license
>> people will use it if they find it. If it is not feature complete for their
>> use cases they then have the choice to extend the existing capabilities or
>> to develop the whole thing again from scratch.  Most will usually extend
>> the capability, and if it's easy enough contribute it back.
>>
>> So the most important thing to do is to make sure to add your packages to
>> the documentation index with appropriate keywords. If a package is not
>> adaquately documented it is as almost as good as not released. Users won't
>> take the time to dig into a package which might do what they want and might
>> not. The other important thing to keep in mind is that people will extend
>> packages to fit their use cases.  It is important to make it easy to
>> contribute back. If it is hard to contribute back the user extending the
>> package both has to do the work to extend it as well as the extra work to
>> contribute back.  In the long run they need to believe they will save
>> time/energy by contributing back to the project.
>>
>> Tully
>>
>>
>>>
>>> Thanks,
>>> Isaac
>>>
>>> On Fri, Nov 29, 2013 at 12:21 AM, Kevin Hallenbeck <kmhallen at oakland.edu>
>>> wrote:
>>> > I develop the 'ueye' package, but I haven't touched it in about six
>>> months.
>>> > It looks like each package has some strengths and weaknesses. I am
>>> willing
>>> > to work on a unified package for uEye cameras that would include all
>>> of the
>>> > features from these packages.
>>> >
>>> > Thanks,
>>> > Kevin
>>> >
>>> >
>>> > On Thu, Nov 28, 2013 at 9:54 AM, Isaac Isao Saito
>>> > <iisaito at opensource-robotics.tokyo.jp> wrote:
>>> >>
>>> >> ros-thusiasts,
>>> >>
>>> >> for a camera called Ueye, I've seen at least 4 wiki pages for separate
>>> >> ROS packages that provides interface with the device.
>>> >>
>>> >> http://wiki.ros.org/iri_ueye_camera
>>> >> http://wiki.ros.org/ueye
>>> >> http://wiki.ros.org/ueye_cam
>>> >> http://wiki.ros.org/ueyecamera
>>> >>
>>> >> All of these are the result of great work of each developer. But
>>> >> wouldn't it be even more useful if we only have one?
>>> >>
>>> >> # It'd be so for us, since one of the robots that our software
>>> >> (rtmros_nextage) supports comes with Ueye.
>>> >>
>>> >> Thanks,
>>> >>
>>> >> Isaac
>>> >> _______________________________________________
>>> >> ros-users mailing list
>>> >> ros-users at code.ros.org
>>> >> http://lists.ros.org/mailman/listinfo/ros-users
>>> >
>>> >
>>> >
>>> > _______________________________________________
>>> > ros-users mailing list
>>> > ros-users at code.ros.org
>>> > http://lists.ros.org/mailman/listinfo/ros-users
>>> >
>>> _______________________________________________
>>> ros-users mailing list
>>> ros-users at code.ros.org
>>> http://lists.ros.org/mailman/listinfo/ros-users
>>>
>>
>>
>> _______________________________________________
>> ros-users mailing list
>> ros-users at code.ros.org
>> http://lists.ros.org/mailman/listinfo/ros-users
>>
>>
> _______________________________________________
> ros-users mailing list
> ros-users at lists.ros.org
> http://lists.ros.org/mailman/listinfo/ros-users
>
>

-- 
Ingo Lütkebohle, Dr.-Ing.
Machine Learning and Robotics Lab, IPVS, Universität Stuttgart
http://www.ipvs.uni-stuttgart.de/abteilungen/mlr/abteilung/mitarbeiter/Ingo.Luetkebohle
+49-711-685-88350

PGP Fingerprint 3187 4DEC 47E6 1B1E 6F4F  57D4 CD90 C164 34AD CE5B
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20140220/ab7a6641/attachment.html>