New robot controller next year? [Archive]

redbeard0531

20-03-2003, 19:18

Originally posted by The Lucas
Could someone please explain the purpose of gosub? It is just a goto with a return statement, totally worthless.

GoSub is an important feature from the basic lineage. Remember, pBasic is used for much more than just our robots.In the BASICs, a sub-routene is like a void function in C/C++/Java. An important aspect of a subroutene is that it will always go back to where it was called from. This is especialy important in code recycling. Imagine if you had to keep track of every place that a function is called from! It also helps with organization; every section can have it own subroutene that each subsystem can work on independently of the rest of the program.

Jeff_Rice

20-03-2003, 19:59

A new controller would rock! I would love to play with something new!

Maybe they should have it be a quantum microcomputer. There were so many times this year that I wished a bit had three settings(on, off, on and off).
:D

Sachiel7

20-03-2003, 20:34

You sure he didn't mean that IFI was coming out with a new system? Just cause IFI could be making a new system doesn't mean that FIRST is going to use it. In fact, I'll bet that It'd be cheaper for FIRST to get the same type model as used currently if IFI were coming out with something new.
Anyway, I still hope that if we Do have a new controller, that programming isn't biased to a specific language like C or Java...
PBasic is just so easy, and evey programmer SHOULD have some basic in them...
Mabie IFI's making a controller with the Javelin... (Shudder)
Sorry, I just don't have much Java experience...
I don't want to be put out of a job by a new controller!!!
SAVE ME!!!!!!!!

The Lucas

22-03-2003, 00:16

Originally posted by redbeard0531
It also helps with organization; every section can have it own subroutene that each subsystem can work on independently of the rest of the program.

Ya I use it for organization too. I am just angry with it b/c last year I had to write the same long routine for 3 identical mechanisms. I almost ran out of EEPROM space (I didnt want to mess with a new page). I thought about simulating a function call, but that takes extra RAM. Also, due to a couple of connections btw the variables and other routines, I couldnt use scratchpad. Last years bot had way to many features out of the box and we quickly eliminated many of them.

AJ Quick

25-03-2003, 18:53

I would like to see a operator interface, and robot controller, that is more resistant to water. It rained on our OI at UCF, and we needed to get a new one.

Ryan Foley

25-03-2003, 19:51

Originally posted by AJ Quick
I would like to see a operator interface, and robot controller, that is more resistant to water. It rained on our OI at UCF, and we needed to get a new one.

That got me thinking, perhaps that is what IFI is going to do

water game next year anyone?

perhaps i am just way to tired to think straight

A new controller wouldnt be to bad, I would have to spend all my time learning it, as I am just starting to get good with the old one after 2 years

Joe Ross

25-03-2003, 19:54

I heard similar rumors this year, specifically, a controller 25x faster then this one.

Then again, I can't remember a year in which there weren't rumours of a new control system for next year.

Ian W.

25-03-2003, 21:23

i've heard PSX controller ports, at least two, instead of game ports. i prefer gameports, as i've almost memorized the pinout now :p. be interesting though, to drive with a PSX controller...

Stephen Kowski

26-03-2003, 08:30

I have heard that is going to be based on the Javelin Stamp. Java?! oh well im glad I won't be programming that.

Nate Smith

26-03-2003, 09:04

After talking to the IFI rep at Great Lakes, all I could get out of him is that a new controller is in discussion...whether or not it will make an appearance, and then if FIRST will use it, are two separate issues entirely...

KenWittlief

26-03-2003, 11:55

I get the pretty clear impression that Innovation First is driven by what First wants - so they would not be designing/building a new control system unless FIRST was asking them to.

And they would not build it unless they were certain FIRST would use it.

Remember back in the day, before Victor speed controllers? when we use Rebels on the Bot?

Sachiel7

26-03-2003, 12:16

I think that if FIRST and IFI do plan on changing the OI and RC next year, that they should give out the info on it and it's programming language pre-season.
It would be a huge hurdle to Learn a new language AND write the entire program within the 6 weeks.

KenWittlief

26-03-2003, 12:29

but what an excellent engineering lesson that would be!

thats how it is in the real world - engineering is all about change

when things stop changing you dont need engineers anymore.

The ones that can deal with rapidly changing requirements, and learn new systems quickly, are the ones who achieve the most success.

Adam Y.

26-03-2003, 15:19

i've heard PSX controller ports, at least two, instead of game ports. i prefer gameports, as i've almost memorized the pinout now . be interesting though, to drive with a PSX controller...
I heard someone said on another forum that in an ad by innovation first that their controllers can be controlled witha play station controller but this is only a rumor.

Rickertsen2

26-03-2003, 19:59

