Can you use the autonomous code as is? I think in our case we have to change to the tank drive, but besides that will it do anything or does it need more. I am just looking to see if it will drive forward, without making changes. We are going to test on blocks, but was wondering what to expect. It looks like it will but I am not sure. If it does that then we can adjust it to turn, etc.
Thanks.
It should work, as is, but you must at least toggle the True/False input on the left to “True” allowing it to run.
You don’t even have to change to Tank Driver from the default Arcade Drive.
Autonomous doesn’t care how you command it, and there are no joysticks anyway in autonomous.
It only runs for about 5 seconds rather than the full 15 seconds of autonomous.
You can fix that simply, by changing the “4” in the upper left to a 12.
You probably do want to add a little variety in the form of a turn or two.
Thank you so VERY much…
I certainly hope they offer more courses this summer and fall on using this with the FRC. I attended three all day trainings this Fall and can make Labview do all kinds of things from a math point of view, but taking that and making it work with motors, electronics and other things is much more difficult. I would pay for a class or training materials to help learn how to tie these together and understand the whole picture. Given the number of threads about the programming, I think I am not the only one.
Thanks for making this easier for us.
How do you make a turn.
If I understand it correctly -0.5 drives forward and 0.5 drives backward???
How do you make it turn?
Thanks for all the help.
The Arcade drive has a second input (X-axis value), that isn’t used in the example, but defines the turn amount. An x-axis value of 1.0 for instance will make your robot turn in place. -1.0 makes it turn in the opposite direction. In between values will make it drive in an arc.
Hover the mouse over the left edge of the Arcade Drive icon and you’ll see an unattached x-axis. right click and choose constant to give it a value (0 is the default when nothing is attached).
If you choose to switch to Tank Drive then a turn in place would be .5 to one side and -.5 to the other.
Should the drive forward numbers be 1.0 and -1.0 or is the -0.5 for forward correct (as in the example).
That’s close enough for people who already know how the Arcade Drive works, but it’s not perfectly correct. The robot will try to spin in place with any nonzero x-axis value if the y-axis value is zero. To drive in an arc, add an x-axis-controlled spin to a y-axis-controlled forward or reverse drive.
Yes, negative numbers on the y axis mean forward. That’s because the joystick standard has negative forward and positive backward, likely because it was defined with flight simulators in mind.
Alan’s probably answered part of your question.
The x-axis is just the turn speed, and the y-axis adds the forward or reverse speed to get an arc.
With the trailers behind the robots this year you’ll probably want to do some sort of arc (mixture of x & y axis), but full speed (1.0 or -1.0) will probably be too much for the slick floor and wheels. I’d imagine you’ll want to start on practice day with about half speed for both until you see how your robot really behaves. Then raise or lower the speed based on what you see.
Here is what I have…
I do have an x and y value. If I understand it, the first will make a slight turn one way and then a slight turn the other way and essentially end up straight?
How often does the watchdog need a feed?
Thanks.
Autonomous Independent.vi (23.7 KB)
Autonomous Independent.vi (23.7 KB)
That’s the idea.
If I remember correctly -x will turn to the right and +x will go left.
In practice, because of possible spin out as your robot gets up to speed, I bet the turns won’t quite even out. The earlier turns will lose ground and the later turns will be more efficient. But then you’ll run into another robot or trailer and everything gets thrown off anyway. 
Just keep moving.
The WatchDog Delay & Feed takes care of everything to do with WatchDog timing for you. That vi tells the WatchDog to delay and to feed itself as often as necessary while it’s causing the delay.
Thanks so much.
We will be moving, moving, moving… I hope.
I neglected to mention that the turns also don’t even out because you’ll be turning in one direction for 2 seconds and in the opposite direction for only 1 second.
That’ll essentially give you an overall arc to the right I think, but so slight that you might end up in your opponents corner. Of course, you’ll be running into the robot coming out of that corner way before you get there.
To end up straighter you’d go one way for 1.5 seconds, then the other way for 1.5 seconds to even things out.
But that’s probably overthinking it all anyway.
On the regolith is it known how long it will take to get from one end to the other? We could not afford it and had no playing field available to us.
If I started in the lower right corner and went slightly left then straight and then slightly left, etc. I am hoping to go to about mid field or so. As long as I am pointing toways the other end when I am done so my trailer is not to the other teams in the other alliance.
Move, move, move…
The ground your robot can cover depends too much on the gearing and wheel slip to know for sure. With no other robots in the way you’ll probably make it the whole length of the field during the 15 seconds. But since there are four other robots with trailers in that direction, as well as the robot coming from the left corner, I imagine we’ll all end up in one big traffic tie-up in the center.
You probaly want a variation in your autonomous to account for the three possible starting positions. Keeping what you have you can simply duplicate that loop twice more. Then vary your power and times in each for your best guess, e.g., if what you have handles one corner, then just reverse the numbers in the second autonomous for the other corner.
Once you agree on starting positions with your Alliance partners for a match, you can quickly switch between auto programs just by using that True/False switch on the left. True for the corner you’ll start in and False for the others.
Can you just highlight to copy them? Do they just go one under the other like the Basic Robot Main has three loops?
If we are not using the other two loops in the Basic Robot Main can we just delete those?
Thanks so much.
Yes, you can just highlight everything and paste it a couple of times.
Just like the three separate loops in Basic Robot Main.vi
Do make sure that only one of the loops is active at any time. It could get pretty random if two were active at the same time.
An alternate is to drop all three into an enumerated case statement, so only one can possible be active.
In Basic Robot Main.vi you can delete the camera and periodic loops if you aren’t using them.
What does the periodic loop do?
We are not using a camera.
I’ll try turning two off as I am not sure how to do the enumerated case statement yet. More lessons to learn…
The periodic loop doesn’t do anything the way it comes.
It’s an empty template for users to see how to add something that requires a very regular, timed period. Something that has to be clocked, such as, collecting sensors requiring a particular frequency or oscillation. Feedback control loops might require a regular period to work predictably.
Doing the three loops is a good place to start. It’s easy to visualize what’s going on. An enumerated case is a variation on that, but time enough for that later. These three loops can easily be moved into a case statement at a later time.
P.S.
The next step would be to convince you to add a 3-position switch to your robot, so you can decide on the fly…