2009 Control System Possibility?

[Tom Bottiglieri]

Originally Posted by Greg Needel

I am not sure where you are going with this. Are you saying that people didn't do 4 lines because of the capabilities of the controller or because it is a difficult challenge. Either way I can see arguments for either. The controller is not the fastest thing on the market but how many teams of the 1500 actually use 100% of the processing or memory on board? I am just afraid that people are falling into the "we need it bigger, better, and faster" trap. IMO sometimes it is better to have a pickup truck that is bullet proof rather then a sports car which needs to be constantly tuned to keep it running.

It's not so much a hardware issue as it is a software issue. The tools and existing infrastructure around the product simply aren't conducive to the accomplishing the goals of the program. IMHO, FIRST control systems need to foster rapid development time, a shallow learning curve, and great results. This is what we want to accomplish, correct? We want to develop control systems in 6 weeks, have them play well in competition, and we want everyone, rookie or veteran, to be able to do it.

If teams sit and do nothing during the matches, it is neither inspiring nor exciting for the students or general public.

There's always room for improvement. What one person says isn't broken seems to be very broken in my mind. Neither one of us is entirely right, but I'm sure both sides of the argument were heard and a concurring plan of action has been put into place.

[Dave Scheck]

Originally Posted by Tom Bottiglieri

It's not so much a hardware issue as it is a software issue. The tools and existing infrastructure around the product simply aren't conducive to the accomplishing the goals of the program. IMHO, FIRST control systems need to foster rapid development time, a shallow learning curve, and great results.

I would agree with this to a certain extent.

I definitely think that teams that have hybrid/autonomous robots that just sit there are doing so because of a lack of software understanding. However, I don't think this is the fault of the control system. I do think this is a problem with a lack of resources/tutorials that help rookie teams out. Yeah, I know there are some good ones floating around, but that isn't made public through FIRST. Most of the time the only way you come across those is here on CD, but how would a rookie team know to look here unless they were given the heads up? We based our software this year on Kevin's revamped default code. Was the default code download location even made public? I don't remember seeing an announcement anywhere.

While I still contend that graphical programming approaches still aren't for everyone, I do think that it allows inexperienced teams to have a pretty good foothold. My only hope is that they use that knowledge to jump into text based coding to get the experience.

If this problem is to be fixed, we don't need fancy new hardware or programming interfaces. The way to fix this is with education. If there was a curriculum that was provided to any team that requested it, I think that teams might find that there isn't a whole lot of magic in the programming itself...as with mechanical systems, it's all in the design.

Also, I've seen a lot more teams moving than in years past. I have a feeling that it's because there is an easy objective to accomplish (i.e. driving one or two lines) that teams aren't overwhelmed by (i.e hanging a tube on a randomly located post). I think that the way that the game is defined will dictate the excitement of the autonomous movement (2005 wasn't very interesting was it?).

[Tom Bottiglieri]

Originally Posted by Dave Scheck

I would agree with this to a certain extent.

I definitely think that teams that have hybrid/autonomous robots that just sit there are doing so because of a lack of software understanding. However, I don't think this is the fault of the control system. I do think this is a problem with a lack of resources/tutorials that help rookie teams out. Yeah, I know there are some good ones floating around, but that isn't made public through FIRST. Most of the time the only way you come across those is here on CD, but how would a rookie team know to look here unless they were given the heads up? We based our software this year on Kevin's revamped default code. Was the default code download location even made public? I don't remember seeing an announcement anywhere.

While I still contend that graphical programming approaches still aren't for everyone, I do think that it allows inexperienced teams to have a pretty good foothold. My only hope is that they use that knowledge to jump into text based coding to get the experience.

If this problem is to be fixed, we don't need fancy new hardware or programming interfaces. The way to fix this is with education. If there was a curriculum that was provided to any team that requested it, I think that teams might find that there isn't a whole lot of magic in the programming itself...as with mechanical systems, it's all in the design.

Also, I've seen a lot more teams moving than in years past. I have a feeling that it's because there is an easy objective to accomplish (i.e. driving one or two lines) that teams aren't overwhelmed by (i.e hanging a tube on a randomly located post). I think that the way that the game is defined will dictate the excitement of the autonomous movement (2005 wasn't very interesting was it?).

I totally agree education is vital in any steps we wish to take. But, there are steps we can take to make sure that control is in place before the education takes place.

A major problem I see students struggling with is not in logic development, but rather in nitty gritty low level mechanical interfacing issues. They seem to grasp what the robot needs to do, and usually can come up with a pretty good implementation. The problem is the mechanical systems are lacking, and there is no easy out of the box solution to make up for this. One big example is the "my robot doesn't drive straight" issue. Teams are forced to spend alot of time tuning their robot to drive straight (most of the time without using feedback) before they can accomplish higher level goals. Usually these teams have about 27 minutes to test software before the robot is shipped, and are flustered while trying to work at the competition.

Now what if we had a system that could do dynamic simulation or object oriented design so that teams could drop in a "drive straight" module and test it before they hit the real hardware? Then could we get to the real logic based issues?

[Mike Soukup]

Originally Posted by Tom Bottiglieri