<complaining>A new control system would be the best thing to ever happen. As for PSX controller ports. I highly doubt it. But at least bidirectional ports would be nice so that we ca nuse force feedback type stuff. I would like to see something like a BasicX (http://www.chiefdelphi.com/forums/showthread.php?s=&threadid=18581) or even a full blown embedded computer. The other thing that would be awesome would be some TTL outputs on the RC. What about a real disply like a VFD or an LCD. None of this LED segment display crap. </complaining>

scuba_sm

26-03-2003, 21:18

Originally posted by KenWittlief
but what an excellent engineering lesson that would be!

thats how it is in the real world - engineering is all about change

when things stop changing you dont need engineers anymore.

The ones that can deal with rapidly changing requirements, and learn new systems quickly, are the ones who achieve the most success.

I think we saw a bit of that this year, with the introduction of bins. A lot of teams had gotten really good at handling balls, but the bins were a complete unknown, and some of the rooky teams did as well, if not better than some of the teams that have dominated in the past. As for an underwater game, I'm not so sure that FIRST would really go for that... As much as they like to switch things around, that would be a little much. They tend to reuse as much as they can, but there would almost nothing that could be reused from this year's field....

S cubed

Rickertsen2

29-03-2003, 16:39

A JSTAMP would be an awful idea. A BasicX or OOPic on the other hand would be great.

Check out the topic:
http://www.chiefdelphi.com/forums/showthread.php?s=&threadid=18581

J2Kraatz

29-03-2003, 18:33

I hope we get new interface and controllers because this years were a little bit of a pain to do deal with. I mean in a programming way.

Pin Man

30-03-2003, 19:58

I heard its true...

HolyMasamune

31-03-2003, 01:59

a new robot controller would be really cool, giving variety to the electronics and programming group :)

Alex1072

31-03-2003, 02:32

If they want any kind of serious control system, they have to switch to a different controller. Frankly from a programming stand point, FIRST is not a control system competition in anyway. If they intend to keep autonomous mode, and if they want teams to develop better AI, they would HAVE to switch to a better controller. Something that uses a non-obselete language would be nice. PBasic is a mix of assembly and basic. To me it looks like they got the worst of both worlds. Only thing missing is line numbering...
But back to the point, it would be nice to have C, or Java even.

Ken Delaney

31-03-2003, 07:25

At the Annapolis Regional I briefly spoke with Dave Lavery. One topic that was discussed were thoughts on a new control system. He wants to know people's ideas about processors, languages, what features we would be looking for in a control system. So far this thread has echoed a lot of my thoughts. Keep it going.

Rickertsen2

31-03-2003, 16:47

As far as languages go it would be nice to either see C++ or Java

as far as features go it would be really nice to see some TTL I/O lines as well as an LCD or better yet VFD display for feedback and debugging.

