paper: Killer Bees BuzzXVI Code and Auto Scripting

[apalrd]

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

Killer Bees BuzzXVI Code and Auto Scripting by apalrd

[apalrd]

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?

[tr6scott]

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!

[apalrd]

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.

[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