New Robot Control System!

[Salik Syed]

I am excited. As a programmer it was frustrating to deal with low level stuff that didn't really matter to me. Hopefully this new system will allow programmers to tackle problems that are actually algorithmically interesting. I'm all for the higher level stuff.

In fact an added layer of abstraction between hardware and software would be beneficial for all teams regardless of skill level... having a more powerful environment would allow for more options to veterans, and an easier interface for rookies.
I don't think everyone needs multi-threading support for a Robot ... but the option of having having advanced features like it is a good thing. I know we had to do our own super simplistic psuedo-threading during autonomous.

The only real necessity is that we use this added power to make things easier... Please don't make it like windows programming or Direct X. A set of library functions and a very simplistic interface for programming would be nice for newbies.

It'd be awesome if we could hook up our robot to a windows laptop style interface. They could even provide software for building simulated robots so we didn't have to wait on the actual robot all the time. It honestly wouldn't be ridiculously hard to do... a simple physics model, constraints tool and a library of sensors/components.

Furthermore I would like to see a kit-bot which comes with more sensor integration... i.e a kitbot which anyone can throw together that will give you shaft-encoders, gyro and camera. With this should be included simple library functions for driving, turning tracking. Then we could actually do something a bit more interesting in autonomous. Right now most of autonomous is writing low-level stuff that should be library code. Moving an arm to a position isn't hard ... it's just tedious

[MikeDubreuil]

My 2 cents...

I would lose confidence in FIRST management if they moved away from IFI. Technically speaking, we could not be where we are today without IFI. I can think of zero reason to move away from IFI's hardware. Their Spike and Victor are considered top of the line components in the robotics arena. From my experience Zigbee isn't a good choice, 802.11 seems like overkill. I bet the new change looks something like this:

• IFI creates the new OI and RC. Victors and Spikes are unchanged.
• OI includes USB support.
• RC includes a Microchip micro and some type of fast user processor, maybe even a DSP offering oodles of memory.

[sanddrag]

I predict an absolute coordinate field positioning system in 2009. I mean, they give us a lot already, and not a lot of teams use it. Too many do-nothing auto modes. You gotta look at it like this: what are they are they gonna do to make it so easy that you have no excuse not to do it? That's now the FRC control system technology has been moving the past few years, and I bet for 09 it will take a big leap.

[Chris Marra]

Originally Posted by sanddrag

I predict an absolute coordinate field positioning system in 2009. I mean, they give us a lot already, and not a lot of teams use it. Too many do-nothing auto modes. You gotta look at it like this: what are they are they gonna do to make it so easy that you have no excuse not to do it? That's now the FRC control system technology has been moving the past few years, and I bet for 09 it will take a big leap.

http://www.chiefdelphi.com/media/photos/26078
I'd love to see something like this implemented for teams. At the same time though, providing teams with a new dashboard capable of mimicing something like StangPS but for a kitbot frame with 4 encoders would be a HUGE step forward for enabling teams to compete in autonomous.

[Eldarion]

Originally Posted by Chris Marra

http://www.chiefdelphi.com/media/photos/26078
I'd love to see something like this implemented for teams. At the same time though, providing teams with a new dashboard capable of mimicing something like StangPS but for a kitbot frame with 4 encoders would be a HUGE step forward for enabling teams to compete in autonomous.

That brings up an interesting point. How many projects of the size and scope of that one are going to be affected by the RC change? I know mine will be affected somewhat, but can you imagine if someone got a perfect autonomous system (or AI...) completed that only ran off of the RC, and then the hardware (and possibly the programming language) changed underneath them?

I'd be steamed!

[Mark Pierce]

I think it's great that we now know:

1. That 2008 will have a similar control to 2006 & 2007
2. That they are working on the next generation now.

