New robot controller next year?

[Sachiel7]

Ok, a few of my opinions and Knowledge here...
First off, IFI was created for First. So, If (For some odd reason) they do change what we're using, it'll probably be from a recommendation coming from FIRST, and you know how FIRST is with change.
Ok, I can understand the need for more EEPROM space, but I still see absolutely no need to get a faster processor. You're not running an extremely high-demand system, and the processor usually never has speed issues.
Also, I don't see why FIRST would shift to a processor with a different language. It seems IFI is going to keep their partnership with Parallax as long as they can, and looking at the Processor lineup, The Javelin is the only other processor I've found with a non-basic like language. And I don't want to have to learn Java, let alone be programming a Robot with it (makes slight frown)...(smirks)...(bursts out laughing)
um...excuse me...
Plus, PBasic is just so simple, it doesn't make sense to shift to a one-sided language like C that plenty of people would have to spend a lot of time learning, more so than pbasic.
If there are any changes to the IFI system, I could foresee IFI installing some sort of memory expansion, but that's about it.
As for the 10 Processors in the IFI system,
If you didn't already know, there are 3 Basic Stamps in the RC, 1 PIC (I think?) in each transceiver, and a few more in the OI.
Anyway, that's just a few of my thoughts...

[aziandorkess]

Hmm.. makes sense; very logical. But it'd be cool if we had to learn and play with all the new program and robot controller/interface, etc. Understand the probs w/pbasic though. there's not much you can actually do with it except the basics... though i agree; it takes too long to learn the new language, etc. in the time frame we get. interesting ideas.

[Scooter]

At the Lone Star Regional, I was talking to the CEO of Innovation First, and he said that within the next two years, we can expect to see almost half of the match be autonomous. What I would like to see would be the implementation of a protocall that would allow for wireless communication/data transfer between robots. Perhaps IFI could put in a canned standard output that teams could improve upon...Or just have certain values be automatically transmitted to you alliance partner. Though he did not mention anything about a new controller, for this to take place, there would almost certainly be a need for one.

Bill B.

[AlbertW]

you know what'd be really cool? an on-field radio positioning system sorta thing. have a transciever on each side of the field, and have them broadcast timecodes, so your bot could figure out exactly where on the field it was

[Andrew]

A completely different idea...

It might be neat to have something like the lego RCX. The RCX allows event driven programming. A simple default code, which teams can use straight out of the box could easily be created.

Plus, if you don't want to use the supplied drag and drop GUI programming language, you can port over to BrickOS, which is an embedded Linux kernel.

Then, you just program in C or assembly, as you like.

As far as the concern many have raised about the current system is "good enough/fast enough."

We have had to mechanically slow down some sensors and actuators in order to allow us to control them.

We were running up against the "basic run error" limit with our control cycle this year, due to the sensor processing for autonomous code.

We have not been able to run anything fancier than a PI controller because of the unreliable cycle time and slow processing.

The pBasic can be "faked out" to program subroutines. You just have to use assembly style register passing. You could probably create a stack if you were really clever. However, the limit on variable space makes this extraordinarily difficult.

The fixed point, non-negative, 8 bit math is perhaps the most severe limitation. I cannot begin to say how long it took to program and debug a simple proportional control routine the first time. What should have been one line of code turned into about a week's work + 20-30 lines of code. Most of this code was spent with shifting and scaling.

The other down-side to the current pBasic is that it is not transferrable to anything else. Wouldn't it be better to use a more conventional language such as C, where the programming skills developed would transfer?

[Sachiel7]

Like I said before, not everyone knows C.
I personally still haven't learned nearly enough of it to be a programmer for the bot if C was used.
Yeah, I do agree that PBasic does have some drawbacks, but I think that if IFI simply improved what they already have a bit, we'd be fine.

[AlbertW]

C is no harder to learn than PBASIC, and for all intensive purpouses, it's easier to work with. Hopefully if they move to C, the system will support a more abstract memory system.

[Sachiel7]

I'm not saying it's harder to learn, I just think that if FIRST was going to shift to a new language, that they warn us prior to crunch time.
There's no way every team is going to learn a new language within crunchtime next year, especially w/ the predicted 1000 teams.
If First warned us before kickoff, then I'd be fine, but they probably wouldn't do something like that.

[Dave Flowerday]

Originally posted by Sachiel7
Ok, I can understand the need for more EEPROM space, but I still see absolutely no need to get a faster processor. You're not running an extremely high-demand system, and the processor usually never has speed issues.

Maybe not for you. We have serious speed issues this year. Our drive system is very complicated and our autonomous is even worse (performing lots of trig, etc). One run through our main loop is taking something like 100ms. For a closed feedback loop system, that is awful. It's slow enough that drivers of our robot can detect a slight lag from when they change the controls to when the robot reacts. This problem will only get worse for us, and will start to affect other teams as autonomous gets more prevalent and more complicated (I'm almost certain auto mode will be back next year and will be an order of magnitude more challenging).

If you didn't already know, there are 3 Basic Stamps in the RC, 1 PIC (I think?) in each transceiver, and a few more in the OI.

