BasicX uP for next year

[Rickertsen2]

The basic stamp1 has a PIC in it. I believe the BS2SX has a scenix microcontrollerin it.

[Mark Hamilton]

Originally posted by Duke 13370
The difficulty in proggramming is another challenge that a team must face, making the language easier takes away from that challenge. Our teams are supposed to overcome these hardships and thrive in them. (whether this was intended or not is questionable, but that isn't the point) We should take these difficult situations and throw them into the face of the creators, and say "look, we have conquered your efficiency and complexity problems, what do you want us to do now?".

or something like that.

the clock thing would be nice if they intend us to do a more complex autonomous program next year, though.

A language doesnt need to be "hard" to make for a good challenge. PBasic is really just a annoying language, because of limitations in the hardware. A more featureful language gives you more capability. More capability lets you do more complex things, and is a better test of your grasp of programming concepts. The less time you spend fighting with the language the more time you can do real programming.

[JLambert]

Originally posted by Mark Hamilton
A language doesnt need to be "hard" to make for a good challenge. PBasic is really just a annoying language, because of limitations in the hardware. A more featureful language gives you more capability. More capability lets you do more complex things, and is a better test of your grasp of programming concepts. The less time you spend fighting with the language the more time you can do real programming.

Personally, I see the language and the controls hardware as a limitation. Much like how the mech side is limited to what materials it can use, we're given a limit to make it a little more challenging. Our task is to do our best with what we have.

Normally, I would say it's also cheaper this way, but seeing as how I myself have gotten several free samples from Microchip.com, I don't think it would be terribly hard to get either free or cheap processors from them in large quantities.

Overall, I think the control system does need to adjust with the times, I just don't think that time has quite come yet.

[Duke 13370]

A language doesnt need to be "hard" to make for a good challenge. PBasic is really just a annoying language, because of limitations in the hardware. A more featureful language gives you more capability. More capability lets you do more complex things, and is a better test of your grasp of programming concepts. The less time you spend fighting with the language the more time you can do real programming.

I wouldn't complain if the programming was easier, in fact i'd love a change to some of these other options, but that would be making it much too easy. If they expect another auton mode, though, they really ought to switch to one of the other options.

[Rickertsen2]

A language doesnt need to be "hard" to make for a good challenge. PBasic is really just a annoying language, because of limitations in the hardware. A more featureful language gives you more capability. More capability lets you do more complex things, and is a better test of your grasp of programming concepts. The less time you spend fighting with the language the more time you can do real programming.

Very well said. The BasicX would do exactly that.

[Joe Ross]

Originally posted by JLambert
Personally, I see the language and the controls hardware as a limitation. Much like how the mech side is limited to what materials it can use, we're given a limit to make it a little more challenging. Our task is to do our best with what we have.

Good analogy, but lets take it a step further. In the past 3 years, and especially this year, the mechanical rules have been relaxed a ton. The electronics rules have been relaxed slightly, by allowing the use of the custom circuit board, but the limitations they put on it make it much less useful then it could be.

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. It would need 8+ digital i/o and a serial port (and maybe some other stuff). If IFI were to use appropriate buffers, they would be easily able to tell if we blew up the robot controller, or whether it was their problem. This allows teams the flexibility to use a better microprocessor, or at least one that they are more familier with.

Now obviously this isn't an easy task, but I think the time would be much better spent then just changing the microprocessor, and keeping the black box attitude.

Just the ramblings of a wannabe EE

[Rickertsen2]

Swapping the BSIISX for a BasicX requires no redesign. it is pin for pin compatible with the BS2SX. All they have to do is swap 1 chip. I would like them to go further though. It would be nice to have more I/O options(with buffers) as well as a better display(a VFD or LCD). Poeple are complaining about learning a new system. I think that would be the best part. I like Learning new systems and languages.

[miketwalker]

I agree that the basic stamp chip is getting outdated. With autonomous mode, we overcame some of the problems with timers eventually, but it was a pain. I think we can continue to work with this, but I noticed when working with lots of other teams that sometimes people overthink their functions and make their code super long and use many more variables then they truly need. I think that's mainly the problem, not just the chip. One overcome of the timer problem I noticed with SPAM was for distance to put a switch that gets clicked every however many inches and you can use that so that if boxes stop you or anything happens you'll keep pushing till you go the same distance, I think that overcomes the problems many teams have run into. Maybe more types of sensors (opticals were a great addition last year in my opinion) would make it so robots can do more. Then we might need more variable space, but teams would have a challenge to develop more of a system to work more with the sensors than the timer. There were many methods I've noticed of overcoming some of the issues with the basic stamp chip, and I think we just need to focus more on other methods, that's what FIRST is all about, looking at the challenge and setting off to find a solution, seeing how other teams do it, using that and making a better code the next year. This year they threw us into the deep end of a pool and short circuited many teams *pun intended* but next year we'll know what's coming and in the offseason can breadboard systems and work with them to perform different operations. I think that's a better way then to make it 'simpler coding' because your still challenged and teams are more diverse, and overall makes the competition more interesting.

[Marc P.]

Originally posted by Joe Ross
Good analogy, but lets take it a step further. In the past 3 years, and especially this year, the mechanical rules have been relaxed a ton. The electronics rules have been relaxed slightly, by allowing the use of the custom circuit board, but the limitations they put on it make it much less useful then it could be.

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. It would need 8+ digital i/o and a serial port (and maybe some other stuff). If IFI were to use appropriate buffers, they would be easily able to tell if we blew up the robot controller, or whether it was their problem. This allows teams the flexibility to use a better microprocessor, or at least one that they are more familier with.

Now obviously this isn't an easy task, but I think the time would be much better spent then just changing the microprocessor, and keeping the black box attitude.

Just the ramblings of a wannabe EE

That would open up an entirely new can of worms to the FIRST community. I believe the PBasic language and Stamp IISX processor are in place to allow some degree of sophistication, while not making programming entirely difficult. If custom processor boards were allowed, there must be some standardization enforced, or what's to stop a team from showing up with a 3.06 ghz Pentium 4 based robot? Meanwhile a rookie team shows up using the standard Stamp... as far as autonomous mode goes, who has a distinct advantage? I think the limitations of PBasic inspire a certain sense of creativity in the programming, and is easy enough for rookie teams and new members to pick up and use right away.

[miketwalker]

Originally posted by Marc P.
If custom processor boards were allowed, there must be some standardization enforced, or what's to stop a team from showing up with a 3.06 ghz Pentium 4 based robot? Meanwhile a rookie team shows up using the standard Stamp... as far as autonomous mode goes, who has a distinct advantage? I think the limitations of PBasic inspire a certain sense of creativity in the programming, and is easy enough for rookie teams and new members to pick up and use right away.

If we were allowed to use stuff like that and have a 3+ghz processor, I could just see students setting up LAN parties in the pits and playing each other over the wireless network through the robot. Lol.

[Rickertsen2]

We are a rookie team. Programming the basic stamp is well... to basic. I hate the thing with vengence. Its way too slow and has no buffers. Not to mention it has no support for any advanced programming stuff whatsoever. I don't see it as a challenge because its not a challenge. i just see it as letting me spend more of my time doing more programming and less time overcoming language difecencies. The BasicX is simple yet powerful. I don't understand why so many people see a new processor as some sort of taboo.

[Marc P.]

Originally posted by Rickertsen2
We are a rookie team. Programming the basic stamp is well... to basic. I hate the thing with vengence. Its way too slow and has no buffers. Not to mention it has no support for any advanced programming stuff whatsoever. I don't see it as a challenge because its not a challenge. i just see it as letting me spend more of my time doing more programming and less time overcoming language difecencies. The BasicX is simple yet powerful. I don't understand why so many people see a new processor as some sort of taboo.

That's exactly the purpose behind it. What you call overcoming language defficiancies is the challence of PBasic. Yeah, you could write a robot program in C++, but wouldn't that make the robot function too easy and too capable? I'm not disagreeing that it would be nice to have more power, but as a veteran programmer of 4 years, I've developed a love/hate relationship with the basic stamp, and am beyond fluent in PBasic. Aside from which, going back a few more years, even the IFI equipment we have now is far more advanced than anything prior. My guess and hope is FIRST will not change to anything too different, especially given all the support Innovation First has provided over the past few years. Besides, autonomous mode with a Basic Stamp is part of the fun

[Joe Johnson]

I too have a love/hate relationship with Stamp2/Pbasic.

To be honest, I have found work around for most of the stuff that I need to get done... ...but I know that there are much better ways of doing this.

I wish that IFI would put out a system that allows for multiple user CPU's -- this would allow for those who wanted to to stay with Stamp2/Pbasic to do so but it would also allow those who are ready for something more to program is C++ on a PowerPC core.

Even better, I would like to see IFI come out with something that could be programmed in something like Blocksets from Mat
Lab/SimuLink from Mathworks.

Bottom line for me is that I think that unless they are going to give us some great new features, IFI should stick with what we have.

Joe J.

[Gobiner]

Originally posted by Marc P.
If custom processor boards were allowed, there must be some standardization enforced, or what's to stop a team from showing up with a 3.06 ghz Pentium 4 based robot? Meanwhile a rookie team shows up using the standard Stamp... as far as autonomous mode goes, who has a distinct advantage?

Being able to get 250FPS on Quake 3 isn't going to allow your robot to do backflips on the field. Having a processor running that fast isn't going to help that much, because a decent programmer can do everything you could dream of in PBASIC with the sensory inputs that are available to us.
Also, you can buy a AMD Athlon for $50 including shipping (I just checked pricewatch.com) and there aren't too many teams who can't afford that if it really would help.

Which isn't to say I think that allowing teams to plug in their own chip is a good idea, but I wouldn't mind a hardware upgrade. Wouldn't mind it staying the same, either.

[Marc P.]

Originally posted by Gobiner
Being able to get 250FPS on Quake 3 isn't going to allow your robot to do backflips on the field. Having a processor running that fast isn't going to help that much, because a decent programmer can do everything you could dream of in PBASIC with the sensory inputs that are available to us.
Also, you can buy a AMD Athlon for $50 including shipping (I just checked pricewatch.com) and there aren't too many teams who can't afford that if it really would help.

Which isn't to say I think that allowing teams to plug in their own chip is a good idea, but I wouldn't mind a hardware upgrade. Wouldn't mind it staying the same, either.

I'm quite aware of this, and quite happy with the PBasic. My point is more advanced (electrically) teams would have an advantage in programming in more sophisticated languages on more advanced hardware, i.e. more advanced/accurate/capable autonomous mode, more precise controls, (if a robot can gather sensor data at 400 cycles per second on an 850mhz athlon as opposed to the 25-30 cycles persecond of a basic stamp with a heavy program, there is far more sensor data avaliable to process and react upon if it's gathered at a faster rate), and the like. This wouldn't be too fair to not-so-electrically-inclined teams who stick with the default hardware, incapable of operating with advanced hardware.