![]() |
General LabVIEW questions from a VERY new user
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 My first question: see this pic 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 Code:
Team Code file |
Re: General LabVIEW questions from a VERY new user
While waiting for the picture to get posted...
See if any of this training stuff helps:
- 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. |
Re: General LabVIEW questions from a VERY new user
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. |
Re: General LabVIEW questions from a VERY new user
Quote:
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 Quote:
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? |
Re: General LabVIEW questions from a VERY new user
Quote:
Quote:
Quote:
Quote:
|
Re: General LabVIEW questions from a VERY new user
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 |
Re: General LabVIEW questions from a VERY new user
The triggers on game controllers are axis.
You can depress them halfway for half power. |
Re: General LabVIEW questions from a VERY new user
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/sh...ighlight=d-pad |
Re: General LabVIEW questions from a VERY new user
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 |
Re: General LabVIEW questions from a VERY new user
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!
|
Re: General LabVIEW questions from a VERY new user
1 Attachment(s)
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
|
Re: General LabVIEW questions from a VERY new user
Try changing your motor Get Output VI to a Set Output VI. That should help with figuring out where to wire in the axis.
|
Re: General LabVIEW questions from a VERY new user
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.
|
Re: General LabVIEW questions from a VERY new user
2 Attachment(s)
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? |
Re: General LabVIEW questions from a VERY new user
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 |
Re: General LabVIEW questions from a VERY new user
1 Attachment(s)
Quote:
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! |
Re: General LabVIEW questions from a VERY new user
"Set Motor Output" is what you are missing.
For example: ![]() |
Re: General LabVIEW questions from a VERY new user
2 Attachment(s)
Quote:
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) |
Re: General LabVIEW questions from a VERY new user
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 |
Re: General LabVIEW questions from a VERY new user
1 Attachment(s)
Quote:
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 |
Re: General LabVIEW questions from a VERY new user
1 Attachment(s)
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 |
Re: General LabVIEW questions from a VERY new user
1 Attachment(s)
Quote:
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) |
Re: General LabVIEW questions from a VERY new user
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 |
Re: General LabVIEW questions from a VERY new user
Quote:
|
Re: General LabVIEW questions from a VERY new user
1 Attachment(s)
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! |
Re: General LabVIEW questions from a VERY new user
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 |
Re: General LabVIEW questions from a VERY new user
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 |
Re: General LabVIEW questions from a VERY new user
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 |
Re: General LabVIEW questions from a VERY new user
2 Attachment(s)
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 |
Re: General LabVIEW questions from a VERY new user
1 Attachment(s)
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 |
Re: General LabVIEW questions from a VERY new user
Quote:
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. |
Re: General LabVIEW questions from a VERY new user
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)? |
Re: General LabVIEW questions from a VERY new user
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 |
Re: General LabVIEW questions from a VERY new user
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, 2, and 3) 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" |
Re: General LabVIEW questions from a VERY new user
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 |
Re: General LabVIEW questions from a VERY new user
Quote:
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? |
Re: General LabVIEW questions from a VERY new user
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 |
Re: General LabVIEW questions from a VERY new user
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
|
Re: General LabVIEW questions from a VERY new user
1 Attachment(s)
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 |
Re: General LabVIEW questions from a VERY new user
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 |
Re: General LabVIEW questions from a VERY new user
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 |
Re: General LabVIEW questions from a VERY new user
1 Attachment(s)
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 |
Re: General LabVIEW questions from a VERY new user
Quote:
http://www.fightingpi.org/Resources/...20Tutorial.pdf has some tutorial information about using global variables at the end of the document. |
Re: General LabVIEW questions from a VERY new user
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? |
Re: General LabVIEW questions from a VERY new user
Quote:
Quote:
|
Re: General LabVIEW questions from a VERY new user
1 Attachment(s)
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 |
Re: General LabVIEW questions from a VERY new user
Quote:
Quote:
|
Re: General LabVIEW questions from a VERY new user
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) |
Re: General LabVIEW questions from a VERY new user
Quote:
|
Re: General LabVIEW questions from a VERY new user
Yes. Reset the global after the planned movements are complete.
Greg McKaskle |
Re: General LabVIEW questions from a VERY new user
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! |
Re: General LabVIEW questions from a VERY new user
1 Attachment(s)
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. |
Re: General LabVIEW questions from a VERY new user
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 :) |
Re: General LabVIEW questions from a VERY new user
Quote:
|
Re: General LabVIEW questions from a VERY new user
Quote:
Quote:
|
| All times are GMT -5. The time now is 01:33. |
Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi