<div dir="ltr"><div>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).<br>
<br>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.<br>
<br></div>Imaging performance is fine, though.<br><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Feb 18, 2014 at 3:59 PM, Kelsey Hawkins <span dir="ltr"><<a href="mailto:kphawkins@gmail.com" target="_blank">kphawkins@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">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? </p>
<span class="HOEnZb"><font color="#888888">
<p dir="ltr">-Kelsey</p></font></span><div class="HOEnZb"><div class="h5">
<div class="gmail_quote">On Dec 5, 2013 3:07 PM, "Tully Foote" <<a href="mailto:tfoote@osrfoundation.org" target="_blank">tfoote@osrfoundation.org</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Dec 4, 2013 at 9:00 AM, Isaac Isao Saito <span dir="ltr"><<a href="mailto:130s@lateeye.net" target="_blank">130s@lateeye.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"># Apologies if multiple posts come in; looks like I'm having trouble<br>
in posting to ros-users with my other email account.<br>
<br>
Following Kevin Hallenbeck's offering, I suggest to borrow his<br>
repository to continue further discussion about unifying features that<br>
are distributed over multiple ROS packages.<br>
<br>
<a href="https://bitbucket.org/kmhallen/ueye/issue/7/merge-features-from-other-ueye-related-ros" target="_blank">https://bitbucket.org/kmhallen/ueye/issue/7/merge-features-from-other-ueye-related-ros</a><br>
<br>
Please note, with a risk of sounding contradictory, that I'm not<br>
forcing to merge multiple packages with similar features into a single<br>
package (if I was doing so, that would be a very good counter example<br>
of opensource advocate).<br></blockquote><div><br></div><div>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: <a href="http://ros-users.122217.n3.nabble.com/Digital-Camera-1394-in-ROS-td439620.html" target="_blank">http://ros-users.122217.n3.nabble.com/Digital-Camera-1394-in-ROS-td439620.html</a> and the results you can find in the camera1394 review pages: <a href="http://wiki.ros.org/camera1394/Reviews" target="_blank">http://wiki.ros.org/camera1394/Reviews</a></div>
<div><br></div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
If there's any good practice/mechanism in ROS or in opensource in<br>
general to avoid package-collision like this, I think more than a few<br>
of us would get interested in it (surprisingly Googling is sometimes<br>
not just enough).<br></blockquote><div><br></div><div>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. </div>
<div><br></div><div>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. </div>
<div><br></div><div>Tully</div><div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Thanks,<br>
Isaac<br>
<div><div><br>
On Fri, Nov 29, 2013 at 12:21 AM, Kevin Hallenbeck <<a href="mailto:kmhallen@oakland.edu" target="_blank">kmhallen@oakland.edu</a>> wrote:<br>
> I develop the 'ueye' package, but I haven't touched it in about six months.<br>
> It looks like each package has some strengths and weaknesses. I am willing<br>
> to work on a unified package for uEye cameras that would include all of the<br>
> features from these packages.<br>
><br>
> Thanks,<br>
> Kevin<br>
><br>
><br>
> On Thu, Nov 28, 2013 at 9:54 AM, Isaac Isao Saito<br>
> <<a href="mailto:iisaito@opensource-robotics.tokyo.jp" target="_blank">iisaito@opensource-robotics.tokyo.jp</a>> wrote:<br>
>><br>
>> ros-thusiasts,<br>
>><br>
>> for a camera called Ueye, I've seen at least 4 wiki pages for separate<br>
>> ROS packages that provides interface with the device.<br>
>><br>
>> <a href="http://wiki.ros.org/iri_ueye_camera" target="_blank">http://wiki.ros.org/iri_ueye_camera</a><br>
>> <a href="http://wiki.ros.org/ueye" target="_blank">http://wiki.ros.org/ueye</a><br>
>> <a href="http://wiki.ros.org/ueye_cam" target="_blank">http://wiki.ros.org/ueye_cam</a><br>
>> <a href="http://wiki.ros.org/ueyecamera" target="_blank">http://wiki.ros.org/ueyecamera</a><br>
>><br>
>> All of these are the result of great work of each developer. But<br>
>> wouldn't it be even more useful if we only have one?<br>
>><br>
>> # It'd be so for us, since one of the robots that our software<br>
>> (rtmros_nextage) supports comes with Ueye.<br>
>><br>
>> Thanks,<br>
>><br>
>> Isaac<br>
>> _______________________________________________<br>
>> ros-users mailing list<br>
>> <a href="mailto:ros-users@code.ros.org" target="_blank">ros-users@code.ros.org</a><br>
>> <a href="http://lists.ros.org/mailman/listinfo/ros-users" target="_blank">http://lists.ros.org/mailman/listinfo/ros-users</a><br>
><br>
><br>
><br>
> _______________________________________________<br>
> ros-users mailing list<br>
> <a href="mailto:ros-users@code.ros.org" target="_blank">ros-users@code.ros.org</a><br>
> <a href="http://lists.ros.org/mailman/listinfo/ros-users" target="_blank">http://lists.ros.org/mailman/listinfo/ros-users</a><br>
><br>
_______________________________________________<br>
ros-users mailing list<br>
<a href="mailto:ros-users@code.ros.org" target="_blank">ros-users@code.ros.org</a><br>
<a href="http://lists.ros.org/mailman/listinfo/ros-users" target="_blank">http://lists.ros.org/mailman/listinfo/ros-users</a><br>
</div></div></blockquote></div><br></div></div>
<br>_______________________________________________<br>
ros-users mailing list<br>
<a href="mailto:ros-users@code.ros.org" target="_blank">ros-users@code.ros.org</a><br>
<a href="http://lists.ros.org/mailman/listinfo/ros-users" target="_blank">http://lists.ros.org/mailman/listinfo/ros-users</a><br>
<br></blockquote></div>
</div></div><br>_______________________________________________<br>
ros-users mailing list<br>
<a href="mailto:ros-users@lists.ros.org">ros-users@lists.ros.org</a><br>
<a href="http://lists.ros.org/mailman/listinfo/ros-users" target="_blank">http://lists.ros.org/mailman/listinfo/ros-users</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br><div dir="ltr">Ingo Lütkebohle, Dr.-Ing.<br>Machine Learning and Robotics Lab, IPVS, Universität Stuttgart<br><a href="http://www.ipvs.uni-stuttgart.de/abteilungen/mlr/abteilung/mitarbeiter/Ingo.Luetkebohle" target="_blank">http://www.ipvs.uni-stuttgart.de/abteilungen/mlr/abteilung/mitarbeiter/Ingo.Luetkebohle</a><br>
+49-711-685-88350<br><br>PGP Fingerprint 3187 4DEC 47E6 1B1E 6F4F 57D4 CD90 C164 34AD CE5B</div>
</div>