Favorite 3D Camera for ROS-Industrial Users?

[Hemes]

Hello all,

I am looking to build a smallish vision system (2-5 cameras; one maybe on the robot?) for my ROS development efforts and was wondering if there was a favorite or goto 3D camera within the ROS-Industrial community.

I currently have two Kinect V2's and got them going in ROS awhile back but haven't checked out the driver's progress since then but it seems really active.  I think I would like something a bit more industrially hardened if possible.  I was checking out the Argos3D P100 (for its industrial nature) or even some Intel RealSense cameras (really cheap but always out of stock) but ultimately whatever I get I would like to have solid ROS integration.  Any comments or suggestions?

Thanks!

Brett

[Hvass, Paul B.]

This is the topic of the ROS-I blog post tomorrow. We will give specs for 8 different 3D sensors w ROS drivers. Paul

Sent from my Verizon Wireless 4G LTE DROID

--
You received this message because you are subscribed to the Google Groups "swri-ros-pkg-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to swri-ros-pkg-d...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Tom Panzarella]

Hi Brett,

I am not sure what Paul has in store for the ROS-I blog. Whatever it is,
I'm sure it will be informative. FWIW, I have been using and really like
the IFM O3D303: https://www.ifm.com/ifmus/web/pmain020_020_010.htm I am
a bit biased regarding its ROS support (i.e., I think it is really good)
because I am the author of the drivers:

C++ driver: https://github.com/lovepark/libo3d3xx
ROS wrapper: https://github.com/lovepark/o3d3xx-ros

I have been building production systems with this sensor for over a year
now and it has proven very reliable. It is based on the PMD imager which
uses phase-shifted time-of-flight. There are a ton of knobs to turn on
the sensor to tune it for your application -- it is not as straight
forward as using a structured light sensor like the PrimeSense but
produces very nice images once properly tuned. This same imaging
technology is the basis for Project Tango's depth sensor -- if that
means anything to you. IFM packages it up into a robust industrial
form-factor. Another really nice aspect of this camera is that you can
run your own OEM algorithms directly on the camera's internal Linux
computer (based on a Quad Core ARM iMX6 from Freescale). The on-camera
"runtime" is actually the above listed github repos, so, anything you
develop off-board using those libraries should port directly down to the
camera hardware if that works for your use case.

Either way, I do not work for IFM but I really like the hardware and
have built the core open-source software for this sensor. It is in use
in production at many industrial/robotics companies. So, I'm happy to
help/answer any questions you may have if you decide to use this
particular device. My direct email is available in the README's of the
github repos above.

Best,
Tom

On 01/14/2016 09:56 PM, Hvass, Paul B. wrote:
> This is the topic of the ROS-I blog post tomorrow. We will give specs
> for 8 different 3D sensors w ROS drivers. Paul
>

> /Sent from my Verizon Wireless 4G LTE DROID/

> On Jan 14, 2016 8:36 PM, Hemes <brett...@gmail.com> wrote:
>
> Hello all,
>
> I am looking to build a smallish vision system (2-5 cameras; one
> maybe on the robot?) for my ROS development efforts and was
> wondering if there was a favorite or goto 3D camera within the
> ROS-Industrial community.
>
> I currently have two Kinect V2's and got them going in ROS awhile
> back but haven't checked out the driver's progress since then but it
> seems really active. I think I would like something a bit more
> industrially hardened if possible. I was checking out the Argos3D
> P100 (for its industrial nature) or even some Intel RealSense
> cameras (really cheap but always out of stock) but ultimately
> whatever I get I would like to have solid ROS integration. Any
> comments or suggestions?
>
> Thanks!
> Brett
>
> --
> You received this message because you are subscribed to the Google
> Groups "swri-ros-pkg-dev" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to swri-ros-pkg-d...@googlegroups.com

> <mailto:swri-ros-pkg-d...@googlegroups.com>.

> For more options, visit https://groups.google.com/d/optout.
>

> --
> You received this message because you are subscribed to the Google
> Groups "swri-ros-pkg-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to swri-ros-pkg-d...@googlegroups.com

> <mailto:swri-ros-pkg-d...@googlegroups.com>.

[Shaun Edwards]

Brett,

I've used Tom's driver.  From a software perspective, Tom's driver is one of the better ones that I have seen.  It worked out of the box, and when I did run in to issues (operator error), Tom was very responsive.

-Shaun

To unsubscribe from this group and stop receiving emails from it, send an email to swri-ros-pkg-d...@googlegroups.com.

[Hemes]

Awesome!  Thanks for all the info.  I just ordered a set of the IFM camera's and look forward to testing them out.  One feature I noticed that I am particularly excited about is the hardware chaining capability to avoid cross-camera interference.  We have had issues with this in the past using the Kinects (although we never tried the vibration trick...).

