General LabVIEW questions from a VERY new user

[ctccromer]

This is my first year programming on our Robotics Team and our previous programmer didn't teach me a thing. I do have prior experience in Basic, C++, Java, and my calculator (physics equations OP), but I saw LabVIEW for the first time about a weak ago. I'm trying to work my way through it slowly but surely and am finally making some good progress, so I'm using this thread for any general LabVIEW questions I get as I'm learning the language itself

Also: I'm using a Logitech F310 controller (http://www.logitech.com/en-us/product/gamepad-f310)

My first question:
see this pic (http://sdrv.ms/Ww88mF)
I understand the part on the left, however the circled part on the right is still confusing to me.
I understand that the axis 1 (x) and axis 2 (y) relate to the left (i think) analog stick on my controller, and I also realize that in order to control the other (right side?) analog stick on my controller I need to make an axis 3 (x) and axis 4 (y) because the computer counts my entire controller as one big joystick.

HOWEVER, I *don't* understand why the axis wire from Joystick 1 branches off to a 2nd vi -- "Cluster to Array" and what goes on in that part of the branch. Why doesn't it JUST use the axes of the joystick? What cluster is it referring to?

The red circled part is un-edited from the starting code in Teleop.vi in a new cRIO Robot Project

Question 2:
Here is my current understanding of each file in a "cRIO Robot Project" Project file/folder that I made while taking notes. If I'm missing something important (or have a "?"), any extra insight would be really helpful

Team Code file

Begin.vi
-Initializes everything to be used later in the project
-Where motors and joysticks are "opened" i.e. initialized
-First .vi file in the project that runs

Autonomous Independent.vi
-Defines what happens in the pre-game, while the robot is running a pre-dertimined list of duties

Teleop.vi
-Defines what happens in the main and post-game, while the robot is being controlled from the Driver station

Test.vi
-?

Disabled.vi
-?

Vision Processing.vi
-?
-Assuming this is where I put stuff for the auto tracking system and the camera feed. Anything else?

Periodic Tasks.vi
-?

Robot Global Data.vi
-?
-Assuming this is where I define global variables? What separates global data here compared to joysticks and motors I open/initialize in the Begin.vi file and use throughout the project? (that seems pretty "global" to me)

Finish.vi
-un-initialize everything, basically the same (but opposite) as Begin.vi
-Where you close motors and joysticks, therefore rendering them disabled
-The last .vi file in the project that runs

Robot Main.vi (NOT part of team code folderr)
-Where you deploy the LabVIEW project as a whole to the cRIO from
-? Any other use ?

[Mark McLeod]

While waiting for the picture to get posted...

See if any of this training stuff helps:
The Tutorials on the Getting Started window
The FRC examples from the Getting Started window -> Support ->Find FRC Examples...
[FRC 2013] FRC Robot Framework Tutorial (https://decibel.ni.com/content/docs/DOC-26299)
[FRC 2013] Test Mode Tutorial (https://decibel.ni.com/content/docs/DOC-26314)
other tutorials at: [FRC 2013] Training Material and Resources (https://decibel.ni.com/content/docs/DOC-8923)
Training stuff I use: http://team358.org/files/programming/ControlSystem2009-/LabVIEW/Test.vi
- It's run from a special mode, You can use this to test new vi's for sensors or manipulators while avoiding running autonomous or Teleop.
This won't get run during a competition match, so you can leave partially tested code in here.

Disabled.vi
- stuff you want to have happen only while the robot is sitting disabled.

Periodic Tasks.vi
- stuff that runs in the background, like a compressor.

Robot Global Data.vi
- This is only one of the ways to pass information around in a LabVIEW program. There are other more common methods that you are already using, like the wires into a vi and the reference names we use for devices opened in Begin.
A typical example might be when code running in Periodic Tasks needs to pass information to Teleop to make some decision.


Robot Main.vi
-Stitches everything together. We only use it for running in debug mode.
The Run arrow doesn't deploy your program permanently to the robot, only temporarily. That lets you muck around with things, without risking the permanent program on the robot.

[propionate]

I am not 100% sure as to why the axes information is being put into another array, but it looks like unnecessary code to me. I haven't opened up LabVIEW 2013 yet - is this code part of the default project, or did you add it in from a tutorial online?

In regards to the different VI's, the guy above me did a good job. Perhaps a little clarification on Periodic Tasks. There are obviously a lot of functions going on in both autonomous and teleoperated mods, in relation to your robot. For example, you may be shooting frisbees in both modes or using some sensor. Rather than having duplicates of these particular functions in both the teleop and autonomous VI's, it is simpler to have them all in one place. That place is the Periodic Tasks VI, and it's nice because it runs in BOTH autonomous and teleop.

Once again, I haven't looked at the vision processing VI, but typically it just holds the code for getting the video input from the camera and sending it to the driver's station. You can add in vision tracking code here - usually we are given this (basically all the work is done for you) in a separate VI, but I'm not sure where it is. Some teams choose to do their vision tracking on a separate onboard computer, or send the video data to the driver's station and do the vision processing there.

Hope this helps somewhat.

[ctccromer]

I am not 100% sure as to why the axes information is being put into another array, but it looks like unnecessary code to me. I haven't opened up LabVIEW 2013 yet - is this code part of the default project, or did you add it in from a tutorial online?
That was the actual code it starts with when you make a new cRIO project. I didn't edit it in any way, just moved some things around, screenshot, and edited in paint.
What is it even putting INTO an array? The axis values? If so, I'll just delete and ignore that part of the provided example code

Once again, I haven't looked at the vision processing VI, but typically it just holds the code for getting the video input from the camera and sending it to the driver's station. You can add in vision tracking code here - usually we are given this (basically all the work is done for you) in a separate VI, but I'm not sure where it is. Some teams choose to do their vision tracking on a separate onboard computer, or send the video data to the driver's station and do the vision processing there.
If there is a vi that already does this (or even has SOME code to get started like all the other vi's) I'd DEFINITELY get that. I'll look around for it

Thanks to both of you guys for the help. Right now I'm just trying to work my way through all of the example code provided by making a new cRIO project. As I slowly come to understand it all, I'm modifying it to fit my situation this year, like changing it from 2 joysticks each with 2 axes, to 1 joystick with 4 axes

Which brings me to my Third question:
When working with the axes of a joystick, how do I change the 3rd and 4th axes to "Axis 3 (x)" and "Axis 4 (y)" instead of the default "Axis 3 (Throttle)" and "Axis 4"? The reason I need to do this is because I'm using the controller linked in the OP, which LabVIEW picks up as ONE joystick, but it has 2 analog sticks, so the left will be Axes 1 and 2, and the right will be Axes 3 and 4.

Question 4:
So I know a cRIO Robot Project is the code you make, deploy to the cRIO, then run on a computer that's in communication with the cRIO.
But what would I need to use a Dashboard Project for? Would that just be for if I wanted to add another feature to the dashboard/driver station windows?

[RufflesRidge]

That was the actual code it starts with when you make a new cRIO project. I didn't edit it in any way, just moved some things around, screenshot, and edited in paint.
What is it even putting INTO an array? The axis values? If so, I'll just delete and ignore that part of the provided example code


It is putting the axis values of the joystick into a SmartDashboard array which is sent to the dashboard.

If there is a vi that already does this (or even has SOME code to get started like all the other vi's) I'd DEFINITELY get that. I'll look around for it
Documentation on the Vision Processing example is here (I highly recommend reading all of it except the C++/Java code part, don't just skip to the LabVIEW code section): http://wpilib.screenstepslive.com/s/3120/m/8731

Which brings me to my Third question:
When working with the axes of a joystick, how do I change the 3rd and 4th axes to "Axis 3 (x)" and "Axis 4 (y)" instead of the default "Axis 3 (Throttle)" and "Axis 4"? The reason I need to do this is because I'm using the controller linked in the OP, which LabVIEW picks up as ONE joystick, but it has 2 analog sticks, so the left will be Axes 1 and 2, and the right will be Axes 3 and 4.

You can't easily change those labels, but the parenthetical is informative, it doesn't effect program operation. As a note, on many controllers (X-box controllers and at least some Logitech controllers) the second stick is not axis 3 and 4 because of things like the D-pad and/or analog triggers. You may have to experiment here, or put some indicators on the values for all the axes then run your program from your PC to figure out what maps to what


Question 4:
So I know a cRIO Robot Project is the code you make, deploy to the cRIO, then run on a computer that's in communication with the cRIO.
But what would I need to use a Dashboard Project for? Would that just be for if I wanted to add another feature to the dashboard/driver station windows?

Correct, a dashboard project is if you want to create a modified version of the dashboard program that runs on the PC. You cannot modify the Driver Station software.

[ctccromer]

I added the vision processing walkthrough to my favorites already and will look at that as soon as I get our camera up and running (have another thread about that)

And I was not aware about the axis thing. When I tested the buttons (booleans) today, the following parts of the controller did not register:
The left and right analog sticks obviously, the left and right triggers, and the d-pad.
Does it consider the left and right triggers as 1 axis each then?
And what does it consider the 8-way D-pad? My teacher and I were discussing it today and were kind of surprised it didnt show up as any of the 12 buttons. It seems like it would be a button/boolean value rather than a full axis

[Mark McLeod]

The triggers on game controllers are axis.
You can depress them halfway for half power.

[RufflesRidge]

Both directional pads and analog triggers usually show up in strange ways.

Analog triggers are typically mapped to a single axis for both. The axis will read 1 for 1 trigger fully depressed, -1 for the other and 0 for both. Partial depression of a single trigger will read a value between 0 and the extreme (1 or -1). Partial depression of both triggers will read something, or 0 (I recommend not having a control scheme that does this).

D-pads show up in different ways depending on the controller, but also typically map to an axis. This thread has a mapping for the F310 in it: http://www.chiefdelphi.com/forums/showthread.php?t=101479&highlight=d-pad

[Greg McKaskle]

Most of the questions seem to have been answered, but as to the incomplete description of the various functions, the diagram of Robot Main contains a large string constant with just such a description.

If you really decide you need to change the name of a cluster element, you cast it to a different cluster. The Cast function looks like forcing a square peg through a round hole. As noted, this is largely a cosmetic thing. Names of elements serve as documentation and little else.

Greg McKaskle

[propionate]

Thank you to RufflesRidge for filling in my gaps. In regards to figuring out the mapping for any kind of controller, the simplest way I have found is to create indicators off of the clusters for the axes/buttons. Then run the program on a cRIO with the driver's station plugged in and the controller plugged into the driver's station. Start pressing analogue sticks and buttons, watching as the values change on your indicators. A quick way to document your joystick controls!

[ctccromer]

I'm trying to set up a program so that I can use one axis to simply turn a CIM motor. I did Open/Close the motor and Set the RefNumRegistry in Begin and Finish, and the attached picture is from Teleop.vi. I can't figure out how to attach the two parts together though

[RufflesRidge]

Try changing your motor Get Output VI to a Set Output VI. That should help with figuring out where to wire in the axis.

[Alan Anderson]

The input terminal on the Motor Set Output function that receives the motor speed value is called Output. That can be confusing if you're not thinking in the same way the writers of the function were.

[ctccromer]

I managed to get our drive system and D-Link wireless router set up! Now I'm moving on to our shooter system, which consists of two wheels (attached to two CIM Motors) and an arm to push the frisbees into the two wheels (we're THINKING a window motor, but not 100% sure yet)

The drive system was pretty easy since it was mostly done for me in the base code, but the shooter I have to do from scratch so I'm a little confused. I attached screenshots of my current begin.vi and teleop.vi. (not finish because that's straight-forward)

How exactly do I attach two CIM motors to the values put out by axis 3?

[Greg McKaskle]

One thing I notice is that you don't necessarily need to enable the safety for spinner motors. If you believe that your code needs to update the motors in order to be safe and in control, then leave the safety on and consider the rate at which you believe you need to update them. Otherwise turn the safety off.

I think the next thing for you to do is to retrieve the motors of the shooter by name, and connect the axis value to the value of both motor refnums.

Greg Mckaskle

[ctccromer]

One thing I notice is that you don't necessarily need to enable the safety for spinner motors. If you believe that your code needs to update the motors in order to be safe and in control, then leave the safety on and consider the rate at which you believe you need to update them. Otherwise turn the safety off.

I think the next thing for you to do is to retrieve the motors of the shooter by name, and connect the axis value to the value of both motor refnums.

Greg Mckaskle
The safety thing makes sense, thanks!

As for the motors.. I feel like I'm missing the vi to bridge the gap between the axis values and the motor controllers' RefNumRegistry vi's. Which vi(s) do I need to use here?
Added another picture for clarity

Thanks for the help!

[Mark McLeod]

"Set Motor Output" is what you are missing.

For example:

http://team358.org/files/programming/ControlSystem2009-/LabVIEW/SingleMotorExample.jpg

[ctccromer]

"Set Motor Output" is what you are missing.

For example:

http://team358.org/files/programming/ControlSystem2009-/LabVIEW/SingleMotorExample.jpg

Thanks! And since I have two separate motor controllers, I assume I need two separate Set Motor Output vi's? I tried plugging both motor controller RefNumRegistry vi's into each side of ONE Set Motor Output but the right side wouldn't connect

Just want to make sure I'm not messing anything up by having it with 2 (pic attached

Also in the picture, does wiring the right-most Set Motor Output's "Output" value to the other one's output value (as shown) give the same value as if I had wired the right-most Set Motor Output's "Output" value to the wire itself (before it plugs into the other vi)? (2nd pic attached since I'm bad at explaining)

[Greg McKaskle]

Do the two attached images of diagrams work the same? Well, maybe.

The output terminal was added this year to simplify publishing to the SmartDashboard. If you have set the motor to invert or to have a scaling functions, the right-side value will not be the same as the left. But many times it will be.

I'd do it like the left image. Split the wire and connect to both motors.

Greg McKaskle

[ctccromer]

Do the two attached images of diagrams work the same? Well, maybe.

The output terminal was added this year to simplify publishing to the SmartDashboard. If you have set the motor to invert or to have a scaling functions, the right-side value will not be the same as the left. But many times it will be.

I'd do it like the left image. Split the wire and connect to both motors.

Greg McKaskle

Worked wonderfully, thank you :)
We drove our robot for the first time yesterday! It was glorious.

It also showed me that the controls are not sensitive enough at low levels and too at mid levels. So rather than just plugging in the axis values to the Drive Station plugins, I now want to do something like this:

If (axisValue < 0.4)
___axisValue*=1.5;
else if (axisValue > 0.4 && axisValue < 0.75)
___axisValue*=0.8;
(else, no change to the value)

I know (roughly) how to use the simple arithmetic and t/f vi's, but I couldn't quite figure out how to wire the input through so many if-then-else-if type scenarios successfully

EDIT: Added a pic of my attempt

[Greg McKaskle]

Rather than the stepwise adjustment, you may want to consider using square root. The attached image shows the plot from -1 to 1 and the code that preserves the sign of the square root of the input number.

Greg McKaskle

[ctccromer]

Rather than the stepwise adjustment, you may want to consider using square root. The attached image shows the plot from -1 to 1 and the code that preserves the sign of the square root of the input number.

Greg McKaskle

Thats a really smart idea that I hadn't thought of.. I'll definitely try it out at our next build day!

Just in case though, so I can have more to play around with, would someone mind explaining to me how to fix the pic above? I know the orange wires are double/numeric values and the green wires are boolean values, I just don't know how to set up an if-then-else-if sequence

EDIT: Also, another question.. Whenever I deploy code OR build the code, I get this pop-up every single time. I don't really understand what it means, but I just click okay and it deploys/builds perfectly fine. Should I just leave it alone or should I do something to stop it from popping up? (attached pic)

[Greg McKaskle]

The red X with the arrows pointing in away indicates no source on the wire. You have the wire going between two data consumer with no data source. If you hover over the X or use the context help window it will give a similar explanation.

To fix one of the cases, the code for 1.5X joystick is always wired to the motor, but you really want it wired to the <0.4 selector. And the multiply has a 1.5, but it doesn't have the joystick value wired to the other input. Branch the wire at the <0.4 and hook that up to the multilply as well.

The deploy dialog is an overly alarming dialog. You are doing it correctly, confirming that you intend to stop the program already running and start the new one you are deploying. You may want to consider using the Run button on RobotMain. This will do a debugging deploy and allow you to breakpoint, probe, highlight, look at panels, and get a much better understanding of how your code executes. Build and Run as Startup are only needed when you are finished debugging and writing code.

Greg McKaskle

[stingray27]

EDIT: Also, another question.. Whenever I deploy code OR build the code, I get this pop-up every single time. I don't really understand what it means, but I just click okay and it deploys/builds perfectly fine. Should I just leave it alone or should I do something to stop it from popping up? (attached pic)

What this is doing is trying to override the current code loaded on the cRio. Any time you build and run as startup to the robot, this dialog should pop up any time you are trying to redeploy to the robot. It is completely fine to just hit ok

[ctccromer]

So I'm trying to modify our drive system. I tried just plugging the output into a sqr-root vi and that into the drive system vi, but as soon as I enabled the driver station, the wheels immediately turn. I'm pretty sure it's vecause it's trying to take the sqr root of 0, so I'm trying to code it so that it'll work for everything, however I'm still confused how to do if-then-else statements in LabVIEW

I attached a picture of my attempt to make it work for positive and negative numbers (but still have not set it to "if == 0, go straight to drive system vi")

Also I've heard something about case structures for if-then-elses, not the "select" vi, but I'm not sure which to use how to use either one..

Thanks for the help!

[Greg McKaskle]

Taking the sqrt of zero shouldn't really cause an issue. You may find it useful to probe the wire you are sending to the motor. And if you are not comfortable with it, you can copy and paste the code to another VI that runs on the host and plot it as I did a few posts above. For the task you are looking at, the Sign and Absolute value functions are pretty handy.

Greg McKaskle

[ctccromer]

Instead of setting the motor speed to a certain percentage of full speed, is there a way to set the (CIM) motor to a certain RPM?



Also, I want to make it so that when button 5 is pushed pushed down, the axis 2 and 4 inputs (going into the arcade drive vi to move the robot's drive train) are multiplied by 0.25
In other words.. when Left Bump is held down, the robot moves and turns at 1/4 normal speed

In order to do this, do I need to set a simple boolean to Button 5 and then check the VI over at the axis inputs for the Arcade Drive VI, do I check button 5 directly, or what? I guess this is yet another if-then-else scenario I need to add to the axis inputs.. And they still confuse me

So for them, do I need to do Case Structures or Select VI's? And is there a tutorial for simply making a ton of if-then-else-if statements chained together? All the tutorials I find are introductions to labview, not about anything specifically like what I'm looking for

[Greg McKaskle]

The motor controllers you are dealing with are not aware of the type of motor and have little ability to measure how fast it is turning. It is possible to use CAN and a Jaguar motor controller, connect a motor and an encoder or other rotation sensor, and then you can get the Jaguar to do the speed control to get to motor to a given RPM set point. You can also do this in the cRIO, but at a somewhat slower speed. You still need an encoder and you need to use a control block such as PID or implement a simple bang-bang controller.

Selects and Case Structures are very similar. The biggest difference is that using a Select, all code is actually executed and the selected answer is propagated downstream. With a Case, only one of the Case statement diagrams is executed.

If you find yourself nesting too many expressions -- in any language -- there is often a more concise way to code it so that it is more readable. But this is a learning experience, so do it in whatever way lets you express what you want as code. Experiment with alternative ways of writing equivalent code, and before long you will develop your preferred coding style for this sort of thing.

Greg McKaskle

[ctccromer]

Thanks yet again :)

I'll forward the RPM stuff to our coach. The reason we were thinking about it is to keep the same RPM rather than a percentage of the motor speed (which would change as the battery dies)

As for the case and select vi's, I think I understand what you mean. And for the situation I mentioned about slower movement, I should just be able to use a case structure. Would you happen to have a picture of an example Select Vi?



We had a huge issue today. Spent a good half hour to an hour trying to figure it out and still never got anywhere, AND apparently last year's programmer never could figure it out either. We have a window motor (for our shooter) that I programmed simply:
Button x: if true, set motor output to 0.4 / if false, set motor output to 0
Button y: if true, set motor output to -0.4 / if false, set motor output to 0

I used case structures for both and copy/pasted the first one made and just added the (-) sign. However the issue is that only one of the two Case Structures will work! Say (ex) initially, Case A is +0.4 and Case B is -0.4. Case A will move the motor but Case B won't do anything at all. Then I switched the signs and Case A will move the motor the other way, but Case B still wont do anything. Switching buttons didnt make a difference. If I delete Case A, THEN Case B works, since there's no other Case in its way.
I tried it both with one and with two RefNumRegistry Get vi's but that didnt make a difference either.

Pics of the cases attached. The FALSE sides are identical to the TRUE sides, except the number is 0 instead of +/-0.4

[Greg McKaskle]

Triple click the Boolean wire coming from the Button. Delete it and rewire it. I suspect that you have one wire that just looks like it comes from 11 and another that comes from 12.

I again encourage you to have fewer icons to set the motor output. If you know that you will set it, just not sure what value, only make the value selection conditional. Code as you have written it has a tendency to evolve to the point where it is accidentally setting the same motor to 2, 3, or 5 different speeds during a single teleop frame. The winning speed is who went last, and it seems possessed.

I attached an image, definitely feels like I've drawn it before, that demonstrates what I mean. Note that in the case both buttons are pressed, you have to declare what to do. I chose to sum the speeds and the motor will not run. That may be a bad idea, but you have to decide what to do in that case.

Greg McKaskle

[Alan Anderson]

...only one of the two Case Structures will work!

They're both working fine. The problem is that one of them does something first, and then the other one immediately does something else, so what the first one did never has a chance to make itself seen.

What you're trying to do is easy, just not with parallel Case structures like that. Greg's code is simple, quick to implement, and hopefully easy for you to understand.

[ctccromer]

yeah, using select vi's instead of case structures worked perfectly, and is easier to understand ^^ And somewhat ironically, as soon as I checked that the Select vi's worked here, I went and programmed an addition to our drive system using a case structure, which worked fine. (I set it so that when a button is held down, to multiply the axis output values by 0.25 so we dont have to jerk the controls when aiming for a shot)

Thank yall so much for all the help. It really has been a huge help not just to me but our whole team. We now have a (theoretically) finished drive system and shooter. Now I'm about to start looking into pneumatics and what not for our climber, and camera, sonar, etc stuff for a tracking system

I do have one question, though not about that: I know that when I DEPLOY the LabVIEW code to the robot, I can use the Front Panel to read indicators and what not. However, when I BUILD the LabVIEW code onto the robot, is there any way to read the axis/button outputs (whether by using the front panels or sending something to the driver station program)?

[Greg McKaskle]

The dashboard shows a few values from the robot by default. It shows two joysticks with 12 buttons and 3 axes. Below are four graphs with the four motor outputs.

If you want to display more, make a dashboard project from the template, add the indicator to the Operation tab, name it the same as the SmartDashboard variable.

Then on the robot, in appropriate location, write the value to the SmartDashboard variable of the same name.

Greg McKaskle

[ctccromer]

Okay so we finally got our Axis M1011 camera in and today I'm trying to do as much work as I can for it. I set it up with the Axis Camera Setup Tool and read the three whitepapers I found (1 (http://wpilib.screenstepslive.com/s/3120/m/8731/l/90348-camera-settings#!prettyPhoto), 2 (http://wpilib.screenstepslive.com/s/3120/m/8731/l/90361-identifying-the-targets), and 3 (http://wpilib.screenstepslive.com/s/3120/m/8731/l/91388-labview-code)) so now I have a pretty good understanding of how it works. I DON'T know why I need to use RoboRealms (though I've heard that I do), and I don't know how to get started coding our tracking system into the LabVIEW project.

Is there one specific thing I could start with and build up from? For example, when I was just starting to work on coding the teleop and was completely lost, I started with the drive system (since that's simple) and worked my way up.

EDIT: also, is there a way to control how far a window motor turns? I currently have our window motor set for when x is true, it goes forward, and when y is true, it goes backwards, but i'd love to say "when x is pressed, go forwards __ degrees, then go back the same amount"

[Greg McKaskle]

To your first question, you have a number of ways to process images. One of those involves running RoboRealms on your dashboard or driver station computer and sending data to the robot. Others involve running LV code in your dashboard or running LV code on your cRIO.

To the second question, the window motors do not have a feedback mechanism. If you add a potentiometer or an encoder, possibly a limit switch in some cases, you can know how much they have turned. But the motors can't do that automatically, you have to build it.

Greg McKaskle

[ctccromer]

To your first question, you have a number of ways to process images. One of those involves running RoboRealms on your dashboard or driver station computer and sending data to the robot. Others involve running LV code in your dashboard or running LV code on your cRIO.

To the second question, the window motors do not have a feedback mechanism. If you add a potentiometer or an encoder, possibly a limit switch in some cases, you can know how much they have turned. But the motors can't do that automatically, you have to build it.

Greg McKaskle

We don't really need any image output on the drive station. We JUST want the tracking algorithm. So do we still need RoboRealms if we dont want the output on the driver station?

For the window motor, would my best bet be to say "go forward at x speed for y seconds then go backwards at same speed for same seconds." and then just play around with it to get it the right speed/time?

[Greg McKaskle]

My comment was about image processing for targeting. There are different ways of doing this with different tools. Look through the white paper links, though I'd suggest doing 3, then 2, then 1. Experiment a bit if you like, and decide on a tool you'd like to start with. You can always try another if you still have time.

Greg McKaskle

[ctccromer]

I'm trying to figure out how to wire "-1 for 250 miliseconds, then 1 for 250 miliseconds, then 0/nothing" into a Set Motor Output vi's output node, but I'm not sure how. Which Vi(s) should I use? I've found Timed Sequence as well as all different kinds of Wait and what not

[Greg McKaskle]

You don't mention whether this is for autonomous, teleop, or more general. I'll give some options and try to explain the tradeoffs.

In autonomous, no other code is running, and there is no need to return to the scheduling code. This means that your code can be written the simplest. You can use a sequence and in frame 1, Set Motor to speed S1 and delay with D1 in parallel. Frame 2, Set to speed S2 and Delay with D2, etc. You can generalize this to use a loop and an array of S1, S2, S3, and D1, D2, D3 if you want to.

In teleop, your code needs to return to the scheduler every 20ms or so. The delay block prevents this until the delay is over, meaning that your joysticks will be frozen for a few seconds. The way to code this in teleop code is not obvious, but a trick well worth putting in your tool chest. It is called a state machine. You code it by Setting the motor and noting when you started it. You update the state to Running A and let the function finish and return to the scheduler. Each time teleop is called, you check to see what state you are in. If in state A, you compare the current time to start time to see if 0.25 seconds have passed. If not, leave it alone. Once 0.25 seconds have passed, you change the motor speed and set the state to B and let it return. B does the same time compare and eventually goes to state C where it stops the motor.

The third option is to put the code into Periodic Tasks and let auto and teleop communicate to it. When in Periodic Tasks, you can write it simply, like autonomous, but you put it in a mechanism loop so that it is started/stopped/canceled by a global or other communication mechanism. This is actually the approach I'd generally recommend, and I attached an image of the general code that would be pretty easy to duplicate and set to other mechanisms. The other case handles stop and delays for 20ms. Look through the code and see if you see any issues or have any questions.

Greg McKaskle

[ctccromer]

That's very helpful, thanks! I'm trying to copy that into my periodic tasks but I don't recognize a few of those VI's. What is the array looking thing on the left? and the Start and Mechanism Op VI's? Also, I put it inside a While loop, but I don't see the slot at the top where "Go" is in your picture either
Thank you very much for the help :)

EDIT: i compiled a video of our progress so far. Everything coded in the video has been done with your help here and I just want to thank you very much! Here's the video if you'd like to see (http://youtu.be/muhzq_TwARc)

[Greg McKaskle]

The array looking thing is an array constant. In it I put a cluster constant and two numeric constants inside that. The array constant comes from the Array palette, Cluster from Cluster palette, etc.

The Mechanism Op is a global variable. You should probably open Robot Globals from the palette and add it there, but if you wish, you can make a new file to organize your globals into. The Global I added is an enum, largely because of readability, but a number or Boolean would also work, even a string.

The slot at the top is the border of the Case structure.

Reading the code from outside to inside, it is a While Loop, a Case Structure, then a For Loop, and a Sequence inside that. Do each of them make sense what they do and why they are being used?

Greg McKaskle

[ctccromer]

I still can't find Stop or Mechanism Op. (tried going to global data.vi file but ctrl+e didnt bring up a block diagram and I couldn't figure out how to get it from the right click menus). What kind of vi is Stop?

Does it matter if my case structure says True/False instead of Go?
Does it matter if my variables in the array don't have labels on them?

Other than that, I think I've got it. Once I finish setting it up, I'll dive in and learn what each thing does. Attached what I have so far

[Alan Anderson]

I still can't find Stop or Mechanism Op. (tried going to global data.vi file but ctrl+e didnt bring up a block diagram and I couldn't figure out how to get it from the right click menus). What kind of vi is Stop?

The Robot Global Data vi only has a front panel. There is no associated block diagram. Global variables are just controls on the vi's front panel. When you want to create a new global variable, just place a control of the appropriate type there. "Mechanism Op." is a global variable that Greg created for the example. "Stop" and "Go" are values of an enumerated data type that he created to make it easier to read the intent of the values. You can just use a boolean with values of True and False if you don't want to dive into enumerated types yet.

http://www.fightingpi.org/Resources/Controls/Labview%20Resources/labview_tutorial/FIRST%20Documentation/FRC%202012%20Robot%20Framework%20Tutorial.pdf has some tutorial information about using global variables at the end of the document.

[ctccromer]

So by creating an enum on the Front Panel of Global Data.vi and renaming is Mechanism Op, I got it in my code. After wiring this up in the 3 places shown, the True/False changed to 1/0

Still not sure how to get the Stop thing.

Once I finish this (and understand how it all fits together), is it just a function I can call in any other files in the project? How do I use it in teleop and autonomous?

[Alan Anderson]

So by creating an enum on the Front Panel of Global Data.vi and renaming is Mechanism Op, I got it in my code. After wiring this up in the 3 places shown, the True/False changed to 1/0

Still not sure how to get the Stop thing.

Edit the properties of the enum and give it named values of "Stop" and "Go".

Once I finish this (and understand how it all fits together), is it just a function I can call in any other files in the project? How do I use it in teleop and autonomous?

The code Greg suggested goes in Periodic Tasks. Any time you want to trigger it, set the global variable to True (or 1, or Go, whatever you end up using). You can do that from any vi in the project.

[ctccromer]

how do you put the blue Stop thing though?

EDIT: Is there one of these VI's that is a MOTOR vi, not a DRIVE vi? That would make things WAYYYYYYYYYYYYYY simpler, and easier to understand. Pic attached

[Alan Anderson]

how do you put the blue Stop thing though?

After you've placed the enum control, right-click on it and choose Properties from the popup menu. Select the Edit Items tab. You can insert new items and rearrange the items in the list. The "Items" column holds the name of the enumerated values; you can double-click on one and edit it to be whatever you like. Greg picked "Stop" and "Go" for his example.

EDIT: Is there one of these VI's that is a MOTOR vi, not a DRIVE vi? That would make things WAYYYYYYYYYYYYYY simpler, and easier to understand. Pic attached

You don't need a combined "drive and delay" vi for a motor that has the safety disabled. Just put a Delay in the frame next to the Motor Set Value.

[ctccromer]

The only timing VI's i found besides that one are all seemingly independent. The one attached above wires directly to a drive system. So I need one to wire directly to a SetMotorOutput vi. Or if not, then I don't know how to use one. Once again, all I'm trying to do is:
1) Send a motor control the value of -1
2) Wait 0.25 seconds
3) Send a motor control the value of 1
4) Wait 0.25 seconds
5) Send a motor control the value of 0 (and leave it that way until I call this function again)

