paper: Killer Bees BuzzXVII 2012 Code

CD-Media: Papers
, , , , ,
#1

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

Killer Bees BuzzXVII 2012 Code
by: apalrd

Complete code from The Killer Bees 2012 robot, BuzzXVII, written in LabVIEW. Also includes commonly used function library and vision testing code

Complete code from The Killer Bees 2012 robot, BuzzXVII, written in LabVIEW. Also includes commonly used function library and vision testing code

Buzz17_CD_Release.zip:
This file contains the complete code of Buzz17 (2012). The project files are buzz17.lvproj and dashboard/buzz17_dashboard.lvproj. See Robot Main.vi for the subsystem organization, and the VI’s under it for each subsystem. I added some comments to the top of VI’s to make my thought process more clear.

BuzzLib.zip:
This file contains the common functions used in the code. Such functions include:
-Simple PID controller
-Simple linear PID gain scheduler
-Simple binary PID gain scheduler
-Simple analog scaling - Scales an input linearly based on two points - Initially written to scale analog inputs, it has also been used to: scale error to linearly cap the integral term (gun speed control), linearly scale the hood based on turret offset angle (fender shot), linearly scale speed between old and new ball settings (various instances in the gun controller), and other things.
-Simple analog input diagnostics - Filters an analog input for various common input faults
-Analog input diagnostic persuader - Filters an output based on the input faults (persuades the output to adhere to the desired action for a fault)
-Various limiting VI’s (limit to pct, limit to (0,1), deadband around joysticks, other similar functions)
-Linear ramp
-Other things
Everything in BuzzLib is also in the Buzz17 CD release, most of the files are in the common folder.

2012vision.zip:
2012 vision software including the test program. I used the test program (test_vision.vi) to run vision samples and test the vision algorithm. It reads a hardcoded folder path, iterates through all JPEG files in the folder, stores the outputs to an overlay, and outputs the resulting image to a file in a new folder. This program was vital to the development of multiple target analysis. See the VI’s in multiple target analysis for more details on the algorithm. It isn’t perfect, but we’ve found it’s quite good.

As with previous releases, feel free to use any of this code in your own projects. Please credit Team 33, The Killer Bees, if you use any major sections (e.g. the vision or autonomous systems).

BuzzLib.zip (96.3 KB)
2012vision.zip (405 KB)
Buzz17_CD_Release.zip (7.8 MB)

#2

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.

#3

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.

#4

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

#5

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!

#6

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.

#7

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

#8

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.

#9

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.

#10

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

#11

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

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

#12

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.

#13