2009 Control System Possibility?
 

Hm... VEX and FRC control systems tend to be based off each other, and
this seems to indicate that there's a new control system for VEX that runs on 802.11... perhaps this means the end of serial based programming for FRC bots! Would be cool to be able to program straight from wireless. Also, its opened the door to robot->robot communication, according to that link... 2009 game involving telling alliance robots data about something, anyone?

Re: 2009 Control System Possibility?
 

Man, already with the '09 stuff. We haven't even had the Championships yet, lol:D

Re: 2009 Control System Possibility?
 

Recent info suggests that there is a split between IFI and First. Vex Labs released that they would have a 802.11g solution. FTC will use blue tooth for the new FTC controller. So I would expect First FRC to also go with Blue tooth.

Re: 2009 Control System Possibility?
 

which means that we are not truly moving away from serial communications.

I'm assuming that we will be using a blutooth serial module, which will greatly open up possibilities!!

I am also guessing that we will be moving away from PIC

Re: 2009 Control System Possibility?
 

It will be interesting to see what the new FTC controller really is. The announcement indicated its packaging is built on LEGO NXT which uses an AVR master processor (where io devices attach) and an ARM7 processor for user code. It would be unusual to keep the packaging but move away from the established architecture within the packaging although there will probably be inclusion of faster models of one or both of these chips. The specs on the ARM7 certainly seem to match the 10x memory and 38% faster specs released in the blog.

Currently, the LEGO NXT looks like it is set up to have all io devices plug into and be serviced by the AVR which is similar in architecture to the PIC - i.e. it has timers, ADC, io pins, etc. User written code gets put on the ARM processor which has none of these but does have a couple different methods of interacting with co-processors. With this type of architecture, it could make adding or creating your own sensors from industry available parts much more difficult (the AVR is not currently user accessible, but that is where h/w gets attached).

If so, then this is both a move forward but also possibly a significant change in terms of software programming environments... which is why until details are released there is a lot of angst and guesswork.

If true, then you will end up with two camps: those that love it because now they don't have to worry about all those pesky hardware sensor devices as both the h/w and s/w for the devices are provided & hidden from the programmer, and those that hate it for the exact opposite reason. I'm in the "hate it" group becuase its a shift from systems programmer (me) to application programmer by adding another layer of abstraction and isolation from the hardware.

Even when the FTC details are released after nationals, that will just fuel a 2nd round of speculation on what the new FRC controller architecture will look like. Since FTC kits have already been distributed to some teams, my guess is things might be tweaked but are probably pretty nailed down unless there is outright failure of teams to be able to utilize the kits.

BTW, the Gumstix uses an ARM Xscale processor w/MMU and there are two flavors of Linux ported to run on the ARM. My random guess is the FRC version may use an Xscale core so it can run a flavor of Linux and deliver multi-threading, etc. and turn us all into application programmers vs systems programmers. Many will see this is great news.

But all this is speculation and even after the FTC announcement, there will continue to be a huge unknown factor as to what the new FRC controller will really look like for months to come.

Re: 2009 Control System Possibility?
 

After talking to Matt from IFI, his quote of "There is no more IFI next year" really had me thinking....

Perhaps another vendor? Perhaps you have to build your own!!!!!!!!

Jacob

Re: 2009 Control System Possibility?
 

I was talking to somebody from WPI a few months ago. The speaker said that the device he had was a prototype of the FIRST control system for 2009.

I got a chance to play with it, it's impressive.

It was based yes, on an AVR and an ARM, though a move from ARM to XScale was to be made. This made it extremely fast. It looks similiar to an Arduino with a breadboard. There are quick connect ports for motor controllers, and a nice breadboard, similiar to the Parallax BOE board.

It was programmable in C, D, Python, Java, and BASIC.

Re: 2009 Control System Possibility?
 

From hints that I have got, GAME port controllers won't be much use next year...

Re: 2009 Control System Possibility?
 

God i hope not!!! I want to use USB!