[Alan Anderson]

...I attached an image of the general code that would be pretty easy to duplicate and set to other mechanisms. The other case handles stop and delays for 20ms. Look through the code and see if you see any issues or have any questions.

Greg, shouldn't that last frame be after the For Loop? You don't want to Stop execution after each set/delay; you want to Stop after they're all done.

[Greg McKaskle]

Yes. Reset the global after the planned movements are complete.

Greg McKaskle

[ctccromer]

I finally figured out the sequence. It was actually much easier than we were making it.

But now I'm starting to get into Autonomous programming. I think I understand the coding part of it fine, but I do have a few questions about the general use of Autonomous mode:
1) I was told you can have up to.. I think it was 10? different Autonomous modes. At competition, how do I choose one before the match starts?
2) When practicing during the build season, how do I simulate the Autonomous mode part of the game? Do i change the drive station to Autonomous, Enable, and after 15 seconds it will automatically flip over to teleop, or is it more complicated than that? I'm unable to test anything with our robot at the moment but I also don't want to accidentally mess anything up

Thanks!

[Mark McLeod]

There isn't a limit on the number of discrete autonomous routines you write.

You can choose the mode to run from the Driver Station, using the I/O tab, or wired selectors, or by choosing with a button press or a sequence of presses.
You can install a switch on the robot itself to choose between autonomous modes. Switch values are available in your cRIO code. Lots of options.