Whatever processor they use, it better have alot more memory as well as be alot faster. (giving us some kind of motorola procesor and bundling a compiler such as the one made by metrowerks for use for motorola processors) how about a BasicX (http://www.basicx.com/Products/BX-24/bx24main.htm). The basic Stamp is just pathetic. And the current control system runs too slow to even read a whel encoder without the help of something like an external pic to count the pulses and relay the info the the control system. The lack of buffers on the current control system further exacerbates the problem. As i have said in other threads i am all for a new control sys.

Hailfire

31-03-2003, 19:38

Yeah, you always hear that robots can be programmed using C++ but you never see it. Could you imagine though, that just with an application all you would have to do to program the robot is punch in a bunch of values and push a bunch of buttons and it would automatically program for you? That'd be nice to have.

Sachiel7

31-03-2003, 20:59

I personally see know reason for a faster processor. We have never had speed issues w/ processing at all.
Also, I see no reason to jump to a different language, as PBasic is good to work with, for newbies and experienced programmers...

Ian W.

31-03-2003, 21:19

while a faster processor with more functionality won't be shunned by me, it's not *needed*. it's nice and all, but it's like frosting on the cake. it's simply not crucial to robot function to have linux embedded in the robot. of course, just because it isn't needed doesn't mean i wouldn't mind seeing it... :p

Ryan Foley

31-03-2003, 21:22

take into account soe teams who have almost no programming skil.
I know my team is just starting to learn how to do the basic programming in PBASIC.

Having all that training on the Isaac 32 system and PBASIC worth nothing because we switch systms would not be cool for some teams.

Switching either the system (keeping PBASIC language) or just the language (keeping the 32 system) wouldnt be bad,

switch both and some teams could be in serious trouble (i know mine would)

FotoPlasma

31-03-2003, 21:57

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 (http://www.chiefdelphi.com/forums/showthread.php?s=&postid=141190#post141190), 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.

FotoPlasma

01-04-2003, 12:41

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.

BBFIRSTCHICK

01-04-2003, 15:50

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.

PyroPhin

01-04-2003, 16:45

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

KenWittlief

01-04-2003, 17:08

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++?

Alex1072

01-04-2003, 17:55

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.

rbayer

01-04-2003, 18:36

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.

Halfire:
Could you imagine though, that just with an application all you would have to do to program the robot is punch in a bunch of values and push a bunch of buttons and it would automatically program for you? That'd be nice to have.

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

--Rob

Rickertsen2

02-04-2003, 17:09

Originally posted by KenWittlief
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++?

Thats why i vote for a BasicX (http://www.basicx.com/Products/BX-24/bx24main.htm) proccessor. Its still alot like Basic just much more powerful. Just look at this comparison (http://www.basicx.com/Products/BX-24/bx24compare.htm). 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.

Jeff Waegelin

02-04-2003, 19:38

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

Doug Leppard

05-04-2003, 20:14

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

Adam Y.

05-04-2003, 21:49

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

Jeff Waegelin

05-04-2003, 21:51

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

MattK

06-04-2003, 03:15

Originally posted by redbeard0531
Hopefuly no more pBasic. I would love it if they moved to an event driven language, but that is unlikely. If not, they should at least give us the ability to use real functions where you can pass stuff in, and return stuff.

Unlikely, but we can always hope;)!

Ugh I just learned pBasic

Doug Leppard

06-04-2003, 06:15

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

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.

AlbertW

09-04-2003, 13:21

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 (http://www.gleasonresearch.com/)

edit: added link

Sachiel7

12-04-2003, 20:53

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

12-04-2003, 22:07

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

12-04-2003, 22:53

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

13-04-2003, 06:31

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 :D

Andrew

13-04-2003, 10:44

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

13-04-2003, 18:41

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

16-04-2003, 13:33

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

16-04-2003, 14:26

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

16-04-2003, 14:38

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

16-04-2003, 15:03

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

25-04-2003, 16:40

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 :p

JasonStern

25-04-2003, 17:16

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

26-04-2003, 01:12

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 (http://web.mit.edu/6.270/www/home.html)), 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

27-04-2003, 18:44

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

27-04-2003, 22:00

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

MichalSkiba

12-09-2003, 23:03

If FIRST wants to move towards either a longer autonomous period or splice it into a different section of the heat were dead-reckonning would be impractical, then a better processor would definately be needed. If a mock GPS system, multiple real-time IR, gyro,... sensors, and intra-alliance communication during the autonomous mode is a realistic goal for either this comming year or the one following, then I'd suggest using an ARM Thumb microcontroller, and programming in C.

The ARM Thumb uC has more then enough processing power and speed to comprihand the demands of keen programmers for years to come. Its core has DSP features such as barrel shifters and single cycle multiplication, to speed up signal interpretation. It was a plethora of General Purpose IOs and on-board peripherals that would allow the designs to be expandable (allowing for the addition of an NTSC/H.263 codec for feeding video streams).

C is fast, powerful and relatively easy to use. Additionaly, theres a better chance that a software mentor would be able to help out with C then with pBASIC. Teams won't have to program low-level hardware settings like registers if a kernel (and RTOS?) is provided by FIRST (most likely burned into a ROM). The kernel could be something like uCLinux for example. The kernel could include a block that would give FIRST admin privliages [FIRST = root], such as the ability to cut power to the robot (like at the end of a heat). Headers with libraries and various global functions could be provided by FIRST, or made public by various teams, to further ease programming.

I strongly beilive that there is enough time within the 6 week timeframe to learn fundamental C and to program the robot. If you already know one programming language, such as pBASIC for example, switching to another would definately be easier. Additionally, even more so then linux, there are huge talent pools and reasources avalible on the internet and in books, incase anyone has any questions about programming in C; far more then for pBASIC.

So what about teams that don't have enough people to dedicate to programming? Well, too bad. Autonomous was a critical element of last year's game, and I don't see a reason for why its importance should change this year. Therefore, select a person to do the programming.

Most of all, FIRST provides the oppertunity and environment for students to learn and excel. This should be extended to programming (and not limited by crappy hardware).

That's my $0.02 PLN

*S*K*I*B*A*

Rickertsen2

12-09-2003, 23:25

That would be great. there really really isn't even a need for a rtos if they stick with the current approach of 2 processors. (a user configurable and a hard coded one). But then again, from a hardware standpiont, an rtos would be more economical because it involves less components. I really have the feeling though, that all we will see is like a change to a jstamp, BasicX or something else like that.

-------------------------------------------------------------------
pretend this is the start of a new post.

Originally posted by 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!]
Thats why they offload the PWM and other duties such as enable/disable to another processor, so your code is runnign in a "sandbox". Also i found the lack of interrupts to be a limitation rather that a good thing. As far a setting up and writing to registers, FIRST could provide example code an libraries to do all the grunt work for the unexperienced teams.

Adam Y.

13-09-2003, 15:26

and keep in mind, though not everyone knows C, NOBODY knows PBASIC
Actually PBASIC is easy enough to learn on your own and that it is fairly easy enough to understand without much programming background.

Sachiel7

13-09-2003, 22:53

Ok, a few more thoughts here...
First off, to all the teams complaining that the Basic stamp stinks, isn't fast enough, doesn't give you a huge range of options, then let me say this: duh.
Do you honestly expect FIRST to supply teams with a fast system with plenty of memory and a typical programming language?
No! It is part of the FIRST challenge that you work with things that don't always do exactly what you want, when you want them to. When you get a job working as an engineer, do you think that every project you work on will have no problems, and be performed in an ideal environment? That you will have the latest, biggest, and baddest gizmos at your disposal???
Tell me if you find such a career, because I certainly haven't found one this way yet.
FIRST will supply a slower processor with limited memory and a language that is not-too-typical as a challenge. You have to learn the hardware, the language, and how to work with it. You should design your robot to function well with it, not rely on FIRST to give you the best.
(Also, a note to Wildstang, you complain about the speed of the processor, yet even with a highly significant delay, you still managed to take Nats. Think about that.)
Also, note that (as I stated before) IFI was created for FIRST. And they more than likely aren't going to change their entire control system for a new processor and memory. It is known that FIRST will include auto mode for at least 2 more years. IFI reps around the regionals have confirmed this several times. Why, when they just developed a system to function autonomously, with the multi-slot programming, would they just scrap all that?
It is my belief that IFI will stick to their control system for at least 2-3 more years before even considering a change.
When I previously posted about C, I meant that C and Basic are the main two different choices of languages out there. Since the system is currently basic-based, it would be asking alot to shift to C. That would likely require the change of processors for more compatability, and as I just said, I doubt that will happen.
One clue we may receive will lie within the eduBot, if we receive them this year, and I believe from all the positive feedback that we probably will receive them again.
If FIRST is going to switch languages/processors, then they will perform this switch on the eduBot. Note that the eduBot documents on IFI's site have been updated since competition, and yes, they still use the same control system as before.

dez250

14-09-2003, 00:04

i am not going to go out on a screaming and yelling tangent here, and i will make this short so everyone will read this.

IFI was not created with FIRST, or in any way completely for FIRST. They were a control system that took over when the Motorola controllers were discontinued. IFI was around before they were involved with FIRST, and if you have taken a look much at their site you would might figure that out. Also FIRST has just helped them as a company succeed, and grow more. I would suggest some of you to take a look at what you type here and what you say, as this thread may be the rumor mill, but it still reflects upon your team and yourself what you say, and this board will leave lasting impressions on many if not all of us!

~Mike

FotoPlasma

14-09-2003, 00:15

Originally posted by dez250
. . . IFI was not created with FIRST, or in any way completely for FIRST. They were a control system that took over when the Motorola controllers were discontinued. IFI was around before they were involved with FIRST, and if you have taken a look much at their site you would might figure that out. . . .

~Mike

I seem to recall that, during the awards ceremony (which ran concurrently with the final matches) at Championships, in Houston, 2003, Woodie Flowers (possibly someone else) specifically stated that Innovation First was formed by professionals who were involved in FIRST, at one point, and decided to split off, and work mainly on providing FIRST with control system equipment.

If I'm wrong, please correct me, as soon as possible.

Ricky Q.

14-09-2003, 00:32

Once again Jim, you are correcto, as soon as I saw this post I pulled up the video of the Founder's Award off SOAP's website, http://www.soap108.com/2003/movies/cmp/ , and watched it, and low and behold its Dean Kamen saying

This company started as a couple of guys on a team in the second year of this competition, and one day they decided it was better to do FIRST everyday than just once in a while, so they quit their jobs and decided to start helping us. They started helping us build better motor controls.....their new company grew as we grew, they started building complete systems, to run robots, fields, power, and then they decided they'd help us with EDU robots...

And so on, so IFI did start out as some guys on a FIRST team.

Mike Soukup

14-09-2003, 09:55

Originally posted by dez250
IFI was not created with FIRST, or in any way completely for FIRST. They were a control system that took over when the Motorola controllers were discontinued. IFI was around before they were involved with FIRST, and if you have taken a look much at their site you would might figure that out. Also FIRST has just helped them as a company succeed, and grow more. I would suggest some of you to take a look at what you type here and what you say, as this thread may be the rumor mill, but it still reflects upon your team and yourself what you say, and this board will leave lasting impressions on many if not all of us!
You're right, what you type here reflects on you & your team, so enough with the know-it-all, condescending attitude. Even if you were right about the origins of IFI (and you aren't, it was founded by some engineers from FIRST teams as Jim & Ricky pointed out), don't assume that others haven't looked at their website or done some research into the origins of IFI.

Originally posted by Sachiel7
(Also, a note to Wildstang, you complain about the speed of the processor, yet even with a highly significant delay, you still managed to take Nats. Think about that.)
Us complaining about the speed of the processor & us winning nats are really independent. We were surprised that we got as much mileage out of the control system as we did and we enjoyed the challenge. We were pushing the limits of the current controller. We were dangerously close to the upper bound on program loop length, a few hundred or so more lines of code (I didn't actually calculate how close we were) and we wouldn't have executed our loop fast enough and the RC would have reset. Sure we could have offloaded more processing to another off board controller, but we had electrostatic problems with our existing processor & didn't need more problems. Besides, it's almost unrealistic to require teams without mentors with CompE & CS backgrounds to use an off board processor if they want to do anything exciting with autonomous mode. We've already heard some grumbling from teams who think it's unfair to use an off board processor just because their teams don't have experienced mentors. If FIRST wants a majority of teams to progress beyond dead reckoning in autonomous mode they have to give us a processor with more power. Many teams in 2003 could have come up with awesome autonomous programs, but they were limited by the speed & memory constraints of the current controller so they stuck with dead or rotation counting. And if FIRST wants the more experienced teams to continue to push the envelope of what's possible in autonomous mode they'd better give us a controller that's capable of accomplishing more.

Originally posted by Sachiel7
Why, when they just developed a system to function autonomously, with the multi-slot programming, would they just scrap all that?
This isn't true. The 2003 controller was pretty much the same as all previous controllers. The old ones had multi-slot programming, we actually used 4 slots in 2002 (and 6 in 2003). And when we loaded our 2003 code onto previous year's RCs - I believe we used the 2001 controller on our prototype bot - we didn't have any problems, even in autonomous mode.

Mike

Doug Leppard

14-09-2003, 16:06

This was my FIRST year with FIRST. But I have been doing autonomous computers as a hobby for years.

The FIRST controller was in adequate not just because it was slow and had no memory to speak of, but it couldn't process interrupts, or look at an IO port more than once a cycle which means you did not have direct connection to the ports. It was ok if it was just an remote controller under radio command. But if you wanted to do auto mode a new controller is needed.

We did a modified external computer to do simple wheel encoders, which gave us better control of the robot in autonomous mode.

The kids I worked with had no problem understanding the concepts and implementing them.

What I understand is that FIRST is coming out with a controller soon and it will be radical change from previous years. The only way to do auto mode well is that you need a different controller. So I do hope that the controller will be released soon so we can train our kids now.

dez250

14-09-2003, 16:13

i was not trying to sound like a know-it-all... i was trying to convey a point to you all... your all running wild with things you may say and things you may here, you all are just going around saying what you may like to say, and what i did was try to show a point to you all... The last post i said in this thread was to see how quick some of you may jump at someone else's throat, and to try and show you that maybe for one time you should step back, take a rest and read all of what some others have to say before you put your 2 cents in. i see mike read through my whole post, and the start of it all with IFI was a b/s to see how many of you would just stop reading in the middle. Mike from 111 read through and what he pointed out is what i wish everyone could have seen, and not the inaccurate points of my post. Mike, the Student he is to FIRST, and the mentor he is to Wildstang, read through and showed that what you post on here comes to bight you back, and reflects upon your team and/or any organizations you may be involved with. This may be the rumor mill, but there is still a genuine state of respect in here, please read what you post, before you say it. For sometime or another you will meet someone from here at a competition or in real everyday life and see that this is more then computer to computer, but face to face.

~Dez

FotoPlasma

14-09-2003, 16:22

Originally posted by dez250
....

~Dez

Uh. I didn't jump down your throat. I corrected a technical inaccuracy. If you have any kind of valid complaint which you want to talk about, IM me.

<edit>
Heh. By the way, nice little disclaimer in your sig.
</edit>

Ian W.

14-09-2003, 16:43

Originally posted by dez250
i am not going to go out on a screaming and yelling tangent here, and i will make this short so everyone will read this.

Originally posted by dez250
....

~Dez

That's too long, I don't want to read it...

To be completely serious though, You can't expect to post something that has obviously incorrect info here and be surprised when everyone tries to "jump down your throat", if that's what you want to call it.

Just let this drop, because this is the stupidest thing I've seen in a while. These forums have many people, like Jim and Ricky who will always correct you, just because that's what they do. I like when the correct me, because it's either because I was stupid and didn't look it up, or I learned something new. If you don't like that people are correcting you, either look stuff up so everything posted is true, don't post fake information, or just leave. No one is making you stay here, and you're obviously sad because people are "jumping down your throat", but I can't help you, and I'm not sure that anyone else can.

Now, back on topic, about those controllers for next year. Anyone know when we're being told what they look like or what language they'll run?

<EDIT>
Typo.
</EDIT>

Sachiel7

14-09-2003, 16:47

All I'm saying is this:

-The division of IFI that produces the First components is heavily involved with FIRST.

-I agree that we need a system upgrade for more auto-heavy tasks. But my point was that it is part of the Challenge to use what is given to you, and if your complaining that its not good enough, you're not rising to the challenge.

-IFI has confirmed an entirely new control system for 2004. THIS IS NOT A RUMOR. I and at least 4 local teams have contacted IFI directly and each time they have confirmed that we are receiving an entirely new system next year. My prediction? I'm guessing they're going to use a BasicX. They'll probably stick with a BASIC based system, or something simple because every single (predicted 1000) team will have less than 2 months to learn this new language. Many of you big teams out there say "scoff, we have 20 programmers, and at least one of them knows C, or Java, or something or other" and you don't take into consideration that there could be well over 500 other teams out there that have no clue how to code in C or Java and would have a big issue on their hands with this type of shift.
I'm also curious as to whether or not IFI will change what type of PWM/Relay we use. I'm hoping that the Max amperage will be increased again, and that we may :) receive an even beefier drive motor than the CIM next year. Possibly a larger battery. I don't know, but I just emailed IFI asking what they could tell me, if anything, about the new system. FIRST claimed that information would be posted about this a while back, but I haven't seen a change yet.
This also raises quite a large bump in our workshop schedule. A major change in the system (electronics included) would ruin the fact that we have been planning our control workshops to take place only weeks away from now.

TechnocratiK

14-09-2003, 18:28

The RCs we're using could definitely use improvement One of the biggest faults of these microcontrollers is their inability to properly calculate with negative numbers. Sure, floating-point values would be a nice frill, but when working with a gyro, it'd be nice for the value of 1 / -1 not to equal 0.
Secondly, a new programming language would definitely be nice. Personally, I favour C++, mainly because it provides a good balance between complexity and efficiency. Nevertheless, I'd be tolerant of practically any language, as long as it allowed for user-defined functions.
Finally, more variables is a must. Robot controller programs aren't that big if you use some tricks, but being limited to 26 unsigned variables is torture.
As for the OIs, I really don't forsee FIRST using a Playstation controller plug, mainly because of the limitations of the device. Sure, digital inputs all around would be nice, but PSX controllers aren't the solution, not when you need a 3 way switch or the likes.

Rickertsen2

14-09-2003, 21:00

[i]Why, when they just developed a system to function autonomously, with the multi-slot programming, would they just scrap all that?
[/B]

IFI didn't actually develope the multi-slot thing in 2003 or ever. That was a result of Basic Stamp software updates, which have nothing to do with IFI. As far as auto mode goes, all they did was make a minor update to the firmware on the RCs, and some minor hardware and firmware changes to the field controllers.

Dave Flowerday

14-09-2003, 23:27

Originally posted by Sachiel7
(Also, a note to Wildstang, you complain about the speed of the processor, yet even with a highly significant delay, you still managed to take Nats. Think about that.)
I know Mike already responded to this point, but I want to emphasize something: what we did with our robot was NOT done entirely with the built-in processor. It wouldn't have been possible. We had to add our own external microprocessor to do it. Think about that.

Honestly, a better processor will help out other teams much more than it will help us. Most of our team's mentors are software/computer engineers. That makes us very well equipped to deal with limited computing resources of the current system - like being able to add our own external processor this year. For a lot of teams, that's not a realistic option, which means those teams will gain much more freedom with a new processor than we will.

Matt Leese

15-09-2003, 13:39

Originally posted by TechnocratiK
The RCs we're using could definitely use improvement One of the biggest faults of these microcontrollers is their inability to properly calculate with negative numbers. Sure, floating-point values would be a nice frill, but when working with a gyro, it'd be nice for the value of 1 / -1 not to equal 0.
The current Basic Stamp based microcontroller fully supports signed arithmetic (well, at least for addition subtraction; I believe it also works for multiplication and division). Two's-compliment numbers work perfectly (the real question would be why they wouldn't). However, the only thing that doesn't support negative numbers are the input and output devices. So this is probably much more a problem of the additional hardware than the Basic Stamp directly.

The real stupidity with the Basic Stamp math is its lack of order-of-operations.

Matt

Adam Y.

15-09-2003, 19:40

The real stupidity with the Basic Stamp math is its lack of order-of-operations.
Actually I think most processors handle math that way from left to right.

Sachiel7

15-09-2003, 20:23

Ladies and Gentleman, I have an announcement to make!
Upon emailing IFI asking for some information on the new control system, I received this message in response.

I think it should answer several questions:

----- Original Message -----
From: Tom Watson
To: sachiel7@comcast.net
Sent: Monday, September 15, 2003 4:22 PM
Subject: Re: New System

Sachiel7(I changed my name),

We will have updates on our website beginning on 01 October. Until then we can not give out any details.

Innovation First

So, We'll know in 16 days the specs of the new system.
I think I'll make a countdown timer for it.

Also, I have received word from a few sources that claim that the new language will be C based, and from word coming from other people, the pointers are highly suggesting this. I'm just glad I got C under my belt this summer :D .
A note to wildstang - I wasn't trying to be mean or anything I just wanted to note that even though the system didn't live up to your expectations, it got you the national trophy, with some help. Plus, I was a bit confused as to why you were using trig on a processor like this (???) From the matches I saw your bot had a skid/crab drive with the 2 "flaps" and a pretty good solid auto. What components did you have that required that level of calculation? Just curious. Also, yes my main source for claiming that IFI was made for FIRST was the remarks at the Awards Ceremony that Dean/Woody made. I saw it live, and I remembered reading something about that somewhere.
Anywho, I'm looking forward to this new system. Hopefully it will be a bit easier to use. I just through though, all the creations made for the STAMP, like the load of extra tools teams have developed, is all going down the drain.
My main suspicion that first is making the jump also is with the predicted 1500 teams, which is the largest jump to date. Could this also mean the field size/shape might finally be changed?
I guess we'll find out.

Rickertsen2

15-09-2003, 20:27

YES!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Fianlly!!!!!!!! I really can't wait. Its like christmas or something.

Sachiel7

15-09-2003, 20:32

Christmas for some...
The Apocalypse for Others.
(Not us :D )

Matt Leese

15-09-2003, 22:01

Originally posted by Adam Y.
Actually I think most processors handle math that way from left to right.
Most processors only do one operation at a time. Given that the Basic Stamp is programmed in PBasic, this means that you program it such that it does multiple operations at once. Because of this, it can't do order of operations. Most programming languages will execute things in the correct order. The Basic Stamp will not.

Matt

Ian W.

15-09-2003, 22:52

Originally posted by Rickertsen2
YES!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Fianlly!!!!!!!! I really can't wait. Its like christmas or something.

What about chanukah? Or do I have to get Adam Sandler in here to make me feel happy? :p

Rickertsen2

16-09-2003, 10:24

lol u know what i mean. No hard feelings.

Dave Scheck

16-09-2003, 10:41

Originally posted by Sachiel7
A note to wildstang -Plus, I was a bit confused as to why you were using trig on a processor like this (???) From the matches I saw your bot had a skid/crab drive with the 2 "flaps" and a pretty good solid auto. What components did you have that required that level of calculation? Just curious.

Our autonomous system, StangPS, required the use of trig. We used the offboard processor to calculate our current position on the field at all times. The communication between the RC and the processor was at a minimum due to the lag we experienced. Every loop we passed the x,y, and angle to the field (theta) across. The RC then used that information along with the point on the field it knew it wanted to get to in order to calculate the direction to drive. That's where the trig comes in. Take a look at the presentation that we put together at http://www2.wildstang.org/2003/video/StangPS

As Dave and Mike have mentioned, we really pushed the stamp to its limits. By upgrading the processor, other teams may have the opportunity to attempt something similar completely within the RC.

Mike Soukup

16-09-2003, 10:50

Originally posted by Sachiel7
A note to wildstang - I wasn't trying to be mean or anything I just wanted to note that even though the system didn't live up to your expectations, it got you the national trophy, with some help. Plus, I was a bit confused as to why you were using trig on a processor like this (???) From the matches I saw your bot had a skid/crab drive with the 2 "flaps" and a pretty good solid auto. What components did you have that required that level of calculation?
It's quite alright, your original post probably came across the wrong way. The problem isn't that the controller didn't live up to our expectations - we've been dealing with it for a few years so we knew what to expect - the problem is that FIRST is asking us to do more with it than ever before. The controller came out when the most complex programs teams were writing were simple feedback loops for controlling arms & crab wheels, now teams are asked to write programs that drive the entire robot without operator control. Fortunately FIRST & IFI realized that in order for the competition to progress beyond simple autonomous programs, they need to give us a better controller.

We used trig functions (actually an arctan lookup table) to find the angle that our robot needed to travel in order to reach its destination. We knew the robot's coordinates (got that from the off board processor) & the target coordinates so we simply took ((delta y) / (delta x)) and used our arctan subroutine to get the angle of travel relative to the field. Then we had to take into account our robot's angle relative to the field and get the angle to point the crabs, but that was just a subtraction. After that we had to adjust one side of our crab wheels in order to correct for any skew in the robot's orientation (what we called theta correction). Then that data was passed to our normal crab control subroutines to actually turn the wheels to the proper angle. I almost forgot that we also passed data to the wing control subroutines so we could control the wings in autonomous mode. All of that was done each loop in autonomous mode.

Thanks for the info about the status of the new controller. You may want to edit out your email address from the post if you don't want it public.

And on a side note, I sure hope IFI builds a lot of extra controllers since it's common for teams to build a second robot for use after the build deadline. Either that or FIRST lets us keep our controller instead of shipping it with the robot.

Mike

Sachiel7

16-09-2003, 12:03

Hey thanks for letting me know more about what you did last year.
I tried to make something like wilddraw this past year but ran out of Time. I'm working on a newer one now, and I'm having it generate rough code in C, in case that is the language we use.
My drive system I designed will function as Crab\Skid\Car and a few others, so we may agree on using it if there aren't any obvious issue with it being used in the game after it is revealed. That would really cut down out crunch.
My email is available to anyone who wants it on chiefdelphi, so feel free to give me a ring.

Wetzel

26-09-2003, 23:19

From a FIRST email blast.
"The rumors are true; a new control system is coming. The new RC has a user programmable Microchip PIC" controller operating at 10 MIPS, gives direct access to I/O, has interrupts, and is programmable in C. Please do not contact Innovation First requesting information as more details will be available at www.InnovationFirst.com in the next few weeks when the product ships.

Last year all teams received the FIRST EDUrobotics kit to assist in preparation for the FIRST Robotics Competition season. Based on the overwhelming response and positive feedback from teams for survey results, FIRST will again offer the FIRST EDUrobotics Kit to the incoming rookie and returning teams that did not compete last year. After these teams register for an event, and upon receipt of a $500 deposit at FIRST, they will receive the kit that will include the new Innovation First Control System. All deposits are applied toward the $5,000 registration fee; however, once product is shipped the deposit is non-refundable. In order to allow everyone to build familiarity with the system, all teams that received the FIRST EDUrobotics kit last year will receive the new control system when they register. On-line instructional materials will be available on our website at www.usfirst.org. Both items should start shipping approximately October 15, so register early.

In order to provide the new robot controllers and other new parts in the kit this coming year and stay within budget constraints, it is necessary for FIRST to make some changes to the kit of parts. Battery chargers, joysticks and compressors will be supplied to teams in their first and second year. Veteran teams should have two sets of these parts and can use them on their 2004 robot. We hope you find some of the new parts exciting and challenging."

Whos excited? :)

