2009 Control System Possibility?

[Tom Bottiglieri]

Originally Posted by Dave Scheck

Yes, with more advanced hardware the potential of what can be done with it goes up, but the current hardware can be made to work. Are you telling me that an arbitrary rookie team with no programming experience would be able knock two balls down and do 5 lines this year had the controller been more advanced?

I'm not so worried about the processing power or the programming language as I am about its interfaces. Give me out of the box current monitoring with an easy I2R comp. code module (every CIM motor is about the same, right?),. Give me quad encoder inputs on the motor controllers. Give me something better than plug the square plug into the round hole and then apply some magic code, that may or may not work.

I have worked with many rookie teams through 125's Ask An Engineer program and Boston's Regional Mentor program. Teams need this stuff.

[Dave Scheck]

Now that's something that I whole heartedly agree with Tom. Modules like you described give the user more data to work with. This in turn leads to more you can do right out of the box. There still is some "magic code" that needs to be done to do the work, but the data provided makes it much easier.

[Tim Skloss]

Originally Posted by Tom Bottiglieri

Give me out of the box current monitoring with an easy I2R comp. code module (every CIM motor is about the same, right?),. Give me quad encoder inputs on the motor controllers.

We already have that... it's called FIRST Lego League where everything is standardized and your choices for input and output devices are very limited. Works great for middle schoolers who aren't ready to learn the details of electromechanical control, but misses the point for FRC.

I don't think an extra-large incantation of Mindstorms is where we should go. Developing C code (albeit slowly) to make a robot with simple motor drives go straight gives the students a much deeper understanding of how things work. That is FAR more important than having a winning robot.

Insulating the students from complexity cheats them. Students who learn how their robot really works are better prepared to make the important educational choices that are in front of them at this time in their lives.

They are smart. They can learn if they have good teachers. I agree with the earlier point that most missing autonomous is due to the lack of mentors who can help them.

Making something idiot proof only cultivates better idiots.

[Tom Bottiglieri]

Originally Posted by Tim Skloss

We already have that... it's called FIRST Lego League where everything is standardized and your choices for input and output devices are very limited. Works great for middle schoolers who aren't ready to learn the details of electromechanical control, but misses the point for FRC.

I don't think an extra-large incantation of Mindstorms is where we should go. Developing C code (albeit slowly) to make a robot with simple motor drives go straight gives the students a much deeper understanding of how things work. That is FAR more important than having a winning robot.

Insulating the students from complexity cheats them. Students who learn how their robot really works are better prepared to make the important educational choices that are in front of them at this time in their lives.

They are smart. They can learn if they have good teachers. I agree with the earlier point that most missing autonomous is due to the lack of mentors who can help them.

Making something idiot proof only cultivates better idiots.

I'm not sure what else I can say. The bar is not being lowered. It is being raised.

[Danny Diaz]

Originally Posted by Tim Skloss

We already have that... it's called FIRST Lego League ... Works great for middle schoolers who aren't ready to learn the details of electromechanical control, but misses the point for FRC.

Developing C code (albeit slowly) to make a robot with simple motor drives go straight gives the students a much deeper understanding of how things work. That is FAR more important than having a winning robot.

Insulating the students from complexity cheats them. Students who learn how their robot really works are better prepared to make the important educational choices that are in front of them at this time in their lives.

I can't disagree with this any more, at least the way this competition is structured. Let's view this from the point of my students:

1. We spend our summers fundraising to make money to be able to compete. In most cases this involves ACTUAL MANUAL LABOR, and is in addition to the work they are doing in their REAL summer jobs. $6,000 entry fee, around $3500 for robot parts/accessories, $2500 for travel, and an additional $5,000 for Championships - money doesn't grow on trees ya know, and since we've grown the Central Texas area corporations and businesses are giving less and less to each team since they're being pressured to donate to more and more teams.

2. Once we have busted our chops to make the money to be able to compete in FIRST, we're purchasing the hardware and software tools to help us build our robot within the confines of this competition.

3. Now you're telling us we're SUPPOSED to be frustrated that we can't even make a $%^@ robot drive STRAIGHT?!?! That's supposed to be something we're SUPPOSED to have problems with? A $250 LEGO Mindstorms robot now has nice little wrappers that handle all the complexities of driving straight, but because we're paying 50x as much money we're SUPPOSED to have to solve this problem out of the box OURSELVES?!? That BS.

4. Okay, now that we've given our lives and sanity to this competition, you're saying that having these frustrations is more important than winning? Why the heck even participate in the competition if your end goal isn't to win? If this competition didn't cost the average team $10,000 per year, I might be able to agree with you. But the way it's structured, anything not designed to make me more productive and making me more competitive is working against me, and I can go elsewhere and have people/things work against me for free.

