Variables, Cameras, and Wait

[blackflame2996]

Originally Posted by dfu1234

So, I like programming in things that are text based. This is my first time using labview. I wouldn't be using it is the vast majority of the team didn't require it. So, I am totally lost in it. No one seems to know how to use a variable. Such a quintessential part of programming, and I can't use it.

Question two. I have the vision processing vi incorporated and (I think) working. What I want to know is how to get the distance data out of it. I tried google. A lot. I failed. Please help.

Question 3: Data lookup table: how could I go about making and using one? This would be for the distance processing as our launcher changes speed based on distance.

Question 4: How would I, for example, make it so that a motor spins a certain way thereby turning a camera and stops when the camera looks at the target "dead on"?

And Question 5: How do I use a "wait" command? I just want to delay a t/f signal all of 1 second. I cannot for the life of me find a wait command that seems like it will do this job.


Thank you in advanced.

Ok, let's start with variables. Go to the data communications palette. drag and drop the Global Variable. double click this to access its contents. on this front panel, drop whatever elements you want; for example, use an LED for a boolean, and a numeric indicator for a number. Now back to the Icon on the block diagram of your code. By default, the variable is set to wright. copy and paste, creating a write block for each element of the variable set. click on the icon to select the element. plug in whatever info here. Now, where you are sending the info, paste the variable, and right click. click "change to read", and select the element. wire the output to whatever needs the info.

now, for the rest of this. There is a real danger of choking the RIO's CPU when running vision on it. we found this problematic, and learned from another team at our first regional how to run image processing on the Driver's station. I would highly recommend offloading vision processing to the DS, so as to free up CPU. here is a sample code that runs the distance and position processing that you need on the driver station. http://dl.dropbox.com/u/42324681/Distance%20Get.zip


We have had a great deal of success with this code. what you do is get the value from the processing, and put it through UDP (I included a UDP example), and write the signal read by the RIO to a variable. Now, I would recommend that instead of sending the distance and processing it, process the distance on the station, and just send motor values to the RIO.

Now, for positioning the camera, I will assume that you have encoders of some sort on the motor that moves the camera. In the included processing, one of the outputs is the position, as an x,y value. you can take this, and again process this into a position shift on the station, and send the position to the RIO. I cannot help with specific values, but unbundle the position into the x and y, and find the appropriate position shift.

If you don't have encoders, have it find which direction the camera is off, and send a (LOW) motor value, and a 0 when it is in the tolerable range. NOTE: the UDP example that i provided will need adjustment if a 0 is supposed to be read. at the moment, there is a feedback node to return the last "good" value if the UDP value is 0, but this will need to be taken out in order to receive a "0".

for any values going through UDP, I would cluster them all, and unbundle them on the RIO to prevent problems with the channel. on the RIO's end, do the UDP receiving in timed tasks, and write all values to global variables.

for question 5, it depends on where in the code this is located. more info would help.

I sincerely hope that this helps.
--David Donahue.

[dfu1234]

THANK YOU!

Ok, so, I REALLY like the idea of putting all that processing onto the computer, but I need help with how to actually incorporated it. Do I just extract the folder somewhere and then add the folder via import, or should I put all of these in their proper file location?

Offputting it to a computer also means I can do the actual math instead of a look-up table .

Thanks for all the detail information on the camera. I will try to incorporated (well, not try. HAVE to) later, when I meet up with my team. Let's hope the none-encoded SPIKE is easy enough to set up.

And, the wait command is like this. In Teleop.vi, I want to use a button to change a Boolean variable back and forth. So, I currently have a sort of t flip flop with the button and the variable as the inputs. Here is a picture of it:

Before anyone comments on a glaring flaw in this, there will soon be a while loop in it with button nine the determinate.

What I want to avoid is this: Person presses button 9; Gyro is true. Next tick: Output false into gyro. Next tick: HEY LOOK! Inverse Gyro is true and Button Nine Pressed is true. Let's output and change it! Next tick: etc etc so on and so forth. Considering how fast ticks are, this could utterly screw me. THAT is what I want a wait command/block for.


Team 3595 Massive Attack thanks you heartily.

[dfu1234]

Um, in which vi do I put the math? And, what are the output variables? Like I said earlier, I am completely new to labview. After putting this in the project, I am at a loss of what to do. Please help. We are literally at competition right now (practice day, but still.)

[Mark McLeod]

Do not put loops or waits in Teleop.vi
That would freeze your response to the driver controls and your robot will become jerky and uncontrollable running off to who knows where while your Teleop is waiting (and not processing new packets).

You need to find someone at the competition with you to look over your shoulder and give programming advice. Most events have a Control System Advisor (CSA) who you can ask for help. Pit Admin will know how to get you in touch with them. Also, check with nearby teams or Pit Admin/Help Desk may keep a list of teams that offer programming assistance.

[Greg McKaskle]

The problem with the code you attached is that it is simultaneously setting Gyro to the value of !(Gyro && Btn9) and to (Btn9 && !Gyro). Your code doesn't really say which should go first or last, and really, you probably meant to set the Gyro global only once on that diagram. If you wanted an if/else, that is called a case statement.

Perhaps what you were wanting to do was to invert Gyro once when button 9 is pressed, regardless of how long it is held. That would be more like the attached. It says that if the button is now true, but in the last message was false, invert the variable Gyro (except I didn't use a variable but a label).

If you wanted something else, please describe the desired behavior thoroughly and I or someone else can show how to do it.

By the way, the node I used, the feedback node is a special variable with very tight scoping so that it works well in parallel environments. It is a wire. No, its a variable. Actually its a piece of diagram state data that guarantees one reader, one writer, and allows for initialization. A related entity is the shift register.

As for your urge to use variables. It is a necessary part of many nonfunctional languages since they have no other good way to transfer data. It may be useful to think of a wire as an unnamed variable that you assign on the upstream/left end and read from on the downstream/right ends. Again, it is guaranteed to have one writer each iteration, and not only does it deliver the value, but allows the downstream element to execute. Functional languages like portions of LV, are very different from procedural languages, and strange at first, but very powerful and often very simple once you understand a few concepts.

Greg McKaskle

[blackflame2996]

I agree, variables are not necessary in LabVIEW. there are very few things that cannot be done with wires and feedback nodes. their main application in our code is transferring info between two sub VI's where wires, for some reason, did not work.

[blackflame2996]

just extract it anywhere, all of the dependencies are in the folder. open the project, and build the exe to use the dashboard. sorry it took so long to respond, had a regional.

[MAldridge]

This is my solution to the toggle (see attached). At some point, I will do a write up on the advantages of doing it this way. Essentially, you put 'Grand Unified Button Handler' in your periodic tasks in a 15Hz loop and read your joysticks into it there; then you pull the outputs into a global and read the global wherever you need it. In the GRUB main vi, there is a control labeled 'latched?' you set which ones are latchable and then you set current as default, that way you can quickly change a button from latching to non-latching without rewriting large sections of code.