Wetzel

Mike Yan

30-09-2003, 22:49

It was stated the the new micro was a PIC operating at 10MIPS.
Does anyone know what the clock speed is?

PICs run at a quarter of whatever clock speed it gets, so I was just wondering.

FotoPlasma

30-09-2003, 23:22

Originally posted by Mike Yan
It was stated the the new micro was a PIC operating at 10MIPS.
Does anyone know what the clock speed is?

PICs run at a quarter of whatever clock speed it gets, so I was just wondering.
Mike, you just answered your own question. If Fcyc is Fosc/4, and Fcyc is 10M, Fosc is 40MHz.

Jaime648

08-10-2003, 16:46

Yeah, we just had a meeting last night and they told us that we have to get a new controller program. So we have to learn all new stuff. Which will be good because you get to learn different programs and stuff like that. Even though I'm not in the electronics i think it will work out just fine. :)

Dan 550

11-10-2003, 01:25

Ugh. I don't know how I'd handle a new controller...our programmers just tweaked their pBasic skills to what I'd call "good" this year, and now they're gonna throw this at me. Wow. Maybe it'll be good -- maybe they'll keep pBasic and expand the flash and RAM and maybe give some more inputs and outputs and some better feedback on the OI. Little flashy lights are not sufficient, and the dashboard port makes for a bunch of glorified flashy lights on a computer (which I think is a hassle and gets in the way). At least have bigger, brighter flashy lights! My one complaint is that the current RC doesn't handle non-player input sufficiently without miracle code. And it's hard to have miracle code with just two guys coding, who both actually have lives and don't live breathe and die pBasic during the build and test time.