There is only 1 BASIC Stamp in the whole system. The reason? The BASIC Stamp is a toy microprocessor. Don't get me wrong - it's great for programming by high school students and mentors without software experience, and most teams would be lost with anything else. But all the other work done in the system (i.e. the stuff that teams can't change) is done by real microcontrollers that are literally thousands of times faster than a Stamp.

[Andrew]

This problem will only get worse for us, and will start to affect other teams as autonomous gets more prevalent and more complicated (I'm almost certain auto mode will be back next year and
will be an order of magnitude more challenging).

Add to this concern the fact that, as autonomy becomes more "real," we will all need more sensors so that the robot can figure out what its environment is like.

More sensors = more time spent in the serin command, more variables, more processing of sensor inputs to condition the information.

The space for code may become a limiting factor. If you want to save cycle time by using in-line routines instead of subroutines and by using look-up tables instead of trig functions, you rapidly run out of EEPROM to store the thing in.

In the past two years, we have used up the entire variable space, including unused input bits which we doubled as scratchpad. We've been at 52 ms cycle times (which I consider is the outside limit). This year we used up all of our digital inputs. We also used 93% of our EEPROM.

We freed up some of these resources when we improved efficiency in the code. But still, we were creeping close to the boundaries.

With more complicated autonomy, we may have to limit ourselves to a drive train + lots of sensors for autonomy, and skip doing anything else.

[AlbertW]

Didn't they say something about releasing the control system specs before the beginning of build? That would give teams plenty of time to learn C

and keep in mind, though not everyone knows C, NOBODY knows PBASIC

[JasonStern]

I would definitely like to see a processor that can handle inputs better. first time i've dealt with an RC and i can't say im impressed. no negative numbers and no decimals were a nightmare, but worse of all was dealing with sensor inputs. one of the devices on our robot was designed to tell us if we were on the ramp and if we were on it straight. this device had near perfect accuracy with a PWM duty cycle style output, but only +- 10% with an analog output. I originally thought I could use the former mode with the rc, as the stamp has a function to support it, but I was discouraged to find that we have no direct inputs to the stamp and could not implement it. nor could we use the digital inputs of the rc as the stamp does not read them in fast enough. the sad part is that device only ran at 100hz, but the stamp's pathetic 38 hz is nearly a third of that! instead we had to use the analog inputs and sacrifice precision. not to a mention a similar problem (stamp to slow) kept us from using encoder wheels to track our robot.

FIRST, please, if you are going to continue auton modes, which I strongly hope you do, give the programmers and the electrical people on the teams more to work with. there may be a larger initial learning curve, but as someone else said, thats part of engineering. better now then years down the road when pbasic is even more obsolete!

P.S. something that would be nice is something similar to how you program lego bricks, at least their consumer version. the basic user can drag and drop control blocks in place and easily write code. However, the advanced user can bypass the gui and write code in text while having access to more advanced options. it would be a win/win situation for everyone!!

[ahecht]

Originally posted by AlbertWu
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.

I have to second that. I love using the HandyBoard, and coming from programming in pBasic, IC was a breath of fresh air. Interactive C is basically an ANSI C modified specifically for robot control (original created for the MIT 6.270 Competition), It supports seamless multitasking and has the ability to run code that you type on the fly, with no waiting for the code to compile and download.

I don't know if it is possible to change the RC to run off of a 68HC11, or get IC to run on a BASIC stamp (highly doubtful), but it would be much easier.

More info on Interactive C is available at http://handyboard.com/software/icsource.html (the open source version) and http://www.newtonlabs.com/ic/ (the commercial version).

[FreeBSDboy]

Some food for thought.

I have programmed autonomous robots on motorola HC processors for some of my classes when I was a junior in college. It is not a trivial step up from pbasic.

It's not so much learning the C language that would give the most problems, but rather I'd say it would be the seting up of and writing to registers and using interrupts that would be the most challenging aspect. There are a lot of difficult things that the basic stamps / pbasic make very easy to acomplish.

An example would be PWM output on the HC series. You need to have a good understanding of the real time clock and how real time interrupts work in order to get it to function properly. And it is much easier to accidently destroy your motor controlers and servos by screwing up the PWM programming- to the extent that it would be handy to have use of an oscilliscope for diagnostic purposes.

While I am sure that many of the veterans and the more tech savy teams would greatly appriciate such added control over the control system (I know I wouldn't mind it), you have to keep in mind that it also has to be simple enough for rookie teams and beginners to be able to pick up reasonably quickly, which pbasic allows.

So just some food for thought. Not everyone would be appriciative of a control system with a large learning curve. I'm confident that First and IFI will take all this into account if/when they decide to tackle the issue. And I would hypothesize that any changes to the control system would take the form of expanded capabilities without loosing sight of these issues.

Just my perspective. I hope I could shed some light on the topic.

[edited for minor gramatical errors - whoops!]

[ahecht]

Yes, using a raw HC chip is difficult, but as the HandyBoard has proven, that complexity can be elimintated with additional hardware and software. Using a Handyboard with IC, you can be up and running within minutes (although I was using the HandyBoard's built in H-bridge, I was sending PWM signals to servos using the built in functions without any trouble).