Quote:
Originally Posted by Gdeaver
I've been looking at some of the cheap Android 4.0 tablets that have come into the market. You get a reasonable screen, 512 or 1 g memory, up to a 1.4 ghz quad core arm and a camera for less than 100$ and some refurbs for less than 60$. Pair the android sdk with open cv for android. Could this be the cheap robot vision system ? Would have to figure out how to get usb in to the crio.
|
You don't actually need USB at the cRIO.
You bridge the interface with another circuit and you can do exactly what you intend.
When I helped propose the 2015 contol system I actually did this.
Course without intending to bridge to the cRIO.
However it wouldn't be all that different.
The risk here though is if you use the integrated camera in the tablet (which I am presuming you intend) you have to contend with a few things. The tablet dimensions. The lack of a lens fixture (this is easily worked around I have recorded excellent video with a lens on an iPhone and you can even get a parabolic lens for the iPhone now; plus 3D printers make this easy). The potential for image controls in the firmware of the Android camera (there are circumstances where what looks good for a picture is not good for image processing). Plus there's the matter of the tablet WiFi which might be an issue.
So while I actually did make this work and would happily make it work again if someone wants to tinker with it.
I thought an integrated camera about the size and shape of the existing cameras might be a better choice.
Course it might not be the cheaper choice because of the power supply issue.
I doubt I can bundle a camera, a dual core ARM board and a suitable battery for less than $150 in the kind of quatity I would expect from FIRST (in otherwords deliver it as a COTS product).
Though I have another application (or dozen) for it.
Quote:
Originally Posted by Greg McKaskle
The other thing to keep in mind is the development tools and debugging tools. Vision systems rarely work the first time, debugging them can be tricky, and you frequently need to debug them when the environment changes. So invest in the ability to see the images and understand what the various processing steps are doing, and you will be far more productive later.
|
So far I've approached that 2 ways.
Accessible local frame dump so you can get the image without the overhead of TCP/IP (memory card).
A set of access points to set programatic detectors for things like white-out (which does impact processing performance).
The idea was:
1. To be able to see what is going on if you need to see the process.
2. To be able to alert if bad things are about to happen.
My current image sensor is from OmniVision.
I've been using their CMOS 'camera' sensors for years.