Camera Tracking

[wildaburk3160]

Hi guys, I'm head programmer on 3160 this year and we've decided that some sort of camera tracking is essential for next season. After doing some research on these forums I've been directed to the Rectangular Target-2013 example in FRC examples. I open it up and none of the code is comprehensible. Would it be possible for any one to direct me to some source that can offer some explanation to what is going on in the code? I've seen some white papers about different aspects of vision in LabVIEW, but they weren't very helpful as far as explaining any code. If someone could help a LabVIEW vision rookie out, it would be much appreciated.


Links to the white papers here:
https://decibel.ni.com/content/docs/DOC-14557
http://www.ni.com/white-paper/2723/en

[Joe Ross]

Here is the white paper that describes the 2013 vision code. http://wpilib.screenstepslive.com/s/3120/m/8731

[wildaburk3160]

Thanks Joe, that is extremely helpful.

[Greg McKaskle]

And here is the earlier pdf of the 2012 code. https://decibel.ni.com/content/docs/DOC-20173

If you have other questions, please ask more explicit questions here.

Greg McKaskle

[wildaburk3160]

If I want specific motors to be controlled based on the feedback given in the vision processing VI, do I put program the motor response in the vision processing VI, or do I need to make a global variable of some sort, and put it in the teleop VI? I have no experience with global variables.

[Greg McKaskle]

If the motors are exclusively controlled by camera, unlikely and potentially unwise, then you could put the code in the vision loop. But more likely, you'll have a manual mode and/or only use the vision for specific tasks. This makes it much more common for the camera loop to update globals indicating the quality and state of its image processing. Then a parallel loop -- can be teleop, but more often periodic tasks -- will read the globals and update the motors.

Globals are actually quite easy to use correctly, but also quite easy to use incorrectly. The key is to limit the number of writers to the global. Ideally, only one piece of code would ever write to the global. It is quite common to have an initialization phase that breaks the rule but happens only at startup.

If you want to trigger something, you can also use events, notifiers, or even queues, but globals are quite capable for FRC robots.

Greg McKaskle

[wildaburk3160]

Oh, I wasn't planning to have the camera explicitly control the motors, I didn't mean to imply that. I just wanted to have, like you said, a manual mode in teleop and when the camera is in range of the retro-reflective target, or at a button press, have the camera take over to align the bot properly. I will try out the global variables and I will likely have more questions down the road.

[wildaburk3160]

After finding and doing the labview tutorial on integrating vision code into a robot project, and duplicating the vision code hierarchy, an error occurs where there is a bad wire connecting the "Get Mode" VI to the Robot Main global variable that is connected to the adjacent case structure, claiming that I am connecting two different data types. I've checked another project and this problem does not occur there.

[Greg McKaskle]

Can you post a picture of the broken diagram? It sounds like something was copied from the vision example into the Robot Main that confused data types.

Greg McKaskle