paper: Killer Bees BuzzXVI Code and Auto Scripting

[tr6scott]

We tackled using the gyro and a proportional loop to do the turns and tuned the gain, here is our proof.

http://youtu.be/3Q_lrvty8Ig

We spent yesterday going through the drive straight gyro code, and could use a little help with the Arc Drive.vi

What does the 5.43 constant represent? Is that the max speed in FPS of the bot in that gear?

It looks to us, that the throttle is divided by that “range” which gives a fraction of top speed, or essentially the motor controller output, 0 to 1. The “wheel” comes from the gyro error, times a gain kp, then is scaled by the “fraction of top speed” and added to throttle. Throttle is speed calculated by the position error to target * gain…

We are still a little foggy on what the range of values of “wheel” should be and how they relate to the 5.43 number.

Thanks for the help, good luck this season, look forward to seeing the Bees again in 2012.

Scott.

[apalrd]

Are you looking through the drive-straight autonomous functions?
Those are quite complicated.

The 5.43 is the max speed in low gear

The algorithm work like this:
-We calculate a proportional term to drive straight
-We apply it using the arc drive code which proportionally applies the term based on the output forward speed (which is in ft/sec)
-If the speed drops below a threshold, we latch the p term because the algorithm is unreliable while we slow down or speed up.

Clarification on wheel:
-We've been looking at various HMI's, and in many arcade and halo drives, a throttle stick and steering wheel are traditionally used, leading us to refer to inputs to an arcade drive as 'throttle' and 'wheel', even in the absence of an actual steering wheel

[tr6scott]

Originally Posted by apalrd

Are you looking through the drive-straight autonomous functions?
Those are quite complicated.

Yes, but that is where the Magic happens! (and it's a lot less complicated when you know it works.)

Originally Posted by apalrd

-We apply it using the arc drive code which proportionally applies the term based on the output forward speed (which is in ft/sec)

Ok, I get it now, you have to tune the gyro gain to work a full throttle. Then you scale gyro P(id) contribution to the output bases on the speed you are actually moving at.

Originally Posted by apalrd

Clarification on wheel:
-We've been looking at various HMI's, and in many arcade and halo drives, a throttle stick and steering wheel are traditionally used, leading us to refer to inputs to an arcade drive as 'throttle' and 'wheel', even in the absence of an actual steering wheel

Makes perfect sense, I tripped up thinking wheel was a robot wheel, not a steering wheel. I have only seen tank drives, makes sense as an arcade drive.

What was the value of the gyro p gain you used? When we tuned the gain for the rotation we ended up at .006 but our algorithm we added minimum constant, which was the threshold minimum motor value that it took to move the bot. I saw how you solved this just by telling the bot to go farther than it needed to, with the addition of the "overshoot" distance. Nice simple solution.

In our turn to heading, we are exiting the loop when the error has settled for a second, at less than .5 degrees. This allowed the bot to overshoot and correct, at the end of the video you can see it jiggle a bit, that is it correcting for the overshoot.

[apalrd]

When we do turns, we settle after ~200ms of sitting inside of the +-3deg exit threshold, and reset the counter if we are outside of that area.

We correct for the +-3deg of error in the drive straight, which brings us back to virtually no error (less than a degree, usually less than half a degree).

We had to do this to be as fast as possible, because of time constraints in the routine (we finish about 14.5s after auto starts).

The turn we do drives only the outer wheel for accuracy. We also have a fast turn which turns with both wheels and stops when it gets to or past the target (just killing the output power instead of overshooting), we use the fast turn as the first turn in the 2-tube routine, which turns from the backup to get the second tube. We are much more tolerant of error in this turn, and will compensate for this error later in the second turn and drive.

[tr6scott]

Howdy, me again...

Hope your season is going well, I am trying to get someone to look at beescript, on our team. I saw how easily you were able to adjust auto programs last year at Kettering, and really see the value of this approach.

In looking at the beescript standalone file, in the createcommands.vi there is a reference to call.vi, and there is no call.vi in the code. Is that a required vi or can that just be deleted like any other commands in the "scrptlib" folder that is not needed.

Thanks for all the help thus far, we are making some huge strides this year, working with your code from last year, understanding it, and writing our own for our use. I am a PLC programmer by trade, and LV is powerful, but requires learning.

We have been able to ultilize the encoders for distance, drive straight forward with the gyro, (although backwards has some issues) and use encoder p loop to hold on the ramp when the drivers release the sticks. Considering we never had an encoder on the bot until this year, I'd say we have made some huge strides in programming. Look forward to seeing the bees at Kettering, and what you have cooked up this year.

[apalrd]

oh, yeah, call.vi....

call.vi is an artifact from an earlier version of the code. Feel free to delete the command for it.

[tr6scott]

As we were looking through the code you gave for auton scripting and the code you used for competetion, we saw that in the scripting example the CreatCommands.vi was outside the Auto_Initalization.vi , but in the code you used at competetion you had the CreatCommand.vi inside the Auto_Initialization.vi. Why is this? Any help would be appreciated, Thanks

[apalrd]

The scripting example setup commands and auto init (sensors) as different things. No real reason.

[tr6scott]

Ok, We got it working yesterday. I am the mentor, and did not dig into the code, to research the issue we were having, but I wanted to post incase someone else uses the code, and so you know of the issue we tripped up on. It seems there is a problem with passing non-integer data between the script to the code. In our drive straight command, we are choosing the motor speed drive at, the raw -1 to 1 motor speed. So in our script one of the arguments is 0.5 for motor speed.

The code that populates the driver station message box, says that it read 0.5 and everything was good. But when we probed the data in labview, it was either a 0 or a 1. We then made the data in the script 50 and in the adjusted the labview code to divide the speed value by 100, we got it to work and drive at 50% speed as intended. (This was not the only error made this weekend, there were many others that were self imposed. )

I am guessing that the message box is populated with the string values from the script file and not from the converted string to fixed (or interger) data the labview code is seeing.

Thanks again for sharing, and responding to all the questions, we now have our torc drive straight auto and wait working in beescript, now to get the turns done. We could not have done it without your help.

Scott McBride.

[tr6scott]

One more question...

Where do you tell the code how many parameters are passed from the script file to the command cluster/array?

We added additional data to the drive_strait script file but it does not read back through the dashboard. I was thinking that you would be creating the parameters on the fly from the script file, parsing until the end EOL character was found, but it appears that is not how it works.

Scott McBride

[apalrd]

My guess is that you are exceeding the character limit for the line of the Driver Station and it's getting truncated. That display does not line wrap, it truncates extra characters.

If you open Execute File, there are several VI's which do the actual processing of a file into arrays of lines and later arrays of arguments. I believe the first one is read_auto_file and the second is part of ExecuteCommand.

It's never explicitly defined how many arguments to expect. The interpreter passes all arguments to the command and lets each command deal with it - Some do, some don't.

For the actual breaking up into lines, it first breaks them up by newline into an array of lines, then FOR's through each item. If it's not a comment or blank line, it executes the command on that line. That VI breaks up the line into an array of strings separated by spaces. The first one is the command name, the rest are arguments. It finds the command with a matching name to the command called, and calls it with an array of arguments.