Re: 2009 Control System Possibility?
 

Thinking about that, maybe IFI is just changing names. This could also be why it is no longer FVC. They probably are doing a company overhaul as far as naming of products go. Personally I don't think that IFI is just going to split with FIRST and then be done with it which is the first thing I think of when I read that quote above. What I expect it to be is just that they are changing their name.

Re: 2009 Control System Possibility?
 

I spoke with someone from IFI at SVR this year. He said that FIRST has canceled it's contract with IFI and that IFI wasn't going to be involved with FIRST next year.

Re: 2009 Control System Possibility?
 

I highly doubt there will be a breadboard on the new control system, at least not in the way most of us vision one. There's a reason they are used on the lab bench and not in production. I can see modular motor control and misc I/O lines, running on some modern bus.

Also I would be very surprised if you could program the robot in Python, Java, or Basic. If there was an OS with interpreters and a control API, then MAYBE this is a possibility, but I highly doubt it. That is very scary from a support/infrastructure point of view. I would expect to see some kind of visual programming language (something similar to easyC, Labview, Simulink, etc..) after the success of easyC in FRC and FTC.

Re: 2009 Control System Possibility?
 

Considering the turn of events of the last year, I'd put down lots of money that the new control system won't be from IFI.

Re: 2009 Control System Possibility?
 

I have also heard the same from various sources.

Re: 2009 Control System Possibility?
 

FIRST has made it abundantly clear that they will not be returning to VEX next year, and have since taken public potshots at the VEX platform.

It's been a pretty open secret here that FIRST is trying their best to get rid of IFI.

Re: 2009 Control System Possibility?
 

Python support would be *excellent*.

Re: 2009 Control System Possibility?
 

Why exactly would FIRST want to get rid of IFI? :confused: They donate many supplies to teams (which if bought individually, could cost more that a thousand dollars), and there is always an IFI representative at almost regional.

Re: 2009 Control System Possibility?
 

IFI doesn't do all of that for free, I'd imagine. They're likely contracted by FIRST to provide those services and, apparently, FIRST is unhappy with how that arrangement has been playing out.

Re: 2009 Control System Possibility?
 

In my opinion I think that next year is not going to be a fun one initially. I foresee alot of issues at the initial regionals with matches switching from Hybrid to Operator control. I would have much rather seen IFI come out with a new version of the control system. I hope that the new control system is very similar to the current one with new features. It's gonna suck If we have to buy new relays, speed, controllers and other control parts

Re: 2009 Control System Possibility?
 

I agree one of the best parts of being a veteran team is all the stockpiled parts we have that we can use for ourselves or helping other new teams near us.

Re: 2009 Control System Possibility?
 

There is ALWAYS a way to interface! Heck, I've used an IFI spike with an arduino successfully!

Re: 2009 Control System Possibility?
 

But if there's a new control system that doesn't explicitly depend on IFI components, there's absolutely no way we're going to be allowed to use them.

Re: 2009 Control System Possibility?
 

Why not. What is the problem with an open electronics platform. As I see it, that's a good thing!

There is a reason for industry standards, and as such, there are many ways to implement them. I think that that would be a HUGE stepping stone for FIRST

Re: 2009 Control System Possibility?
 

As long as the new control system can do native trig and floating point calculations, im fine :D

Re: 2009 Control System Possibility?
 

It is...until you're scrambling through the pits trying to find a Billfred Industries speed controller and the only spares you can find are GaryDill. In this particular case, standardization allows teams to help each other more quickly as there is a far shallower learning curve--your Victors should work the same way as ours, give or take a few quirks (brake/coast headers, motor wiring arrangement, etc.).

Re: 2009 Control System Possibility?
 

These are solid Facts:
As far as FTC goes, the control system is the exact NXT hardware possibly with a different firmware. sensor port 4 of the NXT can do I2C communications and an expansion I/O device will be connected to it.

These are my guesses:

For the Operator Interface, It is possible to use another NXT brick with a custom Firmware to let FIRST manage disabled, autonomous, and teleoperated states.
Or it can be a custom circuit made by FIRST.
As far as managing the game goes, the NXT brick can connect to multiple blue tooth devices, so it can directly connect to the field management system.


I highly doubt that the FRC controller will have anything to do with NXT
I have heard from various credible sources that FIRST is designing the Controller from scratch.
I doubt that the communications will be at 2.4 GHz since a chances of interference would be high, and also Blue tooth is not reliable enough.

Re: 2009 Control System Possibility?
 

Wow... I'm totally blown away that IFI and FIRST are parting ways after this many years... If thats the case, then I'm way off base, and I might not be a very happy camper next year. If we're moving away from an All-IFI setup, I hope they go all open electronics, outside of the RC. Basically the same rules as now, but you can use any speed controllers/relays (IFI or otherwise) that you want, and they MUST be fed from the ports given to us. (under control of a master CPU so they could still disable us.)

Otherwise, you're going to have a TON of veteran teams with YEARS of stockpiled Spikes/Victors that would now be totally useless. This is part of how we've collected so many spares, is by being a 5th year team.

Never mind that theres likely to be growing pains, stemming from trying to change what is tried, tested and true. Namely, all the field control setup.

Re: 2009 Control System Possibility?
 

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. When my agents were down in Texas, interviewing for NI, they were openly describing this system as the new FRC platform. Whether that means they've submitted a bid, and expect to win, or they've already been chosen, I don't know. But I doubt a potential employer would be feeding my agents disinformation....

Also, recall there was a bit of a slip-up a few months ago, regarding these very same units, where an NI representative announced, then retracted an unofficial statement about these systems, when he was talking to an FRC audience.

Anyway, my money is on cRIO, for next year. Hopefully it's ready in time, if that's what FIRST wants to use.

Re: 2009 Control System Possibility?
 

I've done a little bit of work with cRIO based systems. I'll be interested to see how NI would turn that into an FRC control system. It would be really easy to design a visual block-based programming system with LabView, though...

Re: 2009 Control System Possibility?
 

I have absolutely no "inside info", but the NI cRIO solution makes so much sense, and boy is this thing sweet!

Now it makes sense why NI included the full-license version of LabView in the KOP this year. They weren't just hoping you would use it for the Dashboard and Robot Modeling Kit - they were prepping us for the future!

And, if they were to provide these units, it would be a pretty good bet that FIRST students going out into industry would take this "industry-ready" NI technology right along with them.

Re: 2009 Control System Possibility?
 

Interesting... according to the cRIO description, you can use C/C++ code on the real-time processor, in addition to LabView. The more I read about this, the more sense it seems to make to me. I think this system could allow us to do a lot of interesting new things with I/O, as well as provide a really simple graphical programming interface for new programmers, while still allowing teams to continue learning and using C.

Re: 2009 Control System Possibility?
 

I should have written in my first post that I would doubt seeing Python, Java, or Basic, but would 110% expect C/C++ capabilities. I assumed whatever platform we are moving to will have at least some capability to execute software written in C.

Re: 2009 Control System Possibility?
 

I'm kind of excited about the move from IFI. After 3 years of programming IFI, a little change would be refreshing! I'm also a big supporter of having an open electronics platform. Our teams been around for 11 years or so, and we have quite the stockpile of parts. It would be a bit of a bummer if they all of the sudden became worthless. Also, I've been looking around on FIRST's website, and I have seen no news about the switch from IFI. Has there been a press release of sorts, or is this more hearsay? I'm really quite interested in what controllers FIRST is considering.

Re: 2009 Control System Possibility?
 

I could get excited over this
http://sine.ni.com/nips/cds/view/p/lang/en/nid/202711

Encoder input and current sensor built in. We could start doing some great things for the community as far as software infrastructure goes.

edit: Looks like this is for low current applications only (8A continuous, 12A peak). Either way, I hope some kind of 'out of the box' feedback solution is integrated into our motor drivers next year. I have helped teams get software solutions running at regionals for the past few events, and the value of something like this would be immense.

Re: 2009 Control System Possibility?
 

For what I've been told by some people(or more of a lot) on the committee and the other volunteer and mentors here in Colorado, I had been hearing that we're going with Labview...

I've been told it goes back to when the VEX kits were first released at Radioshack and IFI was having a lot of problems because many of the kits were defective and IFI began to lose money and had to break ties with Radioshack. Then it goes into even more detail but it's more trouble to explain what had happened between FIRST and IFI.

I've heard that FTC next year for the Fall 2008 season though will still be allowed to use the VEX kits but it will be their last year to be allowed to use them for FTC.

Re: 2009 Control System Possibility?
 

FIRST without IFI... now thats a scary thought... sadly it looks like the future

Re: 2009 Control System Possibility?
 

programming in Labview would be nice (i use it everyday @ work), but my money is on M$ & .NET CF.....

Re: 2009 Control System Possibility?
 

Also gone will be all the tech support. There's always at least one IFI representative at each regional and they have always provided great support (from what I've seen). What can we expect from the new provider?

Re: 2009 Control System Possibility?
 

Hopefully FIRST will consider that aspect when they enter a new contract. IFI people have been incredibly helpful throughout the years.

Re: 2009 Control System Possibility?
 

According to their website, IFI has 75 employees; National Instruments has over 4500. I bet they can spare a few for each FIRST event.

But we all know that numbers don't tell the whole story. So , for a real life example of NI's FIRST support, just pop over to the NI forum right here on CD, and ask Danny Diaz (an NI employee) a question. Chances are, he'll have an answer within an hour or two. If NI is able to provide even 1% of the excellent service that Danny has provided so far, we'll all be in good shape.

Re: 2009 Control System Possibility?
 

we were talking to someone from IFI and he said they were working on something that runs natively on Linux but they arent going to use it for first

Re: 2009 Control System Possibility?
 

Ugh, I hope not. This is one programmer who won't be continuing in FIRST if that's the case.

Re: 2009 Control System Possibility?
 

That's the thing... I'm wondering how they will handle the control interface, given that VxWorks is a full OS. There will have to be some sort of interlock, but if the programmers can get into the OS level, how much use is that?

Re: 2009 Control System Possibility?
 

IMNSHO a properly designed Class 1 Bluetooth based system would be the
most robust of the unlicensed alternatives. Assuming that you are not going
to run 2.4 GHz jammers (i.e. microwave ovens), WiFi access points, or
Portable 2.4 Ghz phones on the actual field, there would be virtually no
interference that would be of much impact to a Class 1 piconet on the field.
The field controller could be optimally located above the center of the field
with an appropriate radiation pattern. The field controller could be master
of a single pico-net and it would have virtually no interference with
adjacent fields or even Bluetooth Cellphones in the pockets of the drivers.
Active Bluetooth voice connections close to the field could be a problem
but these are not legal anyway. They could be detected by the field
controller which would not be a bad thing.

For non-competition situations, each operator console could be master of
its own piconet. Everyone could operate even in the pits without interference
as long as Wireless lans weren't being used. BT offers much greater control
over what could be done and far more predictable results than WiFi. 2.4 GHz,
however, is not the place for channelized operations. The coexistance
problems of BT and WiFi occur mainly when you try to use both in the same
box (or immediate proximity). In those scenarios, coordination is required
in order for both to simultaneously work. BT class 1 works fine in an area by itself and
version 1.2 or later will even do a good job of working around a nearby
WiFi, WiMax, or Single Channel source. There is also an excellent open-source
BT stack to build from.

I agree that ordinary off-the-shelf class 2 BT devices would probably not
work all that well. But the 1600 hops per second over 79 channels basic
operation with +20dbm transmitter (and better receive sensitivity) of Class 1 devices
can, with appropriate system design, provide the most robust solution at
the datarates involved (240kbps).