Choosing Autonomous mode on the Operation tab will just run Autonomous mode as long as it's enabled. No time limit is imposed.

Using Practice mode will by default go through a typical field cycle of Disable/Autonomous/Disable/Teleop/Disable. Options are provided on the Setup tab to adjust the times, so for instance you can reset the Teleop period to be 0 seconds if you don't want to bother with that mode, but still get the Autonomous time limit and other transitions.

[ctccromer]

Awesome, i played around with the drive station and understand that part.

Still a little confused how I can tell the drive station or robot to pick (ex) Autonomous Mode 2 of 5. So if we wanted we could have an Auto Mode for the back of the period and the front, and choose between them at the last minute.

EDIT: Also so y'all know, I'm planning on making a video (after build season ends) where I go through our robot's entire code and explain absolutely everything I can. This way anyone that's in the position I was/am next year will be able to watch it and learn a ton without having to ask a million questions like me :)

[ctccromer]

Still a little confused how I can tell the drive station or robot to pick (ex) Autonomous Mode 2 of 5. So if we wanted we could have an Auto Mode for the back of the period and the front, and choose between them at the last minute.

And also how to separate multiple Autonomous Modes in the programming

[Alan Anderson]

Still a little confused how I can tell the drive station or robot to pick (ex) Autonomous Mode 2 of 5. So if we wanted we could have an Auto Mode for the back of the period and the front, and choose between them at the last minute.

Either use the Dashboard to set a value that you then read on the robot using the SmartDashboard functions, or just use what's on the I/O tab of the Driver Station.

And also how to separate multiple Autonomous Modes in the programming

Turn Autonomous Independent into a single large Case block. Put each mode's code in a separate case and use the value you receive from the Driver Station (or the Dashboard) to select which case gets executed.