Camera tracking logic???
 

Hey, not a programmer, but I've heard (and witnessed) that processing a constant video stream, as well as trying to send images back to the drivers station for processing is a no no. Is there anything special about processing on the crio?? How often should we grab an image from the camera so that the crio can handle it. I heard there was a 0.5 second delay when processing an image on the crio, someone said start a new "thread" in the code, what does that mean? Can anyone confirm or deny these claims???? We don't have the weight for it yet, but is it worth it to have a classmate onboard?? I've seen many teams effectively use the crio, but we're pretty lost. I figured press a button, grab an image, process, make drivetrain adjustments based on how far off target, grab another image after a half second or so, adjust again, and shoot. I think that's all people are doing, but I heard the crio is just too slow, are people knocking down the resolution alot??

Re: Camera tracking logic???
 

Our cRio's processor was peaking, so I removed the'enable vision' boolean in robot main and made a joystick button write to the enable vision.vision processing doesn't happen on the DS. Its all on the cRio.

Re: Camera tracking logic???
 

Oh boy, that's a big bunch of questions. I'm gonna try to answer each part, but there's a lot of information that can go into any one of these, much of which can be confusing to non-programmers and inexperienced programmers alike. Here we go:
This question is a bit ambiguous, but the major concerns of video streaming and processing are this:

• Streaming takes a lot of bandwidth. There's only so much data you can send over the field network at a time, and if you try to send too much, packets start getting "dropped" and the important packets (like the ones controlling the field) may be among the dropped packets, which causes issues.
• Images are big. An image on a computer is typically stored in "truecolor", or RGB format. In this, each "pixel" (a little square of color) is made up of three components: red, green and blue, the primary colors of light. Network cameras and webcams often stream video as a series of 640x480 (pixel dimensions) images. This means that there are over 300,000 pixels, and nearly a million separate components. Processing an image takes at least one stop at each pixel, and quite often many more than that, so it takes a lot of processing time on the computer (or cRIO).
• Streaming to 2 places takes twice the effort. If your team programs the robot to process the image on the cRIO and stream video back to the driver station, that's a total of 2 different video streams, each sending a rather large (although compressed) image over the field network.

Absolutely. The cRIO's processor is a 400 MHz RISC processor, which in layman's terms means something akin to "slower than your grandmother driving a tortoise up a molasses waterfall in January."
You have a knack for simultaneously asking 2 questions ;) I'll start with how often you should grab an image.

From a purely theoretical standpoint, it can be as frequently as you want, as long as your code can respond to it. However, the fewer images you grab, the less strain you put on the network. So if the code can only process 2 images per second, you may want to lower the frequency to 2 a second, or maybe 5 if you want to make sure the camera stays ahead of your processing code.

Threading is a way to have a computer share its processing time between two separate, "simultaneous" processes. I put simultaneous in quotes because computers (unless they have multiple cores) just can't do anything simultaneously. You can think of a thread as, well, a thread, weaving in and out of the computer's execution of commands. It's helpful in this case because image processing operations can take a long time, and if you don't have it threaded, this can mean that your robot spends a lot of time sitting there without being able to respond to input from the driver station.
Certainly. However, asking programmers ambiguous questions may not always get you the answer you want. We're used to dealing with machines that do exactly what we tell them to do: nothing more, nothing less; when someone asks a question that could be easily interpreted multiple ways, I for one tend to either answer both or answer neither instead of having to guess at what you were thinking when you asked it. ;)
That depends entirely on your programmers. If they can program a laptop to do secondary processing for the robot, go for it. However, I don't have any personal experience with that, so I cannot in good conscience tell you either way.
The cRIO, at least in my experience, takes anywhere from a third to a half of a second to process an image, and that's at its best. There's a lot of information that can be gathered from a single image, and if you can't afford that half-second gap, you can rely on a sensor like a gyro. You can use the camera to determine the angle of the target, then use the gyro to lock on. But again, it depends very heavily on what your programmers are capable of, and what tools you're willing to work with.

If your software guys need more information on how they can process the images they get, I've made a couple of posts on the issue: http://www.chiefdelphi.com/forums/sh...58&postcount=4 and http://www.chiefdelphi.com/forums/sh...61&postcount=2