paper: Killer Bees BuzzXVII 2012 Code
 

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

Killer Bees BuzzXVII 2012 Code by apalrd

Re: paper: Killer Bees BuzzXVII 2012 Code
 

As in past years, I am releasing the Killer Bees 2012 code post-championship.

Major changes for this year:
-Beescript improvements to allow us to write "ScriptButtons" using a single threaded interpreter (a lock on the interpreter, and the ability to forcefully kill the interpreter if a higher-priority script must run). We intended to use this for auto-balance scripts, but never did. The functionality is still there, but unused. See the Script Buttons VI in the HMI folder for an example of use.

-RT thread for the gun speed controller - See gun_speed_control_feed_forward.VI in the gun folder for a description of the final algorithm, and the other tested algorithms (they're commented out in that VI so you can quickly find them all). I wanted to include the data we used in determining which controller was best, but the data files pushed the zip over a magic 8mb file limit on CD Media.

-Signals system allows me to send boolean triggers and have multiple subsystems trap the signals. I initially wrote Signals like UNIX signals, where each subsystem could register a callback function, but later decided I didn't like this, so I wrote the signal manager and signal trap as you see it now. Each instance owns it's own trap, so multiple traps of the same signal will not cause race conditions where only one will get the signal. The implementation is fairly generic, this system was designed to be re-usable.

As usual, feel free to ask questions or state comments.

Re: paper: Killer Bees BuzzXVII 2012 Code
 

Hey Palardy, I had a few questions I couldn't really solve when I went through your code.

Why do you have the linear ramps on your drivetrain?

What is it that the halo drive is doing? I can't recall your driver setup, though I thought it was tank drive with a normal left and right stick setup.

Can your simple set be used as a drop-in replacement for NI's motor set (assuming use of pwm and not CAN)? Have you had any problems with it? We're seeing fairly high cpu utilization as well, and I'm curious how much that will help since the sets are called quite often.

Re: paper: Killer Bees BuzzXVII 2012 Code
 

-The linear ramps are used to reduce fast shock load to the drivetrain in an attempt to reduce high current spikes (hopefully reducing main breaker heating). We later increased the ramp constants fairly high, they don't ramp much now.

-The HMI we used this year has the left Y as "Throttle" and right X as "Wheel" in the halo drive. The idea is to run an Arcade-type control with the throttle and wheel controls on different sticks. The Halo algorithm we use is a mix of 254's Cheesy Drive algorithm with some additional logic to switch to "quick turn" mode when the throttle is near 0. We also used a similar system in Occra and Vex, and all of our drivers prefer two-stick Halo over two-stick Tank.

-Simple Set is a drop-in replacement for Set Motor under these conditions:
--You can't use CAN
--You *MUST* have created the motor before attempting to set it, as this version does not check if the motor has been created properly
--I removed all of the Safety Watchpuppies
-We have had no issues with the Simple Set VI.

Re: paper: Killer Bees BuzzXVII 2012 Code
 

A comment on Palardy's implementation with Cheesy Drive and Halo Drive:

Halfway through competition season (I believe after week 4), Palardy graciously gave us these VIs, and we implemented them almost verbatim (we added our own ramping software at the inputs). I won't comment for our driver, but when I used it occasionally at home, it was better than tank (my previous favorite). It seemed more natural for locating the robot precisely where you wanted it, and at the orientation you wanted it.

Thank you very much Palardy!

Re: paper: Killer Bees BuzzXVII 2012 Code
 

Love the quote under your name. I understand they're making an Ender's Game movie.

Anyway, regarding the drivetrain, that's good to hear. I think I'll go through tonight and take a closer look and try it on ours. We really don't have any trouble with just straight unfiltered tank drive (wide bot tank drives almost drive themselves if done right) but it'll be a good learning experience.

Re: paper: Killer Bees BuzzXVII 2012 Code
 

Cheesy drive is wonderful. (We've used it the past two years.) Especially in high gear, it blows traditional tank out of the water.

What criteria do you use to switch to quickturn? Do you smooth the transition? (I'm not at a LabVIEW capable computer at the moment, but the next time I am I'll take a look.)

Re: paper: Killer Bees BuzzXVII 2012 Code
 

No smooth transition, it's literally just a binary wrapper around a standard CheesyDrive function. The transition happens when abs(throttle) is <0.2 (basically 0).
With the thumb sticks, it's really hard to get a precise throttle that low without hitting the 0.15 low-end deadband, so we don't care about the transition.

If you look at the implementation, HaloDrive does the wrapping and quickTurn switch decision, and CheesyDrive does a standard 254-style Cheesy Drive with a quickTurn switch input. You can use either, we like Halo.

Re: paper: Killer Bees BuzzXVII 2012 Code
 

It is worth mentioning that Palardy was also the driver this year. While it was his first year, he did have experience driving both the 2010 and 2011 robot for a couple of competitions as well as VEX and OCCRA.

Re: paper: Killer Bees BuzzXVII 2012 Code
 

I don't have Labview. What does the logic for activating quick turn look like?

Re: paper: Killer Bees BuzzXVII 2012 Code
 

quickturn = 0;
if ( abs(throttle) < quickturn_thresh)
quickturn = 1;

quickturn thresh is about 0.2 off the top of my head.

Re: paper: Killer Bees BuzzXVII 2012 Code
 

I WILL comment here. As Colin said, we used standard Tank Drive for the Kettering University district and the Northville district competitions, before switching to the Halo Drive/Cheesy Drive for MSC and Championship.

I drove the 2011 robot at four off-season events (IGVC, MARC, IRI, and Kettering Kickoff) with standard two-stick tank drive. The Mecanum wheels on that robot required a far different style of driving because of what we like to call the "drunk drive" inherent with Mecanum wheels - that is, the drift that one can experience because of the rollers - and because the rollers on the wheels allow the robot to quite easily turn in place. In 2010 and 2011 we used two-stick tank drives with our robots and placed our strafe function on the triggers of the driver's Xbox controller.

This year, with the lack of the omni-directional drive-train, it made more sense, in retrospect, to use a drive system where turning and "throttle" were separate, because robots that can't strafe drive more like one would expect a wheeled vehicle to drive, and, because of this year's game, being able to drive in a straight line without having to think about it was handy (for example, while attempting to balance the field bridges). The intuitiveness of this drive made it more manageable for me to focus on the other functions on the driver controller for this year's robot in contrast to last year's robot, where the driver's controller literally only controlled the robot's drive-train. I was honestly surprised by how much I liked using the Halo Drive vs. the standard tank drive, and I'm sure the system will become part of the team's library of "good decisions" to tweak, reevaluate, and potentially use again in the future.

To echo Colin, thanks to Andrew for providing the drive code to allow us to make the switch so late in the season.