I'd still like to see updated compiler and libraries for next year, but am really happy to see improvements coming. I've seen the evolution from the 1999, 2000-2001, and 2002-2003 Basic stamp based controllers to the 2004-2005 8450 controllers to the 2006-2008 8722 controller. This is the first time we've known this soon that change was coming. I hope we get the tools early enough to install on the school computers and have training sessions before the season starts. I hate trying to guide student programmers, install tools, and learn a new system's intricacies during build season.

My wish list includes (I really don't have time to prioritize these):

1. Easier sensor hardware interfacing (SPI and serial ports, encoder interfaces, etc.)
2. Better debugging tools and robot feedback. I've spent way too much time working around chip errors/compiler errors/communication glitches/Easy C quirks/etc.
3. Better connectors and wiring methods.
4. Libraries and tools to simplify programming

I hope that a some of us get a chance to provide input and help in the new system. I'd be happy to help test and develop libraries/training resources for the new system before the 2009 build season.

[JaneYoung]

Originally Posted by Mark Pierce

I hope we get the tools early enough to install on the school computers and have training sessions before the season starts. I hate trying to guide student programmers, install tools, and learn a new systems intricacies during build season.

This aspect of experiencing a successful year is very important.
a. it helps mentors mentor
b. it helps students learn without added stress
c. everyone can work more efficiently

[Cuog]

I'm certainly excited about a new control system for 2009. Sadly I may not be on a team that year as I graduate in 2008, but mentoring sounds like fun

For me and I'd hope many out there a hardware change will bring about new and exciting possibilities. For me it really is about the adventure and not the end result, and I hope that these changes bring a new and exciting adventure. Whether they stay with IFI or not doesn't seem to be well addressed but I don't think it matters, if its IFI they will likely do as they always do and work closely with teams and come out with something great, if its not IFI then it will be another company that I am quite sure will do the same thing before FIRST would consider them for such an integral part of the robot designs. I certainly have faith that the many brilliant minds running FIRST will be able to pull this together.

Also I would like to point out to those worrying about time that build season is 6 weeks, or roughly two months because there is still work happening at competiions and on fix it windows etc. so FIRST has given itself the equivalent of 10 seasons to work this out. Just think of how much we accomplish in 10 seasons, I'm sure FIRST can do the same.

I think that a new processor with lots of power and options will be a great improvement. I would love to see something that can use graphical interfaces like EASYC to get a quick autonomous for those that want it, and still the option for the embedded linux people to "hard code" their own amazing systems. By giving so many options that it will be hard for any team to use them all I think FIRST will really open the door for better autonomous modes just because of the number of choices.

This may also be another chance for FIRST to level the field again. With the new system rookie teams and veteran teams will be pretty close to each other once again in terms of knowledge and it will encourage a LOT of cooperation among teams which was my favorite part about this year's game.

[Andrew Schuetze]

Originally Posted by Adam Y.

It's a robotics convention/conference. It's more bussiness related than anything. Soemeone from IFI is giving a talk about the market for educational robotics.

Here is the abstract from the conf. webpage


Robotics in the Classroom
- Jason Morrella -
Director of Development, Education and Competition
Innovation First


At Innovation First, Jason Morrella is helping to develop the Vex platform to meet the wide variety of demands and needs facing educators and the educational robotics market for middle schools, high schools and universities/colleges. Before joining Innovation First, Jason was a Regional Director for the FIRST Robotics organization covering the western United States. Jason has spent ten years working with educators and industry leaders to help schools build a foundation to develop and support robotics programs, and for communities to hold competitions for these schools to participate in. Before joining FIRST, Jason was a teacher and robotics coach in the San Jose Unified School District, where he was named Teacher of the Year for the 1998-1999 school year.

[John Gutmann]

Originally Posted by Gamer930

What other languages could it be??? Java?? actual C++?? C#??

That doesn't depend on the processor it depends on the compiler. I am sure if you looked hard enough you could find a compiler for the controller now that you can program in BASIC. I am sure they are going to pic a Processor that has alot of availible compilers. Which would force me to lean towards the AVR......or an ARM if they wanted us to have higher processing power. But for some reason I just don't think they would go for an ARM processor, I don't think it is neccesary. Basically anything you can do on a 32 bit ARM processor you can do on an 8 bit RISC processor it just takes more clock cyclesm and maybe additional hardware. I don't see any problem with sticking with an 8 bit system, I have seen 8 bit webservers, and USB systems, etc. I would put my money on a atmega128 or a atmega2560 both by atmel.

But then again, I may be a little biased.......

-John

[Eldarion]

Originally Posted by John Gutmann

That doesn't depend on the processor it depends on the compiler. I am sure if you looked hard enough you could find a compiler for the controller now that you can program in BASIC.

http://www.melabs.com/products/pbp.htm



(No, I haven't used this product, as I happen to like C. But it was given good reviews by Nuts and Volts magazine)

[ThomasP]

"adaptability to a wider variety of programming languages"

Anyone else thinking .NET?

I think it's the most obvious choice, one control library for the bot and people get a choice of 3 different languages to program in.

[Eldarion]

Originally Posted by ThomasP

"adaptability to a wider variety of programming languages"

Anyone else thinking .NET?

I think it's the most obvious choice, one control library for the bot and people get a choice of 3 different languages to program in.

Interpreted languages, or for that matter languages that require large library files to run compiled programs, are generally not suitable for embedded control. Simply put, it would require a small laptop in order to do a typical robot's tasks using Java, .NET, Visual Basic, or any other language of that type due to the increased runtime overhead, both in terms of the CPU and RAM.

The fewer layers of abstraction, the faster the program will run, with assembly language being the fastest. However, this speed increase is offset by increased development time. I believe a good compromise is reached in the C programming language, as do many other robot programmers!

Something like EasyC is different in that it actually reduces your high-level instructions to C and them compiles the resulting C code (correct me if I am wrong here!). If the current trends continue and no low-level access is required, then EasyC is probably the best solution to the programming problem.

There are two ways that you can utilize increased CPU speed or RAM storage:
1.) You can program as efficiently as you did on the smaller machine, and as a result the machine can do more tasks, or
2.) You can fill up the new resources with programming language "bloat", offering few new features and probably introducing many bugs!

