2003 Programming
 

Hey, does anybody know the story on programming for the 2003 controller? Still pBasic as always, or new language? Expanded memory? I'm in the dark here, and the ninnies are buggin me already...

I don't think anyone knows. Innovation First has pulled all the documentation for the "Full-size RC" and won't put the revised documentation up until mid-December. We'll have to wait and see. If I were to take a guess, I would say it will still be PBASIC, same memory limitations, just a different default code.

Ditto.

Given that the OI you got with your EduBot is the same sa the one we will use for the real RC, I'd guess it's not changing much. A few things that may be different:

autonomous control?
user-defined feedback on OI
Oscilator (sp?) similar to EduRobot
Two dashboard specs (see the OI documentation on the dashboard port).

Other than that, I'd guess it should be about the same

It would be really nice...
 

If they switched from PBasic to a Java based system.

The information I have is over a year old now, but when I talked to Eric, he seemed very interested in the idea of supporting other programming languages. Basically, FIRST primarily wanted to allow teams to continue using PBasic if they chose to. They also wanted to allow teams to use another programming language if possible (Java and C were the two that came up then). I have no idea if InnovationFIRST is working on anything like that. I was told that if we were going to see it, the possiblity of seeing it would start this coming year.

Matt

It'd be pretty neat if they used the Java Stamp Modules from Parallax in the controllers. It would throw some spice into the mix for the programmers. Everyone would have to learn Java...

:D


The negative side of the Javalin Stamp is increased complexity. I was reading through the manual and it said that serial input in the new modual is seamless. By this, it means that data is input into a buffer in memory, and it is up to you to check for the data. When the data comes, it comes, no matter what.

The positive side is that the data is constantly updated without having to wait for the Stamp to finish execution. This is very useful, because you are getting the latest data when you are doing your in-program calculations.

Another positive side of the Javalin Stamp is SRAM memory. SRAM is much, much faster than EEPROM, resulting in a faster execution time. Also, the memory is "flat". Your variable space and code space is the same. This means MORE VARIABLE SPACE!

This is the largest improvement over the BASIC Stamp. The previous stamp transferred data from the memory in a serial nature, and it used EEPROM, both of these factors being considerably slow. Although the stamp ran off a 20Mhz PIC microcontroller, it continually had to wait for the EEPROM to send it the next instruction. The new SRAM is connected in a parallel nature, resulting in much faster memory transfers.

The last big improvement is... of course... decimals! They are no use for output... but in your calculations they can be a big help.





Personally, I think the transition to the Java Stamp would be a good one. The biggest advantage is that the students are learning a programming language that they will actually use, not some proprietary BASIC mock-up.

Java is very easy to learn... And increased complexity is a very good thing. PBasic is far too simple of a programming language for an increasingly complex field such as robotics. Even though I dont think java is the best solution, but it is a good step towards a better programming solution for First. And the learning that would require for students to learn java would be much better spent then learning PBasic/increasing their skill in PBasic. Java can be and is used in real world apps unlike PBasic.

And just think about it... a First robot with a ip address and ftp server! Thanks to java.

Java Stamp
 

I'll agree with you there with the Java Stamp (actually the Javelin) over the Basic Stamp. I'd like to see something better meself.

Most embedded systems are done in C, then C++ with more and more Java appearing. With the availability of Java compilers, that is much more feasible nowadays.

It's also much easier to do cross platform development in Java than in any other language. Coming up with an emulator or simulator should be much easier as well. The Java classes for robot I/O would be pretty easy to rewrite for those purposes.

The multi-tasking capability is definitely the next step in robot programming. Almost a necessity in really good robot programming.

The Basic Stamp is nothing more than a PIC with a PBASIC interpreter. Thus, the PIC could be programmed in C with a custom application as well, such as robot control.

Of course, ideally, I'd like to see an embedded Linux in there to do some really cool stuff. I could do anything in C, C++, Java or whatever.

I'd personally like to see Lisp/Scheme implementations--the power of Scheme is truly overwhelming.

Anyway, if you really want to do something in C/C++ during the offseason, you can always use RoboCon. It's available in the whitepapers as well as at my website:
http://FIRSTprograms.tripod.com/Programs.htm

The reason against switching to Java is the same complexity that some seem to be a good thing. Java is much more complex than PBasic. Namely, the Object Oriented nature of Java makes it quite a bit more complex to learn than PBasic. It also requires a knowledge of functions/methods, encapsulation, data hiding, and quite a few other things. It's unlikely that the default program code would not take advantage of this. There would also be numerous more runtime errors that would have to dealt with. The main issue is that a number of teams have problems with getting the programming to work now. FIRST is not going to change the programming situation unless it's an optional change (think the same way that the electronics board was added this year). From someone who teaches Java to college students, it's not going to be nearly as easy to get high school students to learn it quickly.

