Suggestions for multiple (cheap) Ethernet cameras

[Yair]

For an upcoming project, I was asked to monitor ~20 gauges. It looks like the vision VIs for reading gauges are simple enough, so the trick is now to connect to that many cameras.

The cameras themselves don't have to be high performance (a resolution of 640x480 or less and a maximum frame rate of 5-10 FPS is probably more than necessary), so the main factor is the price of the cameras.

I understand that GigE is the practical standard for doing something like this, but it seems that all those cameras are overkill and way too expensive.

The USB drivers are limited to a single camera.

Does anyone have experience\suggestions for connecting to multiple cheap cameras and getting the images at reasonably real time? Any specific models? Any warnings?

P.S. I have no practical vision experience, so feel free to suggest anything (e.g. maybe saving snapshots and loading those files will work. I just don't have any experience with the cameras).

[crelf]

QUOTE (Yen @ May 20 2008, 01:26 PM)

I understand that GigE is the practical standard for doing something like this

Why?

QUOTE (Yen @ May 20 2008, 01:26 PM)

Does anyone have experience\suggestions for connecting to multiple cheap cameras and getting the images at reasonably real time?

It depends on what "cheap" means - what you need to keep in mind is the appropriateness of your lighting, quality of the sensor (CCD) and the optics that you put in front of it. I'd suggest you check out FireWire cameras - they're relatively inexpensive, and through the magic of a firewire hub, you can have a whole bunch of the online simultaneously (bandwidth dependant, of course )

I usually use camera from AVT - if you need several of them, they'll give you a good volumne discount.

[Yair]

QUOTE (crelf @ May 20 2008, 08:52 PM)

Why?

I didn't realize FW can be split effectively and in any case it requires specific hardware, while any decent computer anywhere has an Ethernet port.

Regardless, IP based systems are extremely easy to set up, extend and modify using existing infrastructure.

By "cheap" I mean "as cheap as possible". It doesn't have to be the ~$10-20 you pay for USB webcams, but I wouldn't expect a $500 price tag for each camera either, since the requirements don't call for something uber-powerful.

I will look into FW and AVT, thanks.

Any other suggestions?

[Neville D]

I think Gig-E is the way to go, considering you can have cable lengths upto 100m (no need for an expensive fibreoptic FireWire extender), can use regular Ethernet hardware, and don't need any special cables.

Downsides:

1 Gig-E cameras need externally supplied power

2 Gig-E cameras are not yet supported under LabVIEW-RT (which limits you to LabVIEW and Windows only)

3 5-10% of processor power is used to deal with the Gig-E traffic in acquiring the image before it can be processed.

4 You have to consider network traffic when all of your cameras are firing simultanously or if they share the network with other PC's.

I have had good results with Prosilica FireWire cameras; they also manufacture Gig-E cameras They probably will do a volume discount as well.

I don't know about "cheap". I doubt your going to be able to get a reasonable industrial camera for less than about $300-$500. And then you have to factor in the cost of the lens (another $100 at the very least). Maybe you can put all the gages on the same physical panel and use a single camera to monitor them all?

Also, vision applications always suffer from feature creep; if you buy junky USB cameras, your soon going to have to discard them for something better.

Neville.

[Chris Davis]

You may want to check out a "internet camera" type device (example). They fall within your price range (especially the wired ones) and your specifications. They often tell you how to connect to them via TCP and stream thier video, or get the latest picture snapshot as a jpg via http or ftp. I've got one at home and they are easy to setup and use, given a router or static IP address.

As Chris mentioned, don't expect miracles out of these cameras, but its probably cheaper than AVT.

If you choose to go with firewire, you can checkout Imaging Source as well, they have small low cost firewire cameras too.

[crelf]

QUOTE (Yen @ May 20 2008, 02:31 PM)

Regardless, IP based systems are extremely easy to set up, extend and modify using existing infrastructure.

Oh, I see, you're hoping to use existing architecture - gotcha.

QUOTE (Yen @ May 20 2008, 02:31 PM)

It doesn't have to be the ~$10-20 you pay for USB webcams, but I wouldn't expect a $500 price tag for each camera either

I don't think you'll get anything other than USB for that price - Firewire cams generall start at $US1k each.

[MikaelH]

I use a web based camera and uses the Data Socket VIs to download the image from the cameras.

Camera:

Code:

URL:

--Mikael

[crelf]

QUOTE (MikaelH @ May 20 2008, 06:04 PM)

I use a web based camera and uses the Data Socket VIs to download the image from the cameras.

Great point Mike - you can get all sorts of web-based media using this technique - http://forums.lavag.org/Downloading-an-image-from-a-Web-server-using-Datascoket-t100.html' target="_blank">see here from more info.

[Yair]

Thanks for the replies.

The approach suggested by Chris and Mikael might be good. Mikael, what kind of update rate can you get from that camera?

I'm still fuzzy on all the details of the specific project, but my understanding was that the gauges are in fixed locations and can't be moved.

A further detail I obtained today is that at least some of those gauges are small (about an inch in diameter). Do the cheap cameras have the ability to see details of this size with reasonable quality (assuming of course you have proper lighting and place them close)?

Another thing I learned is that $500 might not be too much, so I might go with GigE. Neville, is the 5-10% CPU usage a constant overhead or will it happen for each camera? If I have 20 cameras, each taking 5-10% CPU, I'll probably have to do some synchronizing. I'm hoping that at least most of the gauges don't have to be read more often than once a second, so I may not have a problem there.

QUOTE (crelf @ May 21 2008, 04:51 PM)

you can get all sorts of web-based media using this technique

As long as it's in a known format and is served.

[Neville D]

QUOTE (Yen @ May 21 2008, 09:54 AM)

Another thing I learned is that $500 might not be too much, so I might go with GigE. Neville, is the 5-10% CPU usage a constant overhead or will it happen for each camera? If I have 20 cameras, each taking 5-10% CPU, I'll probably have to do some synchronizing. I'm hoping that at least most of the gauges don't have to be read more often than once a second, so I may not have a problem there.

As long as it's in a known format and is served.

The overhead is required for the packets to be received via TCP-IP and organized together to form the image, so I would guess it doesn't matter how many cameras you have attached, but depends how fast the images are coming through (frame rate).

Since your system will be fairly static, you can also boost the performance by defining a ROI (region of interest) so that the camera only sends the pixels in the ROI. This limits the amount of data transfer, the size of LV Vision buffers used and improves overall speed and system response.

I personally haven't used a Gig-E camera in a project since we use LV-RT on a PXI system, we are limited to Firewire only.

If using a cheaper camera with jpeg output, make sure the image processing works OK with jpeg images before you start. The DCT transform used in the http://en.wikipedia.org/wiki/Compression_artifact' rel='nofollow' target="_blank">JPEG compression algorithm tends to have trouble with straight edges in an image.

Let us know how it all works out!

Neville.

[MikaelH]

QUOTE (Yen @ May 22 2008, 02:54 AM)

Mikael, what kind of update rate can you get from that camera?

I did a test right now.

http://lavag.org/old_files/monthly_05_2008/post-941-1211425248.png' target="_blank">

..and when sitting at the office and accessing my local network at home, it took 1448 ms per image.

So on the same local network you should probably be able to get 2 images per second.

You might need to use normal TCP/IP function so you don't need to reconnect every time, and use a normal HTTP Get command.

//Mikael

[NI Vision Guy]

QUOTE (Neville D @ May 21 2008, 12:58 PM)

The overhead is required for the packets to be received via TCP-IP and organized together to form the image, so I would guess it doesn't matter how many cameras you have attached, but depends how fast the images are coming through (frame rate).

Since your system will be fairly static, you can also boost the performance by defining a ROI (region of interest) so that the camera only sends the pixels in the ROI. This limits the amount of data transfer, the size of LV Vision buffers used and improves overall speed and system response.

Neville.

Another thing you can do to improve performance in a GigE Vision application is to make sure you're using an Intel Pro 1000 NIC. The NI Vision Acquisition driver has two modes, normal and high performance. The normal driver runs on all other NICs, but when you have an Intel Pro 1000 based NIC, the NI IMAQ driver automatically detects this and will grab the incoming packets before they go through all of the overhead provided by the windows network driver. This can drastically reduce the processing time required to build up the images from GigE cameras.

Hope this helps some!

http://zone.ni.com/devzone/cda/tut/p/id/5750

-Matt

[crelf]

QUOTE (NI Vision Guy @ May 22 2008, 11:09 AM)

...when you have an Intel Pro 1000 based NIC, the NI IMAQ driver automatically detects this and will grab the incoming packets before they go through all of the overhead provided by the windows network driver.

:thumbup: Great stuff to know - thanks Matt!

[Yair]

Thanks for the responses. It might be a while before this actually happens, but I'll try to remember to post an update.

P.S. Welcome, Matt.

[robijn]

Basler GigE cameras are quite affordable.

Joris

[Yair]

Thanks, I added it to the list.

[curiouspuya]

Hi Yair,

Its been a while since this post but can I ask how you went with your multiple cam application?

Thanks

Peter

[Yair]

The answer is that it didn't go. The vision part of the application was canceled, so I can't really provide any insight.

[mohsendk]

On 5/21/2008 at 11:43 PM, crelf said:

QUOTE (Yen @ May 20 2008, 01:26 PM)

Why?

QUOTE (Yen @ May 20 2008, 01:26 PM)

 

Does anyone have experience\suggestions for connecting to multiple cheap cameras and getting the images at reasonably real time?

 

 

It depends on what "cheap" means - what you need to keep in mind is the appropriateness of your lighting, quality of the sensor (CCD) and the optics that you put in front of it. I'd suggest you check out FireWire cameras - they're relatively inexpensive, and through the magic of a firewire hub, you can have a whole bunch of the online simultaneously (bandwidth dependant, of course )

I usually use camera from AVT - if you need several of them, they'll give you a good volumne discount.

Hi dear Crelf, 

I'm trying to get a snapshot from 15 cameras simultaneously in Matlab platform, I tried it by usb cameras using 2 usb hub, but it was impossible. do you know whether it's possible or not, if I use gige or ip cameras associated with ethernet hub? 

[Rolf Kalbermatter]

3 hours ago, mohsendk said:

Hi dear Crelf, 

I'm trying to get a snapshot from 15 cameras simultaneously in Matlab platform, I tried it by usb cameras using 2 usb hub, but it was impossible. do you know whether it's possible or not, if I use gige or ip cameras associated with ethernet hub? 

Are you serious? Do you want to operate those cameras in 320 * 240 pixel mode?

First do some basic calculations about data throughput before starting to ask such questions. Your USB bus certainly will start to hick up if you try to transfer that many cameras at full resolution simultaneously to your computer. It's likely to cause trouble even with a lot less of cameras. USB never was intended for so many high speed simultaneous devices and even with GigE ethernet you will be getting trouble if your cameras have even remotely modern resolutions and you want to do more than 1 or two frames per second per camera.

And once you get all that data into your computer you will be hard pressed to do any significant image processing in realtime on it.

Edited August 28, 2019 by Rolf Kalbermatter

[ShaunR]

9 hours ago, Rolf Kalbermatter said:

Are you serious? Do you want to operate those cameras in 320 * 240 pixel mode?

First do some basic calculations about data throughput before starting to ask such questions. Your USB bus certainly will start to hick up if you try to transfer that many cameras at full resolution simultaneously to your computer. It's likely to cause trouble even with a lot less of cameras. USB never was intended for so many high speed simultaneous devices and even with GigE ethernet you will be getting trouble if your cameras have even remotely modern resolutions and you want to do more than 1 or two frames per second per camera.

And once you get all that data into your computer you will be hard pressed to do any significant image processing in realtime on it.

He only wants to "snapshot" rather than streaming images, from what I understand.

15  is theoretically feasable for single images with gigE (1920x1080 @ 12 bits/pixel ~ 3.2 MB per image). I'd use a hardware trigger to make sure they are all triggered simultaneously in spite of congestion. It might take a couple of seconds to get them but the biggest issue I see is that the OP is using Matlab

Edited August 28, 2019 by ShaunR

[Rolf Kalbermatter]

2 hours ago, ShaunR said:

He only wants to "snapshot" rather than streaming images, from what I understand.

15  is theoretically feasable for single images with gigE (1920x1080 @ 12 bits/pixel ~ 3.2 MB per image). I'd use a hardware trigger to make sure they are all triggered simultaneously in spite of congestion. It might take a couple of seconds to get them but the biggest issue I see is that the OP is using Matlab

Ohh well I missed the "snapshot" 😆

But I would have to agree with everything in your post. Matlab isn't going to make this any easier at all. 😆