If you were to choose an ethernet video camera, which one would you choose? (This would be based on low cost, low processing requirements, avaliability, and easily usable interface (I assume cameras just export JPEGs or TIFFs, but I figured there might be some funky encryption stuff, and I’d rather not try to deal with that in Labview)).
Why did I place this in “Programming” and not “Technical”? I’m using the camera for practice programming, being a programmer, and as long as it’s ethernet, I shouldn’t have to worry about physical interface.
In the FRC applications I’m familiar with the camera is not used to transmit images. The camera can do video, but it is put into a different mode. In hardware/software it is put into a mode where it filters all colors except for the color on the target light.
The camera then streams x,y coordinate data of the light. If you look at the video when in this mode and using the light, all you see is a black screen with a bright dot, where the light is.
If you know the x,y coordinates of the light then you can make things go.
whether the data comes over ethernet or rs232 it doesn’t matter since they are only transport layers.
ebarker correctly describes the functionality of the CMUcam we received in the KOP some years ago, but that does not apply here–the CompactRIO should (from what I understand) take anything you throw at it.
I know Linksys makes some remote surveillance products but I think they demand a high premium. After some searching on NewEgg (no affiliation, just…they do great work ) the list shows that the cheapest Ethernet camera is $79.99. As far as transferring images, I think you will need to do a bit of reverse engineering. Can you do HTTP with LabVIEW? I am not familiar with it at all, so I don’t know how possible this is. If the web interface is a simple webpage refreshing itself, you could possibly hotlink to that JPEG and keep downloading it every second or so. But if it’s anything more sophisticated…you are welcome to ask here, but I can’t guarantee that we can help.
Good luck, and I wish I were in your shoes. Instead I’m a college freshman…got to focus on class, not FIRST, at least for a few terms…
May the force be with you!
JBot
Some more thoughts: don’t bother buying the camera until you have set up (on your PC) a copy of WAMP or somethingequivalent and placed a JPEG in the WWW folder and successfully parsed and processed it with LabVIEW on the CRIO. Then you can figure out the interface if it isn’t a series of JPEG images.
You have a lot of work to do…but I still envy you!
Can LV do HTTP? Yes, though you will do it over TCP with a bit of string formatting and parsing.
If you choose to go this route, any enet camera should do. All we’ve looked at use HTTP to initiate the communications and change params. Some camera vendor’s have good documentation on their web site, others were reverse engineered using wire shark.
By the way, doing this on a PC and later taking it to the cRIO should transition easily.
Yes, but not nearly as well as they will in a few months. The current code for loading JPEGs and MJPEGs expects them to come from disk. So, you can make it functional, but not performant.
Let me just make sure I interpreted that correctly:
One of the things NI is currently working on is a VI to convert live video from an ethernet camera into a picture data type that will give the current frame whenever requested? (And this VI will not be locked, so we can actually see how it has been done?)
The few months wasn’t meant to imply we are still working on it, but rather when it will be delivered.
As for locking VIs, the JPEG convertor will in fact call into a C++ library because that is what the kernel of the imaging library is written in. The networking layer will be done with native LV functions, and all of the new VIs being written for FRC are unlocked and open source.
There will be some locked VIs in vi.lib, same as there are in regular LV. The reasons for locking them tend to involve submission for patents. There will also be many many example to rip into.
That is pretty silly. That VI calls back into a LV entry point, and unless that sort of thing is locked down, people will start calling into it as well, but without the wrapper, the parameters may not get conditioned – leading to crashes. And if/when we change the interface, we can also change our wrapper to match. If other locations are calling the interface, we have to honor the old interface as well or break their code.
Anyway, the reason the color stuff has to call back into LV is for the symbolic colors. The LV color picker and managers tap into the OS colors such as Window BG, Text FG, Text Selection, etc. That color lookup is the primary thing that the callback into LV handles.
) the 