A major problem I see students struggling with is not in logic development, but rather in nitty gritty low level mechanical interfacing issues. They seem to grasp what the robot needs to do, and usually can come up with a pretty good implementation. The problem is the mechanical systems are lacking, and there is no easy out of the box solution to make up for this. One big example is the "my robot doesn't drive straight" issue. Teams are forced to spend alot of time tuning their robot to drive straight (most of the time without using feedback) before they can accomplish higher level goals. Usually these teams have about 27 minutes to test software before the robot is shipped, and are flustered while trying to work at the competition.

Now what if we had a system that could do dynamic simulation or at least object oriented design so that teams could drop in a "drive straight" module and get to the real logic based issues?

If the new control system can guarantee that our robot will drive straight, I'm 100% on board. Our software team would enjoy the extra couple of weeks that would give us. But I'm afraid it's never as simple as dropping in some module, each robot has its own complex behaviors that affect its performance; no two robots drive exactly the same, even if they have the same general design. What works for one robot may not work for another. For example, some robots that don't turn well can't be made to drive straight by using different motor speeds on each side. The ability to drive straight with a chassis that just doesn't want to or control an unwieldy arm is an extremely difficult problem that either requires advanced math to model the system (which I've never been exposed to) or lots of guesswork (which I'm all too familiar with ). I certainly hope that if FIRST bills the new control system as a way to magically make all the nitty-gritty controls problems go away, they succeed. I know they've over stated the abilities of the modules they've given us in the past, I hope they don't do it again.

[petek]

Originally Posted by Dave Scheck

I would agree with this to a certain extent.

I definitely think that teams that have hybrid/autonomous robots that just sit there are doing so because of a lack of software understanding. However, I don't think this is the fault of the control system. I do think this is a problem with a lack of resources/tutorials that help rookie teams out. Yeah, I know there are some good ones floating around, but that isn't made public through FIRST. Most of the time the only way you come across those is here on CD, but how would a rookie team know to look here unless they were given the heads up? We based our software this year on Kevin's revamped default code. Was the default code download location even made public? I don't remember seeing an announcement anywhere.

Links to Kevin's code and other resources are on the FIRST docs site but you have to know what you're looking for and navigate down several levels to get to that page. So, though the info is available, I think your point is valid because a typical deer-in-the-headlights rookie programming team probably isn't going to find the right information early on.

I would like to see FIRST create a technical documentation system that addresses the needs of all teams - rookie, small, large, lots of mentors and no mentors. This sounds like a huge challenge, but a good example is right in front of most of us: the Vex manual. (Oops, sorry for using the "v" word ) Anyway, that manual makes it easy for a newbie with no technical knowledge whatsoever to build and program a robot all by themself. It also covers more advanced topics and engineering theory, but the way it's organized, the essentials are not buried in the details or program headers.

Most of the information needed for such a publication already exists for the current (IFI - oops, there's the "i" word) system, but spread across many websites and downloads. Experienced teams already know where some of it is, though most still have to do some digging to find technical info that should be readily available. To put this documentation in an easy-to-use format would still be a lot of work, but mostly in organization, rather than creation.

If FIRST handles documentation and training for the new system like they did with the old, where will we be next January? Since so much of what is now available for the old system was created by teams, we could be looking at starting from zero unless FIRST takes the bull by the horns right now and makes the effort to provide comprehensive, well-organized and accessible information and make it available before kickoff.

[Danny Diaz]

Originally Posted by Dave Scheck

(2005 wasn't very interesting was it?).

Actually, it was. 418 was the only team at the Lone Star Regional that could, in autonomous, repeatedly grab the magnetically hanging tetra and place it on top of its stand. It was incredibly cool, the team worked on that one aspect for almost an entire day.

Autonomous is what you make of it given the tools you have available to you. The biggest problem in my opinion is that the tools we currently have are lacking.

-Danny

[Dave Scheck]

Originally Posted by Danny Diaz

Actually, it was. 418 was the only team at the Lone Star Regional that could, in autonomous, repeatedly grab the magnetically hanging tetra and place it on top of its stand. It was incredibly cool, the team worked on that one aspect for almost an entire day.

Autonomous is what you make of it given the tools you have available to you. The biggest problem in my opinion is that the tools we currently have are lacking.

-Danny

OK, credit given. We (111) worked extremely long hours and were able to reliably cap the center goal with a tetra that was in most of the positions on the field....with our practice bot. On the competition bot, things drove a little differently and we were very close on multiple occasions, but ran out of time. I can't seem to find the video, but there was one occasion at champs where time ended with the tetra hovering centered over the goal. It was exciting to watch, but resulted in no points.

With the exception of 111, 418, and a small handful of other teams, the majority of teams didn't move enough to be noticed. That's what my original point was...autonomous was boring the majority of the time.

I also say "It's a poor workman who blames his tools". We (and I know we're not alone), use the controller to the fullest almost every year. In 2005 we offloaded the camera processing to our custom circuit, but the logic of doing something with the data resided on the RC, and let me tell you, it took a lot of math to figure out where we were going. In 2003 we had a waypoint system completely in PBasic.

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?

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