Re: 2009 Control System Possibility?
 

What about Zigbee. 802.15.4

That means virtually no interference. Also, they use access keys, similar so Secure BT, meaning that if they were set to the team number, there is little chance of interference.

http://rfdesign.com/next_generation_...-needs-zigbee/

Re: 2009 Control System Possibility?
 

I have been apart of FIRST for 3 years and I have seen the IFI guys jump over hurdles and through hoops of fire to help teams out so it is a shame that FIRST split, especially in the manner that IFI found out.... In other news, my source(s) tell me that something above was in the works.

I HOPE that whatever FIRST changes to, doesn't change the price of FIRST as many teams are already barely cutting the entry costs and a decent robot. The thing I like about IFI is $500 for the RC, $500 for OI and a few hundred for accessories will run smoothly. If we have another system, I hope it is around the same or cheaper because if it goes up even by $200-300 then we will see the peak of growth in FIRST sooner. At that, if the accessories like motor controllers and relays are more expensive we (the teams and the FIRST community) are at a bigger loss.

Re: 2009 Control System Possibility?
 

I think your information is suspect at best.

If you don't have hard facts, it's best to avoid speculation that may or may not be unfounded.

Re: 2009 Control System Possibility?
 

So does anyone know when FIRST will announce and give us access to the new system? Will we have to wait till kickoff?

Re: 2009 Control System Possibility?
 

I'm hoping they announce something before kickoff, I'd like to know what to expect.

Re: 2009 Control System Possibility?
 

Last time there was a significant platform change, when the processor inside the RC was switched from a BASIC Stamp to a PIC for the 2004 season, teams were sent a "Mini-RC" in the fall so that they could learn the language and the structure of the default code. I would expect something similar for future platform changes.

Re: 2009 Control System Possibility?
 

I'm curious to see what's sent to us!

