Horray for throwing large sums of money at threads... in increments of $0.02!

In my eyes, the main problem is speed. The other main issues are variable and program space, but those don't concern me as much. 38Hz is just too slow to do many of the things most of the people I know would like to do, contrary to what Sachiel7 might say (though he (assuming male, sorry) may only be referring to his team, in which case, who knows, he's probably right).

No, it doesn't have to run an embeded Linux kernel. It doesn't have to control a character LCD display. It doesn't even have to have a different enclosure from the Issac32.

In my opinion, Joe Ross put it best, in this post, when he said that "Ultimately, what I would like to see is an interface to completely bypass IFI's microprocessor. That way, they can keep using the Stamp 2SX (or upgrade to a P) and many teams can continue to use it. Then, they provide a way for us to plug in our own microprocessor, of our choosing." I believe that we might be seeing an even more gradual shift to this kind of environment for many reasons. I haven't talked to any IFI or FIRST people about the possibilities, but the fact that, for the past two seasons, they have allowed us to construct our own custom circuit boards, when we're only limited by price (which did, I might add, double, between 2002 and 2003) and availability (DigiKey and FutureFAI as allowed distributors). Perhaps the next milestone may be to allow these seperate circuits to supply PWM signals to the Victors and Spikes (Although, I have to admit that I don't know what kinds of implications this has, offhand. I believe that I've heard that our RCs produce some kind of non-standard PWM signal, *shrugs*, probably totally irrelevant. Just another reminder to hang a scope on one of the RC's PWM outputs...).

Lastly, I've seen so much about using Java/C/C++/Whatever-Else as a main programming language. Microchip's PIC series of microcontroller, Zilog's Z8 series, and probably many others which I've never heard of, already have C based compilers, and give you access to the machine language, which is a heck of a lot more than Parallax does for us, right now (Their tokenizer, to convert what we know of as PBASIC to machine code, is closed source, and it's only a recent advent that they offer it, free of charge, to anyone, though we still have no access to assembly level programming for Basic Stamps).

Blah. I probably have more opinions about this kind of thing, IM or PM me if you take issue with anything I've said, or have any questions.

Sorry for posting again, right after myself. It's been 13 hours, and I think that if I just edit that last post, no one would wind up seeing it.

Last night, Joe Ross alterted me to the fact that if FIRST allowed us to control PWM signals to the Victors or Spikes, by way of the custom circuit (CC), they could not guarantee that the motors / actuators controlled by those Victors and Spikes would be shut off, when the robot were put into disable mode.

Something that might remedy this problem is a kind of a pass-through system. PWM signals would be generated by both the RC and the CC, but signals from the CC would be sent through the RC, and then passed on to the Victors and Spikes, without the RC modifying the signal at all. When the RC is disabled, by way of the competition port, the pass-through portion of the RC would cut the signals from the CC, and the CC would not be in danger of sending PWM signals to Victors or Spikes after a robot has been disabled, anymore.

I'm sorry to have to acknowledge that if IFI decided to implement this system, they would have to redesign the RC, if just a little, because I don't believe it can be done with the current Issac32, as is.

Lots more work for IFI for such a small thing...

I doubt it'll happen, myself.

IFI
 

I'll be seeing Bob and Tom from IFI this weekend at another robotics competition. I will ask them and I will get back to you guys on Monday. Im pretty sure they will know.

Woo! you got my vote for some Allen-Bradley Micrologix PLC's. they would be quite nice for the bot, the programming is all drag and drop ladder logic so inexperienced teams would have no problems plus, its powerfull when you get good with it.

it is also what many people involved in FIRST will be using in the workplace, yet another thing to put under your belt for a career!

~Pyro

before you go off the deep end on features you would like to see in a new controller, remember that MANY teams use the defaut code from innovation FIRST in their robot, and never change a single line of it.

In most matches at the regionals, only one or two bots on the field did ANYTHING during auton mode!

if teams cant handle a simple language like pBasic - how would they ever program in C++?

I just looked at the Javelin specs, and I'm still drooling. If they put in a javalin, it would do so much good for the competition. I'm still trying to think of all the implications. Since it is object oriented, new teams will be able to easilly reuse publically available code, making it easier for them to change the basic program. They also have buffering and timers. This would make writing AI programs actuly feasible.

Object-oriented wouldn't help teams re-use code any more than having a large repository of PBASIC code would. Sure, you can drop in a new object, but you can just as easily drop in 15 lines of PBASIC to accomplish the same thing.

Check out RoboGUI at my website for something quick and easy. It can do most stuff (no auto yet) and is reasonably accurate.

--Rob

Thats why i vote for a BasicX proccessor. Its still alot like Basic just much more powerful. Just look at this comparison. Its also slightly less expensive than the BSIISX that is in use on the current system. Not to mention that it is pin to pin compatible with the BSIISX so hardly anything would need changing.

400 bytes of RAM? Floating-point math? Sign me up!

Input on the controller. I was adult mentor for 1083. I do robotics as a hobby and have written several articles on robotics.

The FIRST controller is very limited in processing sensors needed in auto mode. It is not the language or even the speed but many controlling the IOs, like having interrupts, timing subsystems etc. But I was surprised how well many did by what I would call blind reckoning.

Suggest ions new processor.

More RAM
More Flash
Have sensor inputs that allow for wheel encoders etc
Allow for timing of inputs, like for sonar circuits
Still have the output to relays and victors 884 controlled by FIRST
You can still do all that in a Basic language but have one that teaches good programming techniques

BTW, 38 cycles per second is fine for controlling for the loop.

We were a rookie team so I don't know of the history. But I have heard that in the past rumors had a new processor coming.

Doug

A stupid question but in an IFI ad why does it say our control system use 10 microprocessers???

Well, there are other microprocessors inside the control system, other than the BASIC Stamp. They provide the extra functions that the RC has.

Ugh I just learned pBasic

I am only quessing. But a lot is happening inside the FIRST processor. You do not control directly the outputs, another processor does that so they can shut down your robot at the right time. Another processor would be neccassary for taking care of the communications from the robt controller to the human interface. So they probably use an MCU for each process they are doing.

Even the Gleason Research Handyboard is lightyears ahead of the Isaac32 and BASIC Stamp... They should use Interactive C (the handyboard language) on whatever controllers they use next year cause it's almost exactly like C and it's easy to learn.

and seriously... 32 bytes of ram is not anywhere near enough... and we thought 640 kB was small back in the DOS days... ;)

Gleason Research HandyBoard

edit: added link