2009 Control System Possibility?

[lingomaniac88]

If I were to guess, I'd say January 3, 2009.

[Chris Marra]

A new controller system for both FTC and FRC not only means that FIRST is breaking their contract with IFI, but it sounds like they do not care too much for Intelitek either. I am sure that easyC can be updated to the new systems, but it was an excellent program to allow teams to easily control their robot and learn programming fundamentals.

I am sure that the new systems will have graphical programming and FIRST will provide help to teams in learning how to use them, but for teams without many resources it is a much larger ordeal to completely relearn a system than it is for teams with lots of support. Consider rookies who just learned how the FRC control system works vs. veteran teams who have been using it and how both will adapt to having to learn an entirely new system.

[Boron + Z]

I just learned C this year, it would be very disappointing to see all my hard work go down the drain. I guess it's never really going to "go down the drain," but to learn a whole new programming language would be quite bothersome.
I wouldn't be surprised seeing a new OI, but I think the speed controllers will stay. How to implement victors/spikes with a new OI, I'm cluless?

[Jared Russell]

I've interfaced with Victors and Spikes from non-IFI microcontrollers before, and it's not too hard. Just control the PWM duty cycle. FIRST will most likely provide easy function calls for this.

Seriously, though, this move could be devastating for FIRST. Years of refinement went into the current OI/RC system, and it finally works well. Throwing all of that out the window makes zero sense to me from a technical point of view (some of my longstanding criticisms of the IFI system notwithstanding).

Hopefully they pull it off. But it's a tall order.

[Tim Skloss]

Originally Posted by Abwehr

Seriously, though, this move could be devastating for FIRST. Years of refinement went into the current OI/RC system, and it finally works well. Throwing all of that out the window makes zero sense to me from a technical point of view.

I completely agree and I hope FIRST is listening to this thread.

In order to keep veteran teams happy FIRST must at a minimum support:
-code portability between FTC and FRC control systems, many teams count on using VEX to develop autonomous code for their FRC robots
-Gameport interface on the OI, too many teams have custom controls
-support USB to give the others an easy way to use COTS controllers
-real time terminal window to read back messages from the RC
-Dashboard support is critical for debugging
-support industry standard programming languages and not just something proprietary
-allow programmers to work at the system level, you want to see smart and impressive machines in autonomous don't you?

As long as FIRST can guarantee that we will gain features instead of loose them we accept the change. But if they opt to toss something out in exchange for a new whiz-bang goodie (or cheaper costs) they risk alienating mentors and schools who have put a lot of effort developing curricula based on FIRST products.

I agree with many who have posted on this thread: the IFI equipment works very well for our needs. It isn't broken, so don't fix it.

[Tom Bottiglieri]

Originally Posted by Tim Skloss

I agree with many who have posted on this thread: the IFI equipment works very well for our needs. It isn't broken, so don't fix it.

So how many teams hit 4 lines in hybrid mode this year? Driving in a circle seems like a pretty easy task, eh?

[Brandon Holley]

Originally Posted by Abwehr

I've interfaced with Victors and Spikes from non-IFI microcontrollers before, and it's not too hard. Just control the PWM duty cycle. FIRST will most likely provide easy function calls for this.

Seriously, though, this move could be devastating for FIRST. Years of refinement went into the current OI/RC system, and it finally works well. Throwing all of that out the window makes zero sense to me from a technical point of view (some of my longstanding criticisms of the IFI system notwithstanding).

Hopefully they pull it off. But it's a tall order.

How do you know, or not know, that FIRST hasn't considered any of these possibilities. I am sure they are more than aware at what can happen with a new control system. Maybe FIRST feels like its time to get more advanced...

[Greg Needel]

Originally Posted by Boron + Z

I just learned C this year, it would be very disappointing to see all my hard work go down the drain. I guess it's never really going to "go down the drain," but to learn a whole new programming language would be quite bothersome.

In life things change all the time. Everything to a new car, Programming language, job responsibilities, etc. One of the challenges that makes life exciting is making decisions which help you to adapt, sort of a survival of the fittest mentality. I applaud your efforts for learning C as that can be a daunting task if you came from no programming experience. While the syntax may change for another language the basic steps are the same. In the mechanical world it is just like moving from one piece of CAD software to another; the end result is the same it is just about how you get there and which buttons you push. I commend your efforts last you and urge you, pending a software change or not, to view your past experience of learning as a success. Any time you learn something new I find it hard to consider it "throwing your hard work down the drain"

Originally Posted by Tom Bottiglieri

So how many teams hit 4 lines in hybrid mode this year? Driving in a circle seems like a pretty easy task, eh?

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.

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

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

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

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