(Though I wouldn't complain if they sent us an AVR)

Re: 2009 Control System Possibility?
 

With any luck IFI will stay on board with their KitBot and Traction wheel products, it would be a shame to lose such reliable mechanical products out of what seems to be going on with the control system. I would hate to be stuck with my team having to weld the frame again next year...

Re: 2009 Control System Possibility?
 

Well heck, why don't we slap an Allen-Bradley PLC on each robot and call it a day? :P

From NI's website:
C Series I/O Modules

A variety of I/O types are available including voltage, current, thermocouple, RTD, accelerometer, and strain gauge inputs; up to ±60 V simultaneous-sampling analog I/O; 12, 24, and 48 V industrial digital I/O; 5 V/TTL digital I/O; counter/timers; pulse generation; and high voltage/current relays. Because the modules contain built-in signal conditioning for extended voltage ranges or industrial signal types, you can usually connect wires directly from the C Series modules to your sensors and actuators.

*****

I'd LOVE the ability to more easily interface industry standard sensors (inductive proxes, throughbeam and reflective optical sensors, etc.) to the new control system.


$419 for this module - functionality - even low current functionality - comes at a price!

Re: 2009 Control System Possibility?
 

I shudder to think about the possibility of having to program robots using ladder logic. :ahh:

FIRST, whatever you do, please let us use a real programming language!

Re: 2009 Control System Possibility?
 

While it will be refreshing to program something new, I will miss IFI. Also I belive that exposing students to Microchip products is beneficial for later in their career.
Brian

Re: 2009 Control System Possibility?
 

Of all things, FIRST needs to make sure that whatever system they go with, that they have support that is at least as good as or better than IFI's. Even though they're a small operation, and there have been failures in some hardware from time to time (statistics states that it's bound to happen with any type of hardware, though), they have ALWAYS been there to support teams and events. From having loaner hardware to excellent phone support to being there to fix the fields, IFI has always gone the extra mile to make sure that things run smoothly, and to help teams feel that they're valuable.

It's almost as though IFI is just a different style of FIRST team.

If FIRST chooses a different controller system, the only thing I can pray for is that the support they give is better than that of IFI, and that's going to be darn hard to beat.

Re: 2009 Control System Possibility?
 

New FTC controller info from FIRST announcement/blog:

. LEGO NXT controller w/55mhz ARM processor for user code
. HiTechnic I2C sMUX sensor multiplexor for expanding number of sensors.
. NXTG, LabVIEW, RobotC programming tools
. 2-way bluetooth communication

There are I2C prototype cards for developing your own sensors, but latency looks like it might be an issue for some sensors that need fine timing control - maybe not - but that is my first impression. The prototype card uses a pre-programmed PIC16LF819.

BTW, the hardware devo kit for CompactRIO which includes processor module and a couple io modules is $5000. Just the real-time controller module is $1500 list.

Re: 2009 Control System Possibility?
 

Since this is a Rumor thread I'll throw a little wrench into it :)

I heard from a little birdy that FIRST isn't looking for another system that they themselves are doing the work....

I won't say who the little birdy is but I enjoyed a laugh w/ them after they told me and a couple of others about this. :D

On a serious note, IFI truly is the most prepared, most helpful, most aware and most friendly let alone understanding company there is. I try and work side by side with one guy and particular (since we make a good team) and though his (and their) job is hard they def. come out on top when it comes to making sure a team's IFI Equip, is set up correctly and that the team can play match after match w/o fail. Their job is hard and I applaud them for doing what they do 24/7 year round for the teams. It'll be a shame to see them go :(

Re: 2009 Control System Possibility?
 

Well, I'm hoping that not too many things change. In many aspects.

As 1554's programmer, I don't want to have too many delays in writing or transmitting code. It's hard enough to make the six-week deadline for us at the pace we worked at this year and last year. (I bet everyone else reading this is thinking that, too.)

However, I don't think learning the syntax will be a problem. Programming languages are all very similar, anyway.

But I think that it would be a bit annoying if we all had to get accustomed to a completely new way of transmitting code. Honestly, I doubt there will be such vast differences in the two systems, but then again... Murphy's Law. Or some variation of it.

Re: 2009 Control System Possibility?
 

When will the 2009 kick-off be
(date)

Re: 2009 Control System Possibility?
 

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

Re: 2009 Control System Possibility?
 

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.

Re: 2009 Control System Possibility?
 

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?

Re: 2009 Control System Possibility?
 

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.

Re: 2009 Control System Possibility?
 

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.

Re: 2009 Control System Possibility?
 

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

Re: 2009 Control System Possibility?
 

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

Re: 2009 Control System Possibility?
 

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"




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.

Re: 2009 Control System Possibility?
 

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.

Re: 2009 Control System Possibility?
 

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?).

Re: 2009 Control System Possibility?
 

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?

Re: 2009 Control System Possibility?
 

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 :ahh: ) 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.

Re: 2009 Control System Possibility?
 

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 :ahh:). 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.

Re: 2009 Control System Possibility?
 

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

Re: 2009 Control System Possibility?
 

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?

Re: 2009 Control System Possibility?
 

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.

Re: 2009 Control System Possibility?
 

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.

Re: 2009 Control System Possibility?
 

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.

Re: 2009 Control System Possibility?
 

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

Re: 2009 Control System Possibility?
 

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

Re: 2009 Control System Possibility?
 

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?

Re: 2009 Control System Possibility?
 

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.

Re: 2009 Control System Possibility?
 

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.

Re: 2009 Control System Possibility?
 

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.

Re: 2009 Control System Possibility?
 

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.

Re: 2009 Control System Possibility?
 

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.

Re: 2009 Control System Possibility?
 

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.

Re: 2009 Control System Possibility?
 

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.

Re: 2009 Control System Possibility?
 

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

Re: 2009 Control System Possibility?
 

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.

Re: 2009 Control System Possibility?
 

