New Robot Control System!

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