-EDIT-

Okay, reading further, I see that there will indeed be a bigger, better RC/OI combo. Yippee. Now I gotta ramp up my programmers for C.

Dan 550

11-10-2003, 01:28

Originally posted by Wetzel
From a FIRST email blast.
"The rumors are true; a new control system is coming. The new RC has a user programmable Microchip PIC" controller operating at 10 MIPS, gives direct access to I/O, has interrupts, and is programmable in C. Please do not contact Innovation First requesting information as more details will be available at www.InnovationFirst.com in the next few weeks when the product ships.

Last year all teams received the FIRST EDUrobotics kit to assist in preparation for the FIRST Robotics Competition season. Based on the overwhelming response and positive feedback from teams for survey results, FIRST will again offer the FIRST EDUrobotics Kit to the incoming rookie and returning teams that did not compete last year. After these teams register for an event, and upon receipt of a $500 deposit at FIRST, they will receive the kit that will include the new Innovation First Control System. All deposits are applied toward the $5,000 registration fee; however, once product is shipped the deposit is non-refundable. In order to allow everyone to build familiarity with the system, all teams that received the FIRST EDUrobotics kit last year will receive the new control system when they register. On-line instructional materials will be available on our website at www.usfirst.org. Both items should start shipping approximately October 15, so register early.

In order to provide the new robot controllers and other new parts in the kit this coming year and stay within budget constraints, it is necessary for FIRST to make some changes to the kit of parts. Battery chargers, joysticks and compressors will be supplied to teams in their first and second year. Veteran teams should have two sets of these parts and can use them on their 2004 robot. We hope you find some of the new parts exciting and challenging."

Whos excited? :)

Wetzel

Ooh, fun. Gotta find those broken controllers, lost battery chargers, and worn out compressors. I'm excited now. :yikes: