New Robot Control System!

[chaoticprout]

This completely awesome, and the only thing I'm bummed about is that I won't see it as a High School student, graduating in 2008.

[Rich Kressly]

Originally Posted by Bharat Nain

The hardest part of accepting a new control system is their familiarity with FIRST. IFI has been a very long time partner and they know the way FIRST works and its requirements. I hope we know who the new vendor is and I hope they attend many competitions next year to understand what is required.

...and here's where my real concern is too. If and I repeat "IF" (becuase we've had no official word) IFI is not the developer or involved in the new system:
1. How well will the new vendor know FIRST? While it's fair to give people time to get up to speed, does anyone really want to work their bottom off during the build and have things not work in competition?

2. How well will teams and volunteers be able to handle the multitude of potential issues that go along with the incredible flexibility we're talking about?

3.. Will the vendor be able to provide the same expert customer service that IFI has provided? A system expert on the ground at every regional from Wed night through Saturday (even when there are ten events in a week) and several at the Championship?

I'm all for new and better as long as it benefits teams and events, but I have very real concerns here.

[Danny Diaz]

Originally Posted by Rich Kressly

...and here's where my real concern is too. If and I repeat "IF" (becuase we've had no official word) IFI is not the developer or involved in the new system.

Every bone in my body tells me this is something FIRST has already dealt with or is currently dealing with. You list a lot of good points, but realize that when you think of all the bad things that can happen (new vendor, support, etc...) there's at least 2 people at FIRST who have also thought of this. Changing technology is never an easy thing to do, it must be approached with caution - I think we should give FIRST the benefit of doubt in such areas.

-Danny

[Roger]

Since we're all putting our wish list items up, I just hope they make the board plugs and numbers a mite bit bigger so I can see the darn things. Good thing the kids are doing it because I certainly can't!

And upgrade from C to something like FORTRAN.





Okay, seriously, we can stay with C. Just as long as Kevin can understand it I'll try to keep up.

[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

[tjcasser]

Originally Posted by ThomasP

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.

Just let me recap something I mentioned earlier in this thread, IIRC.

Having played with robots programed in Java last week, I can tell you that Java ME does work rather well when it comes to developing software for small, power constrained devices. (You actually use the same interfaces that you use for writing programs that run on a Java-enabled cellphone.) .Net CF has a slightly larger footprint, but it too likely could handle the processors that I imagine FIRST is looking at using in the post-2008 era.

When they say 'support for multiple languages', that smacks to me of a device that's capable of running an operating system in some fashion, rather than just a simple processor... so it's back to the whole wait-and-see...

[mathking]

Originally Posted by tjcasser

When they say 'support for multiple languages', that smacks to me of a device that's capable of running an operating system in some fashion, rather than just a simple processor... so it's back to the whole wait-and-see...

I have been talking with some of our other mentors about this. I think that some sort of OS is the most likely alternative. The other possibility we see is a development environment which allows code from different languages to be compiled to processor readable object code.

I will also second the notion that Java has a number of features that do lend themselves to robot programming. In particular Java handles events and exceptions well. Just as a simple example, I made some code for the InteliBrain robot from Ridgesoft that uses the CMU cam and can find the FRC game light and move the robot to within 5 feet of it very quickly. If the Java code is used with an IDE that compiles the code efficiently, it will not be anything like Java byte codes. Something like xCode perhaps.

[mathking]

Originally Posted by Eldarion

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!

Assembly is only faster if you write good assembly code, and you are smarter than the writer(s) of the compiler. A good compiler with a lot of optimization can take high level language code create object code which runs faster than most of the code student programmers could write in assembly. One reason C became the language of choice for embedded chips was the creation of specific compilers which allowed for small, fast code.

[Eldarion]

Originally Posted by mathking

Assembly is only faster if you write good assembly code, and you are smarter than the writer(s) of the compiler. A good compiler with a lot of optimization can take high level language code create object code which runs faster than most of the code student programmers could write in assembly. One reason C became the language of choice for embedded chips was the creation of specific compilers which allowed for small, fast code.

In my post I should have stated that I was referring to the old assembly gurus who could code circles around the C compilers. I would not expect students to be able to code to that level (I cant either! )

[Bharat Nain]

I have been thinking about this and if FIRST was not going to use the IFI processor, here is what I would do if I were FIRST:

1) Research the different ready-made processors available in the market.
2) Pick out everything that is decent and buy them
3) Vigorously test each processor in conditions that real competition would require
4) Research the company and determine if it is a work-able partnership.
5) Work out details with the partnering company to provide adequate supply and support for all FIRST teams.

There are a lot of other things to figure out such as speed controllers, spikes etc.

So, even though we have all our wishes of the type of processor and its features, I am sure FIRST is researching this in a planned manner and will determine what is best for our applications. We might not get what we expect or like, but hopefully it is what is best for us.