paper: Killer Bees BuzzXVI Code and Auto Scripting

CD-Media: Papers
, , ,
#1

Thread created automatically to discuss a document in CD-Media.

Killer Bees BuzzXVI Code and Auto Scripting
by: apalrd

Complete code of BuzzXVI, the Killer Bees’ 2011 robot. Written in LabVIEW. Also includes the Beescript autonomous scripting system used by BuzzXVI.

Buzz16.zip contains the complete code of Buzz16, written in LabVIEW. I went through it a little bit to clean it up, but is is mostly as it finished the season in St. Louis. Most of the Dashboard code was obsoleted by various laptop changes, but it is still there for all to see. Features include a state-machine for the elevator, with handling of current states and special conditions when exiting states, a drivetrain system including closed-loop speed control, camera targeting using a CMUcam (commented out, but it did at one time work), automated transmission shifting (downshifting was disabled at the request of the driver), automated DualDrive lifting, arc control, and many features never used in competition.

beescript.zip contains just the Beescript interpreter and a PDF describing how to use it.

WPIlib_mods.zip contains the modifications to the WPI library which are required to compile this code. Changes include gyro handling and battery voltage accessibility.

This also requires OpenG-Boolean Trigger, OpenG-Data Changed, and the Encoder Workaround (or a cRio image with working encoders)

Buzz16_PostCMP.zip (5.93 MB)
Beescript.zip (186 KB)
WPIlib_mods.zip (67.2 KB)

#2

Just like last year, I am releasing my code to the ChiefDelphi community. This code was written entirely by me, with lots of guidance and help from my mentors (especially Jim and Eric). I also included a stand-alone version of my Beescript autonomous interpreter which we used during this past season to speed up autonomous updates.

Questions?

#3

There were a couple vi’s missing, something from an openG directory that was used to detect change in some data. Looked at it this weekend, very nice documentation and breakdown of work. But I don’t have the specifics here at work.

We are loosing our two senior programmers this year, and only have 2 freshman interested. Have you ever thought of doing a training class?

What was the “root cause” for the bias needed? Seems mechanically, not required.

Also, can you publish your sensor parts list used, we had issues with the KOP encoders not being very robust.

Again, Great Year, very impressive!

#4

  1. The OpenG Boolean Trigger and OpenG Data Changed VI’s are required to run. They’re not very complex VI’s but I had them and they were nice to use.

  2. The bias in drive_straight is actually not used. We initially used that to control drift, and it worked fine as long as we didn’t change anything, but the slightest mechanical differences required us to re-tune it. We now use the gyro compensator to dynamically handle drift which works amazingly.

  3. We used the 250-count AM encoders (just like the kit encoders) on modified SuperShifters, a previous KOP 150 deg/sec gyro (although the practice robot used the current KOP gyro 250deg/sec and it worked very well), a 270-degree pot on the wrist, and a 10-turn pot on the elevator.

  4. There are a lot of legacy VI’s in the autonomous system. As we added new features we wanted to keep our old routines working, so we have commands like DRIVE_GYRO_TURN_OLD, DRIVE_GYRO_TURN_BASIC, and DRIVE_GYRO_TURN to handle turns differently. The old one is the original turn code, BASIC is a modified version which is more accurate, and the plain one does a slower (only moving one side of the drivetrain) but much more accurate turn. Only the plain turn updates the heading target of the drive_straight. Likewise, DRIVE_STRAIGHT_BASIC just drives, while DRIVE_STRAIGHT does realtime drift compensation with the gyro.

#5

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

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.

#6

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

#7

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

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.

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.

#8

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.

#9

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. :slight_smile:

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.

#10

oh, yeah, call.vi…

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

#11

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:D

#12

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

#13

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. :slight_smile: )

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.

#14

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

#15

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.

#16