[AustinSchuh]

As I read through this discussion, I am starting to discover what I really want in the new control system.

I like the way we can really get down to the details in the current system. On the other hand, I didn't have time in the 2007 season to go through all of Kevin's code and understand it well enough to make everything I would have wanted work. Last year, we ended up using WPILib partly for this reason. It provided a nice middle layer between the hardware and let us develop code faster. My biggest complaint with WPILib is that I couldn't go open up the source files for it and see actually what it was doing and change it like I would have wanted some times.

What I want in the new control system is for it to be quickly usable like WPILib currently is but still lets us see how it actually works and change it to our desires. To me, that means combining the open source nature of Kevin's great code with the clean interface that WPILib provides. For example, I liked how in WPILib you could just enable an encoder by giving the interface the two ports it was on without having to do anything else, but I would have liked to have then been able to go and modify the source for the encoder interface to let it utilize two interrupt ports when an encoder was on two of them.

I like Tom's idea of having current sensors and quadrature encoder ports on the motor controllers. I enjoy it when the basic things that are really helpful to have are plug and play. But, I don't want to then be forced to loose flexibility because everything works only that way, or because the plug and play nature of the controller makes it next to impossible to do anything else. Along those lines, I like the NXT controller, except for the custom plugs which would make interfacing new sensors to it hard. (I haven't tried, so I don't know if the pinouts on the ports would still make it hard to interface new sensors to it even if the plug was easy to come by, but I digress) If you want, you can quickly and easily program the NXT in LEGO's fully graphical language, or you can go and download some custom firmware and environment and run native code that has been compiled using GCC on it that some professor somewhere else developed.

On a slightly different note, I can tell you for a fact that one of the things we were most worried about when putting encoders on our bot was making sure that we had enough counts per second when the robot was driving to actually do something with, (we failed, we later learned) but still not overload the controller with too many interrupts. I welcome an increase in processor power, and would also like the processor to have a FPU built in so we don't have to continually be worrying about how to rewrite our computations in the code to use integer math and then worry about whether or not we are overflowing the variables provided. I would like to be able to have enough interrupts per second so that we could write a PID controller for our drive train, without worrying about overloading the controller and then do some real math on that input.

And this season, we spent a lot of time compiling and downloading. It shouldn't take what seems like 3-4 minutes to compile and download each time we want to test something. I would like to be able to spend 5 minutes finding a bug, fix it, and then have the code ready to test in 10-20 seconds on the bot. I'll still complain about the download time, but at least it will take up a small percentage of my bug fixing cycle, instead of 1/2 of it.