[Lord_Jeremy]

I've got my code set up on an ssh-enabled SVN, but I'm afraid I can't give login details because I didn't have time to set up access controls. I started out with insane documentation but as time became more precious I had to forego that in favor of actual functionality. When I have more time to correct some stupid hacks and finish the documentation I'll release my libraries.

One thing I did in my system that may or may not be a good idea is component registration. The way it works is that say you construct a TankDriveSystem. The only parameter it takes is an instance ID, which is an int you set so you can tell that TankDriveSystem apart from other TankDriveSystems, for example in autonomous handling. Anyway, after you construct a TankDriveSystem, you have to call RegisterMotor with a DriveMotor parameter. In this way, you give the TankDriveSystem instances of four (or two, or six, or seventeen) motors that are stored in a vector. The DriveMotor class contains an instance variable for the "control index," pretty much whether it's left or right. In something like holonomic drive systems, you might have four or even eight control indexes, while there are just two for tank drive. Next, in your teleopInit, you need to call RegisterJoystick with a DriveJoystick parameter. Since a DriveJoystick is just a GenericJoystick with the addition of a control index parameter, you can still use DriveJoystick members in your main class in other classes that just take a GenericJoystick. Then you have to ensure all settings are in place, by calling SetDriveMode (Linear or LowParabolic), SetMaxSpeed, and SetDeadzones. When I release my main class, you'll see what I mean.

When I began using the registration concept, my idea was that I wouldn't have to write half a million constructors to handle cases of two motors, four motors, or whatever. It also saves memory because when you hit autonomousInit, the DriveJoystick vector is cleared. I figured that the overhead this system created wouldn't be too much of a problem, considering how powerful the cRIO is. So far the only issue I had with the system was when I forgot to call the constructor on the Kicker, it kept throwing NullPointerException whenever I registered anything (I'm ashamed to say that it took me a half-hour to realize my mistake). In the drive class, conditionals testing the control index of a DriveMotor and DriveJoystick when they're pulled out of the vector are used to determine whether they're left or right. I think the biggest advantage of the registration is that the functions RegisterJoystick, ClearJoysticks, RegisterMotor, and ClearMotors are all implemented from the interface DriveSystem, so the drive system can be set up without really knowing exactly what kind of drive system it is. If I created two or three different tank drive systems that each used a different algorithm for controlling speed I would only have to change the member variable type and the constructor in the main class.

EDIT:
By the way, I'm extremely interested in your even-driven implementation. I don't really have time or the wherewithal to incorporate that into my libraries but post-season I may definitely look into that. Also, I just had a pretty cool idea. Currently the only really specific classes in my system are the autonomous routines and the kicker class. In that vein I named the kicker class Kicker2010. It pretty much just uses a stepping system, with limit switch tests, to execute a series of steps to load and fire the kicker. My idea is to create an interface SteppingSystem and class GenericSteppingSystem that you could register steps with. Heh, I'd probably create classes Step, TimedStep, ConditionalStep, and TimedConditionalStep. That way you could "build" your array of components into a functional system that acts at the touch of a button. Heh, I doubt I'll implement that for our Regional (again, I would need much testing before declaring such a system fit for the competition) but it's another post-season project.

2ND EDIT:
I just took a brief glance at your GRT framework and you did something I said I was going to do but completely forgot about! I need to implement a Disable and Enable order so that specific components are loaded and unloaded on demand...