I just think the whole rationale of "we gotta be as low level as possible always" is just a crock. I say give me external automatic processing for my gyro so all I ever have to do is ask what direction I'm pointing in, give me the ability to say, "Synchronize motors for XXX encoder counts", and things that cheaper systems nowadays do for me AUTOMATICALLY. Then I can write higher-level algorithms faster that do things that are actually USEFUL to me. Give me that and I'll be a more competitive team, I promise.

-Danny

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

[roboticWanderor]

Originally Posted by Tristan Lall

As it seems to be open season on speculation, let me add what my secret agents are telling me: National Instruments (of LabView fame) has a platform called CompactRIO, which is used for industrial controls. It's modular, durable, and quite expensive. Controller units consist of a smart backplane and a stack of interchangeable modules.

It would be very interesting indeed to see these systems embedded into a FIRST robot. I attended NI week (a big ol NI party/conference) to man a booth for our team, demoing some of our robots (we are sponsored by NI). anyways back to the story... they had many really cool displays and booths set up with LabView and NI hardware controlling some very cool robotic devices, such as remote control cars (with a wiimote no less), an visionary (exuse the pun) assembly line and a neat balancing act. they also had a tetris game that played itself, really cool vision systems, and if you did not know already, the backbone of the NXT coding system is labview.

if FIRST were indeed to pick a NI system, im sure it would be fully capable of handling whatever FIRST could dish out, and more. also, being able to be coded in both C and lab view, it would be easy for programmers of all types to quickly become accustomed to the new system.

[seanwitte]

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 say give me external automatic processing for my gyro so all I ever have to do is ask what direction I'm pointing in, give me the ability to say, "Synchronize motors for XXX encoder counts", and things that cheaper systems nowadays do for me AUTOMATICALLY. Then I can write higher-level algorithms faster that do things that are actually USEFUL to me. Give me that and I'll be a more competitive team, I promise.-Danny

This is a point of view that has always annoyed me. How many different ways are there to write the code to drive straight or integrate the gyro? Why is it that nobody, except Kevin, steps up and actually DOES something about it? Instead of saying "I can't compete because you don't give me enough" why aren't more people publishing these solutions? This is a breakdown in the community, not in FIRST.

[Greg Marra]

Originally Posted by seanwitte

This is a point of view that has always annoyed me. How many different ways are there to write the code to drive straight or integrate the gyro? Why is it that nobody, except Kevin, steps up and actually DOES something about it? Instead of saying "I can't compete because you don't give me enough" why aren't more people publishing these solutions? This is a breakdown in the community, not in FIRST.

A lot of the problem is that new teams don't know there is a community. They don't have team members who read and post to Chief Delphi (which, mind you, isn't an official forum). FIRST's website links to a few more team resources this year, but they don't make it tremendously easy for people to find all the resources that exist. If you've never heard of Kevin's code, wouldn't programming the robot be a much more daunting challenge?

Additionally, the rules against code re-use make lots of things that probably ought to be allowed technically against the rules. If these rules were enforced to the strict letter of the law, things wouldn't be nearly as smooth as they are.

[Danny Diaz]

Originally Posted by seanwitte

This is a breakdown in the community, not in FIRST.

I disagree.

I do believe there are some things the community is "responsible" for - the mentorship that Kevin Watson, Al Skierkiewicz, and the hundreds of other mentors from around the country/world provide has been critical to the success of teams, and we all truly appreciate their support. As a community we have increased knowledge and overall the competition has been made much more fulfilling through their efforts.

However, there are some responsibilities that should be enforced on the competition - i.e. FIRST. Whether they decide to enforce this on their vendors or not is their choice, but it's their job to make sure the hardware/software tools that teams get are going to be conducive to making teams productive, competitive, and happy. For obvious reasons they constrict us to a specific set of tools, hardware, and systems. GREAT! But they have the responsibility of ensuring that we get what we need to succeed with those tools/hardware/systems. They can't throw us into the ocean and expect the community to teach us how to swim.

-Danny

[Dave Flowerday]

Originally Posted by seanwitte

How many different ways are there to write the code to drive straight or integrate the gyro?

I don't know, but it would appear to me that FIRST wants us to rewrite that same "drive straight" code year after year - as evidenced by the fact that they ban use of any software written by a team in a prior year. If they allowed teams to build up a solid software base and expand on it year after year, maybe things would be different? Our team could probably be a lot further along software-wise if our kids didn't have to start with default code each year and rewrite the same drive code that they've written for 3 years in a row now.

Keep in mind our robots are not nearly as homogeneous as LEGO or Vex robots. With so many different drive systems and feedback mechanisms, it's much more difficult to come up with a drop-in "drive straight" module that will just work for everyone. I think to some extent this will always be true. If FIRST provides these higher-level abstractions, it's quite likely that we'll have to simply shift our time from writing a custom modules that do exactly what we need to trying to figure out how to brow-beat the supplied module into behaving like we want.