Brett

>     <mailto:swri-ros-pkg-dev+unsub...@googlegroups.com>.

>     For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google
> Groups "swri-ros-pkg-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to swri-ros-pkg-d...@googlegroups.com

> <mailto:swri-ros-pkg-dev+unsub...@googlegroups.com>.

[Tom Panzarella]

On 01/19/2016 09:59 AM, Hemes wrote:
> Awesome! Thanks for all the info. I just ordered a set of the IFM
> camera's and look forward to testing them out. One feature I noticed
> that I am particularly excited about is the hardware chaining capability
> to avoid cross-camera interference. We have had issues with this in the
> past using the Kinects (although we never tried the vibration trick...).
>

Brett,

Section 7.2.2 of this PDF link should help you with setting up this H/W
chaining: http://www.ifm.com/mounting/706398UK.pdf

Also, we have a current issue on our issue tracker (opened a few days
ago) where we are discussing this issue specifically for another user:

https://github.com/lovepark/libo3d3xx/issues/38

Hope these links come in handy for you.

Best,
Tom

[philip...@gmail.com]

Hi everybody,

I also tested the IFM camera with Tom's driver and it worked really well (the driver that is) .

Just a question for others who have used it this camera, when I tested it about 4 months ago, the camera itself produced point clouds that suffered from mixed pixel effect i.e. discontinuities in the scene led to a series of false positives. For me this was a problem that I couldn't filter without loosing valuable information.

Philip

[Tom Panzarella]

Hi Philip,

I am not sure how severe the mixed/flying pixel effect is that you are
seeing. But, for what its worth, I have had nice success using the IFM
camera / PMD chip with the PCL statistical outlier filter to clean up
flying pixels. You may need to tune it a bit, but, it does a nice job
albeit at the expense of CPU cycles (not sure how performance sensitive
you are).

Here is a link:
http://pointclouds.org/documentation/tutorials/statistical_outlier.php

I hope that helps.

Best,
Tom

> --
> You received this message because you are subscribed to the Google
> Groups "swri-ros-pkg-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to swri-ros-pkg-d...@googlegroups.com

> <mailto:swri-ros-pkg-d...@googlegroups.com>.

[philip...@gmail.com]

Hi Tom,

Thanks for the tip. I will try it next time I have the camera at hand.

I have two comments, firstly the version IFM I used had a window of 176*132 pixels I'm a litte worried about the resolution after filtering (compared to the kinect for example 640*480). Secondly, the flying pixels weren't just "lone" pixels floating in space but rather a continuous band from the foregraound object to the background object so it might be more difficult to filter. Anyway I'll try and post my results.

Philip

> <mailto:swri-ros-pkg-dev+unsub...@googlegroups.com>.

[Tom Panzarella]

On 02/08/2016 03:55 AM, philip...@gmail.com wrote:
>
> I have two comments, firstly the version IFM I used had a window of
> 176*132 pixels I'm a litte worried about the resolution after filtering
> (compared to the kinect for example 640*480).

The O3D has two imager configurations available. A ~23k pixel imager,
132 x 176, the default and also a ~100k pixel imager, 264 x 352. The
latter may give you the pixel density you are looking for. Switching
between the two configurations is a matter of software configuration.
For a while, the 100k imager was not officially supported by IFM and was
considered experimental. The support is now official. For the current
released version of our driver, you need to turn it on as a "backdoor
method" and I have documented that approach here:

https://github.com/lovepark/libo3d3xx/blob/master/doc/100k.md

In the next release of the software (which is coming in early March),
the official way of doing this will be built right into the driver.

Related to this, you may also be interested to know that IFM offers the
O3D with different optics packages which is essentially different lenses
which can be used to widen the FOV of the camera. NOTE: the number of
pixels will be unchanged, it will just widen the field. Perhaps a
combination of the denser pixel array and a custom lens could give you a
configuration comparable to the Kinect. For the types of applications I
have worked on in the past that employed the Kinect, we were always
decimating the point cloud anyway as we did not want to chew on that
much data, YMMV. For our industrial applications for which we employ the
O3D, we actually use the 23k pixel imager and it has proven sufficient.
This, coupled with the overall robustness of the O3D/ToF, has made it a
solid choice for our industrial 3D vision applications.

> Secondly, the flying
> pixels weren't just "lone" pixels floating in space but rather a
> continuous band from the foregraound object to the background object so
> it might be more difficult to filter. Anyway I'll try and post my results.
>

Yes. I'm familiar with this effect you are seeing. Again, I have
employed the PCL statistical outlier filter (with some tuning) to
successfully filter out such aberrations. You may have similar success.

Best,
Tom