Automous Programming

[professorX]

I need help finishing programming Autonomous mode. I want the robot to move forward in increments of .2 until it reaches to 1 for 8 seconds. Then, I want the robot to turn in increments of .2 until it reaches to 1 for 7 seconds.

It is tank drive and the jaguars are not flip so 0.2 for the left value and -0.2 for the right value will make it move forward.

Can anyone help me finish this?

[Stuart]

ok let me ask you a question.

how fast will this code get up to 1

as fast as it can. you see your for loop has no delay and your sequence has no delay either

start looking in to time delays ( it looks like a stop watch).


PM me if you have any other questions.

[professorX]

I want it reach 1 in 8 seconds and then turn for 7 seconds. I was looking at time delay but I'm not sure how it would work.

[Caroline2399]

Yeah, you will definitely want a time delay in there. The only tricky thing about using a normal one is that your watchdog will time out (I experienced some problems with that earlier this season). So, what you will want to do is insert one of those watchdog "delay and feed" VIs with the delay input set to however many seconds you want your code to run for.

It looks like in your first frame of the sequential loop you would want a constant set to 1 (or however many seconds you want it to run at each increment of .2) for the delay time, and set "N" to 7 or 8 depending on how many seconds you want it to take. Then repeat that same kind of format for the second frame.

Just as a side note, currently the last Watchdog delay and feed that you have outside of your sequential loop looks to me as if it is not going to be doing anything.

If you have any more questions feel free to PM me.

[professorX]

So it would be like this? But one problem that I had with this code is that the robot would try to go forward for maybe 1 second and then turn or it would try to move forward and turn at the same time.

[Caroline2399]

I'm not sure as to why that code isn't working, but here are my suggestions for troubleshooting it.

My first suggestion for this would be to wire the error from the drive VI to the Delay and Feed VI in the same frame.

I noticed that you had the constant "N" value for the first frame defined outside of the sequential loop, I don't know why it wouldn't work where it is currently, but maybe try moving it inside there.

Also, maybe try turning the auto-indexing off for the tunnels outputting and inputting the Watchdog Reference and the Drive Ref. And, try for the second "Delay and Feed" VI taking the reference from the output of the first one. Again, I don't know why this would make a difference, but LabView can be odd like that sometimes.

I hope this is able to help, if you still have the same issues, let me know, and I'll see if I can come up with any other methods you could use to troubleshoot the code.

[Greg McKaskle]

We can't tell what the polarity of your motors are or how they are mounted and geared. But your first loop is doing the same as moving one joystick forward and the other backwards. The second loop moves them both backwards. It may seem odd that pushing the joystick forward is negative numbers, but that is the way that HID devices are defined, and that was the standard chosen for the joystick library.

So my prediction is that the robot increases the spin speed for eight seconds, then sets the motors to slow backward and increases speed backwards for eight seconds.

Another thing to think about is how the robot drives using the joystick. After four seconds, your loop will effectively have the joysticks maxed out. Does that match what your human driver would do? It seems like you may want to try a smaller increment so that you wind up at the same point as the human driver.

To clean up the code a bit in readability, you can right click on the outer case and Remove the case. You can also do that to the sequence structure. You can right click on the output tunnels on the first for loop and disable the auto-indexing.

Greg McKaskle

[EricVanWyk]

I strongly recommend making your code clearer by using the Arcade Mode VI during autonomous. It is easier to understand and code for (IMHO). For me, Tank is easier to drive but Arcade is easier to code.

To do so, you will need to invert that motor. I always "force" my programmers to fix things as soon as possible. In your case, you can fix it by using a -.2, or you can fix it by inverting that bit. The bit is sooner, which means you have to worry about it less. Less worry is more better.

[gwytheyrn]

Meh, I disagree, since for tank drive, you're essentially setting the motor values yourself, whereas arcade it's processed by the arcade vi (note: i say essentially).

just out of curiosity, try the attached code...It uses a different structure and does it in a smaller steps (time and motor value), but should have the same overall function. The positives and negatives might be flipped around as previously mentioned though

[Greg McKaskle]

From the little exerience I had in DC, I think there is benefit for using the same drive version or both tele and auto. That allows the auto code to replicate driver actions. True, if you can visualize the joystick maneuver either way, then I also prefer arcade for auto, but the important thing to me is that the person writing the auto can pretend they are setting the joystick and build code to replay that.

Perhaps someone would like to build a recorder for a drive session and play that back using an array of setpoints?

Greg McKaskle