2009 Control System Possibility?

[Tom Bottiglieri]

Originally Posted by Danny Diaz

I just think the whole rationale of "we gotta be as low level as possible always" is just a crock.

I totally agree with this statement. While learning about low level integration is probably beneficial, I don't think its place is in a high school competition. I programmed my teams robot for 3 years in high school and I cannot tell you how many times I got bit in the butt by some hardware nuance. It took 3 years of experience between two high schoolers to get a 80% of the time working autonomous mode in 2006.

Now I learned how to code in C pretty well, but any monkey can write code. What I learned that was much more important was the high level control law theory, which had implications on my decisions for college. I am willing to argue that high level concepts and implementations are what we should be pushing students in FRC to learn.

In FRC now, I see a bunch of teams who have decent mechanical systems and module level code written, but no glue to hold them all together. If we can start pushing interfaces rather than low level implementations, we get two birds with one stone. (Software design experience and competitive robots). This is the same argument I used with my team for buying AndyMark shifters over using our own. Yeah, sure, we can spend a lot of time designing an OK gearbox, but we can also spend less time designing a ROCK SOLID interface for the AM gearbox, and then focus more time on other functions and practice. Which seems better to you?

[Dave Flowerday]

Originally Posted by Tom Bottiglieri

Now I learned how to code in C pretty well, but any monkey can write code. What I learned that was much more important was the high level control law theory, which had implications on my decisions for college. I am willing to argue that high level concepts and implementations are what we should be pushing students in FRC to learn.

I've worked professionally on both very-high-level applications (Java apps on a desktop) and very-low-level apps (BSPs, bootloaders, etc. on embedded PowerPC platforms) and in my opinion, the best software engineers are those who have an understanding of BOTH sides. In college, the very first programming class I had to take started off with assembly - because they knew it was important to understand what was happening "under the hood" even if you didn't work directly on it every day. Frankly, I think the fact that my team is putting out a bunch of software students who have real experience working on embedded C code will put them leaps & bounds ahead in college and their jobs over those who only know Java, Python, VB, or LabView. People who understand embedded software are few and far between compared to the number of people who know how to work in higher-level software (in my experience) and therefore are more in demand.

But that's not really my point. All this whining about wanting to write code that simply tells your robot to "drive straight" - are you telling me the hardware we have now is not capable of this? I don't believe that's true - not even close. Now, there certainly are NOT plug-n-play solutions for driving straight, but this is a software library problem. If this was a problem that FIRST wanted to solve, why haven't they been working on this for the last several years? Volunteers like Kevin have been making inroads, but if this was a priority then FIRST could hire someone, or approach a university and ask them to develop it as a research project, or approach a company like Intellitek, or whatever.

You can drop a supercomputer on my robot and it won't drive any straighter than it does now unless someone also provides the software to make that happen. There's no reason that software can't exist on the current platform.

[Jeff Waegelin]

Originally Posted by Tom Bottiglieri

In FRC now, I see a bunch of teams who have decent mechanical systems and module level code written, but no glue to hold them all together. If we can start pushing interfaces rather than low level implementations, we get two birds with one stone. (Software design experience and competitive robots). This is the same argument I used with my team for buying AndyMark shifters over using our own. Yeah, sure, we can spend a lot of time designing an OK gearbox, but we can also spend less time designing a ROCK SOLID interface for the AM gearbox, and then focus more time on other functions and practice. Which seems better to you?

This is a very interesting way to look at the software, and one that I had never really considered before. Being mostly on the mechanical side in my FIRST (and my non-FIRST) career, I am a huge proponent of using pre-made components to simplify mechanical designs. Things like AndyMark gearboxes, IFI wheels, and even the kitbot frame can be used to take the focus away from basic building blocks, and towards the construction of more complicated and innovative systems. If we can do it with hardware, why not with sensors and software?

A great example of this is what my team went through with our software. We had plenty of time to work on development, as most of you probably know Even so, we spent about 2 of the 3 weeks trying to get our gyro, encoders, and other sensors working the way they should. Old versions of default code, missing documentation, and sensors that were ill-suited to our application all conspired to take time away from our high-level software development. By the time we figured out what was really going on with the low-level stuff, we were down to the last few days, and never did manage to get some of our fancy programs working. If we had some building blocks to work with, all of that troubleshooting time could have been spent elsewhere, with great results.

At one point in time, FIRST rules forced a great focus on low-level development. Additional-parts lists, the SPI catalog, and the Kit were all you had, so any advanced systems required pretty extensive engineering and fabrication resources. When FIRST opened those rules up in 2003, they raised the bar, and opened doors for all kinds of mechanical building blocks to help teams compete. It's time that we did the same thing for the controls side.

[Greg Marra]

Originally Posted by Tom Bottiglieri

Now I learned how to code in C pretty well, but any monkey can write code. What I learned that was much more important was the high level control law theory, which had implications on my decisions for college. I am willing to argue that high level concepts and implementations are what we should be pushing students in FRC to learn.

In FRC now, I see a bunch of teams who have decent mechanical systems and module level code written, but no glue to hold them all together. If we can start pushing interfaces rather than low level implementations, we get two birds with one stone. (Software design experience and competitive robots). This is the same argument I used with my team for buying AndyMark shifters over using our own. Yeah, sure, we can spend a lot of time designing an OK gearbox, but we can also spend less time designing a ROCK SOLID interface for the AM gearbox, and then focus more time on other functions and practice. Which seems better to you?

Bingo. Make it easier to do the simple stuff and free up people's brains to think about the hard problems. Making hardware behave properly isn't a hard problem. Learning closed-loop control theory is a hard, interesting problem.

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