The answer to this problem depends on how complicated the solution is. It could range from 1 to infinite depending on what you want. Also, not every single sensor interfaces the same way and even then you can write code multiple ways to do the same thing. Not every single robot behaves the same way. Even then I still find it odd that you have to rewrite the code.

Re: 2009 Control System Possibility?
 

I 100% agree with you(post 80) This year our team spent almost all of our time at the toronto regionals trying to fix the robot or change the programming to make it drivable(we did about 100 accidental donuts throughout the week because of our crazily un-drivable drive platform, but we managed to compete in every round) and our game layer cost a total of about $100 (made of copper tubing and pvc, this also won us the judges award) because we didn't have enough money, we didn't even have team uniforms (although that was more because of an unmotivated marketing team).

If the new control system was more expensive I can't imagine how we would manage to compete, we didn't last year at the current price.

Also, I learned C for this robot, which wasn't to bad because I am already proficient in other languages (python, java, etc.) which are similar, but I HATE easyC. I'm not sure why, it's supposed to be easy, you'd think that would be good right... however the real C code makes much more sense to me as it is not dumbed down, it is complete.

With all that being said, I would really like to see a new control system next year. We had a lot of trouble with the IR sensor. during hybrid mode the IR sensor would only except the first command or two and then take off into a wall. This doesn't really get solved with a new controller but the point is that a more plug and play version with less low level aspects would have allowed us to do some real good things with our robot other than drive, spin, crash. Isn't robotics about making things accomplish complex tasks? not making robots barely scrape by the easiest of tasks.

Re: 2009 Control System Possibility?
 

Read the thread to here. Since I work with NI stuff, C stuff, Assembly stuff,
VB stuff etc etc I want to say that I haven't seen too many monkeys
writing code as was suggested earlier.

Our team used Kevins code pretty much out of the box ( or off his site ).

What you are missing is the PID knowledge to use the information the
gyro is giving you. Thats pretty heavy stuff if you want to do the
whole thing. Driving straight aint so bad.

If you aren't in a big hurry you can use one of the pre-made compass
modules that are on lots of on line vendors sites.

The only thing I wish you guys had was real time debug. No printfs,flashiing
leds. REALTIME DEBUG. FIRST PAY ATTENTION AND GIVE THE GUYS
A BREAK AND WHATEVER YOU DO MAKE SURE IT HAS A JTAG HOOK OR
REAL TIME DEBUG MODULE ON THE CHIP.

Re: 2009 Control System Possibility?
 

My $0.02 on the topic of "build from existing modules" vs. "design and build it from scratch":