Just my $0.02.

[ThomasP]

Originally Posted by Eldarion

Interpreted languages, or for that matter languages that require large library files to run compiled programs, are generally not suitable for embedded control. Simply put, it would require a small laptop in order to do a typical robot's tasks using Java, .NET, Visual Basic, or any other language of that type due to the increased runtime overhead, both in terms of the CPU and RAM.

The fewer layers of abstraction, the faster the program will run, with assembly language being the fastest. However, this speed increase is offset by increased development time. I believe a good compromise is reached in the C programming language, as do many other robot programmers!

Something like EasyC is different in that it actually reduces your high-level instructions to C and them compiles the resulting C code (correct me if I am wrong here!). If the current trends continue and no low-level access is required, then EasyC is probably the best solution to the programming problem.

There are two ways that you can utilize increased CPU speed or RAM storage:
1.) You can program as efficiently as you did on the smaller machine, and as a result the machine can do more tasks, or
2.) You can fill up the new resources with programming language "bloat", offering few new features and probably introducing many bugs!

Just my $0.02.

They have a .NET Compact Framework, Java Micro Edition, etc... with more processing power and memory, the new RC could easily run one of the newer languages just as fast as the current RC runs C and then it will only get faster from there.

[Qbranch]

Still though... I'm sure the stack sizes (not to mention pertinent memory associated with the interpretive code executor, and all the processing overhead for that) are massive... probably far beyond what an embedded processor can handle. A blackfin or coldfire maybe, but...

<rant>

well to put it simply i like a low weight class for my software... a medium amount of hardware, light software, means fast execution. I'd rather have my quick and fast C than a big bulky processor running a whole ton of code I didnt write (means that it'll probably crash since its near impossible to debug their machine code)...

</rant>

well... maybe i'm old fasioned... just i've always found the close interatction with the hardware of the processor that assembly and C provide...

-q