For programming on PIC chips, the most commonly used language is Assembly. Following that, it'd be C (not C++). I don't have any actual information to back this up but I doubt that the JStamp uses a PIC chip as they just aren't powerful enough to run a JVM. I'd guess something like the Motorola 68000. I'd really not expect to ever see LISP/Scheme. It's too heavyweight for use in an embedded system and just really isn't suited to it.

Matt

it wouldnt be hard for them to throw in a Intel StrongArm 200mhz chip in there and redesign the robotics controller using standard comsumer tech... And if java was used the support based for new people using the Java based RC would be much larger.... imho

The StrongARM would be the exactly wrong chip for a robot controller. And there's a simple reason for that: the StrongARM doesn't have the components built in that we need. There's no PWM controller on a StrongARM. There's no serial input/output controller. That's just off the top of my head. The StrongARM is a microprocessor. What is needed for FIRST is a microcontroller. Adding extra chips just increases the cost and complexity of the system.

Again, the reason for sticking with PBasic is not the size of the user base, but instead the ability to accomplish some programming with minimal knowledge of PBasic. It requires quite a bit larger knowledge of Java to accomplish much in Java than it does in PBasic. Java probally is the superior programming language. It is much more powerful. However, because of that, it's harder to learn the basics of the language. It's that simple.

Matt

The Next Chip?
 

The StrongARM may be a possibility, but I haven't seen many instances of it being used in embedded systems. I see that the tools are out there for embedded ARM development.

Many microcontrollers are microprocessors where the CPU core has additional I/O circuitry wrapped around it. Many of the old 8 and 16 bit micros have morphed into use as microcontrollers since they are no longer useful in personal computers. Motorola has done this with the 68000 and the PowerPC. Even Intel and its' licensees have embedded versions of the 386, 486 and Pentium.

The auto industry is a very heavy user of embedded chips, and they often ask the manufacturers to design chips just for their needs. For example, Ford has the PTEC which is an embedded version of the PowerPC chip.

As for Scheme, yes it's powerful, but a bad choice for embedded and real-time programming. Any language you use must have deterministic behavior in that you know how long it takes to respond to events (latency) and how long it takes to perform a task (performance).

Javelin Stamp
 

I think they are going to offer teams a choice between controllers. If a team wants to use the traditional controller, then they can use it, but if a team wants to use the Javelin Stamp Robot Controller then they will be able to use it. Because the OI is using a Serial Stream to interpret data from the RC, it does not matter which Robot Controller a team uses. The same OI (included with the EduBot) will work with the RC.

Something is changing though. Otherwise, why would Innovation First remove the default program from their website which has not changed in 3 years?

According to the Javelin Stamp manual, they have designed the manual to help PBASIC Stamp users to convert to Java. So although Java is more complex, Parallax understans it and is trying to help people convert.

Although a lot of what you said is true, people don't necessarily have to program in object oriented fashion. They can still program their entire bot as a stream of commands within the main() function. It's possible to do that, although it goes against everything that Java stands for. Once you take that stuff out, you have an easier form of Pbasic. Ultimately, Java is easier because PBASIC has so many mathematical limitations. I can see that the transfer from PBASIC to Java may be confusing, but learning the mangled form of Java I described would be easy.


Java would give the more advanced programmers much more flexibility in what they can do. The biggest advancement in the Javalin stamp is TIME! Yes, the Javalin can tell differences in time. Differences as small as 8 microseconds, I believe. Another big thing is multitasking. You can set an operation to be performed every x number of seconds and continue chugging away at robot code until x number of seconds has passed.

You are contradicting yourself. You have high school students building mechanical transmissions rivaling some automobiles. Some students use sophisticated CAD software and automated mills to create complex parts for their robot. Yet you say that FIRST students are incapable of learning simple Java? Bah.

I took Intro to Java in my Senior year of High School at the local University. 4 credit class. I passed with an A. It was a rather fun class, I fell asleep a lot, but the labs were interesting. To some people it may have seemed difficult, because they weren't motivated.


However, in all practicality, I highly doubt Innovation FIRST would make the switch. I'd be really happy if they did, but I doubt it would happen, mainly because the EduRobot is already programmed in PBasic, and I don't think they'd want to confuse the Rookies. If anything, they'd give them the preseason to learn it.

It wasn't necessarily that they weren't motivated. Back about 20 years ago I was a TA for a programming class in college. (BASIC and FORTRAN IV) One of the things the professor said was "approximately 25% of your class WILL fail. It isn't that you are a bad teacher or that they are bad students. Programming requires a certain turn of mind and some of them just won't get it no matter how hard they try. But when they do get it you will know"

He was right too. Some students walked into class and either had it already or caught on very quickly. Others never did. The fun students were the ones that caught on somewhere in the middle. Their quiz scores would go from 30% to 95% in a week and suddenly they would be all excited about the class.

The ones that never did get it changed their major and got out of engineering. They probably should not have been there in the first place. Not everyone is cut out to be an engineer, and that's OK. We need people to do all kinds of jobs, the important part is to do work you are fit for.