Outside of FIRST, it's a lot less about "integration" and a lot more about "design". There are relavitely few industries in which an engineer can just order parts from a catalog, integrate them together, and have an acceptable widget. This is especially true for situations where the widget will be built in more than onesy-twosy quantities. I think isolating students from "low-level" design will give them a false impression about what the majority of design engineering is really about. I'm pretty happy with the status-quo for FRC in terms of what the teams have handed to them on silver platters (the Field Control System, Kevin Watson's templates, etc.) vs. what they have to do for themselves (figure out how to drive in a straight line in autonomous, etc.). I don't think more silver platters are necessary - mechanically, electrically, or software-ically.

On the question of "how many different ways are there to make a robot drive straight?": Lots, actually. The hard part is to figure out which ones will work acceptably well based on the design of the robot, the objectives of the robot, etc. Let the teams continue to figure out how to do it for themselves. I don't think FIRST should lower the bar so far that the only thing left is a bunch of interconnected black boxes, and too few of the students know what goes on inside them.

Someone also made the argument (I'll have to paraphrase) that in the non-FIRST world "mechanical stuff just works, and it's all about the software". My experiences in the various disciplines over the years don't support that. The opposite, actually. Software doesn't wear out. The first copy of the executable file is identical to the 400,000th copy of the executable file. Software doesn't need to be crash tested (physically, at least), vibration tested, EMC tested, UL tested, etc.

Finally, the "code monkey" thing. The root of it (despite what Wikipedia says) is the old saying "if you set enough monkeys at typewriters and wait long enough, eventually one will bang out a copy of Romeo and Juliet". I know I wouldn't ever want to be referred to as just another interchangeable monkey, so I won't use the term when referring to programmers. I think it's an insult -- self-deprecating intent or not.

Re: 2009 Control System Possibility?
 

I whole-heartedly agree. Engineering is not about throwing together blocks of high-level code that "magically" works. If students aren't exposed to what actually goes into making things work the way the do, then what exactly is the point of even doing robotics? Anybody can throw together a program if enough of the low-level work has been done for them. IMHO the biggest problem with the FIRST program in general (just from what I've seen on my own team, but also at competitions) is that, while people are willing to get excited about engineering, when it comes right down to it, a lot aren't really motivated or open to learning. There is a lot more about programming than meets the eye. Trying to get somebody to get the hard work out of the way so you can make an even more awesome robot is not the point. I thought FIRST was not only about getting students excited about engineering, but also about actually giving them skills to get ahead in the workplace. I'm fairly sure that at a lot of companies, you won't be able to just integrate a bunch of high level components and expect it to work. Don't get me wrong, I have no problem with teams that don't have a very experienced programming team to use more high level tools to get a working robot together, and maybe learn a bit more about programming. But its a whole different story when you prevent people (myself included) who have worked very hard to get to the level of proficiency in programming, from using the skills that they have acquired. If FIRST decides to switch to a system that "dumbs down" the programming too much, then I will probably quit. I would probably gain more experience fiddling with various open source projects than I would playing around with a robot that doesn't allow me to program it at a low enough level. I want to gain knowledge and experience, not some new-fangled system that restrains me. Maybe I've very much missed the point and am all wet, and if that is so, then please forgive me, but I felt it needed to be said.

Re: 2009 Control System Possibility?
 

Remember this is a short 6 week project meant to inspire students to study engineering. They don't need to be engineers out of high school, just pointed in the right direction.

Engineers aren't around to design mechanical systems, or to create software packages. Engineers exist to solve problems. High level problem solving is still problem solving, isn't it?

Re: 2009 Control System Possibility?
 

If that simple statement were true, then only 20% of the teams in FRC would even show up to the tournaments; the rest too ashamed that they are not competitive enough.

FIRST is about the students. As mentors we show them that engineering is hard but with disciplined and steady work it can be immensely rewarding. (If it were easy, where's the satisfaction??)

They are all winners the minute they decide to get serious and start contributing to the team's efforts. The competitions are their chance to celebrate what they have accomplished. Whether they end up with a simple, complex, broken or top-tier robot will make no difference.

Teams that stress winning as the primary goal (and expect FIRST to make that easy), set the students up for disappointment when they don't achieve that goal which (gulp) may drive them away from enginering because the students go away with the idea that "it's too hard to be successful"... when in reality they are winners just for participating and working hard.

Re: 2009 Control System Possibility?
 

That is true. I just don't want to be confined to only that. Of course students won't be engineers out of high school. I also understand that there are many different view points and situations with different teams. I just think FIRST should at least keep the options open when it comes to programming. I have no problem with switching to a new system, but I also am very afraid of the programming becoming uninteresting, per se. Then again, maybe I'm just getting overly anxious and there is nothing to really get worried about. Time will tell (hopefully) :)

Re: 2009 Control System Possibility?
 

But isnt' that is one of the pillars of FIRST, at least according to Dean Kamen? FIRST requires the community of engineers to give back and inspire the next generation. The students need to see that we have an important impact on our society, and make a good living doing it. And those jobs are there for them.

Re: 2009 Control System Possibility?
 

I (personally) am not involved in FIRST because I want to win (of course, that would still be nice ;) ). I'm involved because I want to improve my programming skills and knowledge, and I in all sincerity thoroughly enjoy the way that programming for FIRST makes me want to bash my head against a wall.