Serious Controller Ideas

[archiver]

Posted by Joe Johnson, Engineer on team #47, Chief Delphi, from Pontiac Central High School and Delphi Automotive Systems.

Posted on 5/15/99 7:02 PM MST



Eric has hinted that a new controller for FIRST is in the works for 2000.

So...

Get your licks in now.

What do we want?

I will start us off with a few replies to this message.

Share your ideas too.

Joe J.

[archiver]

Posted by Joe Johnson, Engineer on team #47, Chief Delphi, from Pontiac Central High School and Delphi Automotive Systems.

Posted on 5/15/99 7:22 PM MST


In Reply to: Serious Controller Ideas posted by Joe Johnson on 5/15/99 7:02 PM MST:



I know that veterans will say this is a step backwards, but I beg to differ.

I envision a bunch of relay modules similiar to the Innovation FIRST Victors.

Power and motor leads would be exactly like the Victors.

I would suggest that a tri-color LED be used to indicate the state of the input signals (again, like what is done on the Victors).

Annother idea would be to have the fuses built right into the relay module (but let's make them circuit breakers instead, okay?)


The FWD/REV/OFF state would be controlled by either optically isolated digital IO or perhaps even using a PWM channel.

The Digital IO method would be simpler to implement (both inside the Relay Module and also on the RX board), but I sort of like the idea that all the motors would be controlled the same way (00 = REV, 254 = FWD, 127 = OFF)

Perhaps the clever folks at Innovation FIRST would make both types of inputs available.


My main reason for requesting the remote relay modules is that it would totally remove high current applications from the RX board.

In addition, high current relays could be used, allowing ALL motors to be run with relays rather than just the seat, window and Globe motors.

The reason I like this is that it would be a step in the right direction.

One of the trickier bits of the FIRST board to duplicate is that high current area. Getting the high current stuff in a package off the main board will get us that much closer to an 'off the shelf' controller.

Comments.

Joe J.

[archiver]

Posted by Thomas A. Frank, Engineer on team #121, The Islanders/Rhode Warrior, from Middletown (RI) High School and Naval Undersea Warfare Center.

Posted on 5/19/99 10:24 AM MST


In Reply to: remote the relays... posted by Joe Johnson on 5/15/99 7:22 PM MST:



Hello All;

I agree wholeheartedly! We need two boxes, a power distribution assembly which
contains all the circuit breakers, relays, and current shunts to monitor outputs, battery monitor,
and a separate control box with the microcontroller, the analog and digital inputs, PWM outputs,
interrupts, and a PCMCIA spread spectrum RF ethernet card.

Using the ethernet would allow bidriectional communications, which would be great for
troubleshooting, and real time display of status. Imagine having a display at the player
station that showed the state of say a switch which would let you know when you were against
a pole or in some other state as desired...

FIRST could also run a packet sniffer/capture program which would store the whole match,
and allow them to show, after the fact, whether there were any problems with their equipment. That
would ensure maximum fairness in the rematch area.

The RF SS EN setup would also do away with the need for the tether adapters, turning in RNet's, and
all the related inconvienience of the present system.

Tom Frank

[archiver]

Posted by Thomas A. Frank, Engineer on team #121, The Islanders/Rhode Warrior, from Middletown (RI) High School and Naval Undersea Warfare Center.

Posted on 5/19/99 10:25 AM MST


In Reply to: Re: remote the relays... posted by Thomas A. Frank on 5/19/99 10:24 AM MST:



Oh, and did I mention that PCMCIA RF ethernet cards are about 1/2 the cost of RNet's...

Tom Frank

[archiver]

Posted by Raul, Engineer on team #111, Wildstang, from Rolling Meadows & Wheeling HS and Motorola.

Posted on 5/19/99 12:04 PM MST


In Reply to: Re: remote the relays... posted by Thomas A. Frank on 5/19/99 10:24 AM MST:



: Hello All;

: I agree wholeheartedly! We need two boxes, a power distribution assembly which
: contains all the circuit breakers, relays, and current shunts to monitor outputs, battery monitor,
: and a separate control box with the microcontroller, the analog and digital inputs, PWM outputs,
: interrupts, and a PCMCIA spread spectrum RF ethernet card.

: Using the ethernet would allow bidriectional communications, which would be great for
: troubleshooting, and real time display of status. Imagine having a display at the player
: station that showed the state of say a switch which would let you know when you were against
: a pole or in some other state as desired...

: FIRST could also run a packet sniffer/capture program which would store the whole match,
: and allow them to show, after the fact, whether there were any problems with their equipment. That
: would ensure maximum fairness in the rematch area.

: The RF SS EN setup would also do away with the need for the tether adapters, turning in RNet's, and
: all the related inconvienience of the present system.

: Tom Frank

I also agree. These are great ideas!

Raul

[archiver]

Posted by Thomas A. Frank, Engineer on team #121, The Islanders/Rhode Warrior, from Middletown (RI) High School and Naval Undersea Warfare Center.

Posted on 5/20/99 10:08 AM MST


In Reply to: Re: remote the relays... posted by Thomas A. Frank on 5/19/99 10:24 AM MST:



Hello All;

Forget the PDA concept - Joe's idea of a relay module that connects just like
a VICTOR speed controller is MUCH better.

FIRST could put four of the SSC's in the control box and thus give us 32 outputs,
useable as either variable speed OR relay, in any combination, while getting all the
high power stuff away from the controll stuff (bet that would make Eric's life easier).

The PWM relay module would also be highly marketable, which would be good for InnovationFIRST.

Brainstorming can result in marvelous things.

Tom Frank

[archiver]

Posted by Joe Johnson, Engineer on team #47, Chief Delphi, from Pontiac Central High School and Delphi Automotive Systems.

Posted on 5/20/99 5:10 PM MST


In Reply to: Forget the PDA posted by Thomas A. Frank on 5/20/99 10:08 AM MST:



I will be very glad to forget the PDA concept as soon as you remind me what it is that I am forgetting ;-)

Serious, while I can hardly argue with anyone agreeing with me, I would still like to understand what is being said.

I have racked my brain for SECONDS now and I can come up with nothing that PDA could stand for.

Plesas help me out.

Joe J.

[archiver]

Posted by Dan, Student on team #10, BSM, from Benilde-St. Margaret's and Banner Engineering.

Posted on 5/20/99 6:46 PM MST


In Reply to: PDA? posted by Joe Johnson on 5/20/99 5:10 PM MST:



PDA=Personal Digital Assistant (aka Palm Pilot) and if you're in high school, PDA=Public Display of Affection. :-Dan

: I will be very glad to forget the PDA concept as soon as you remind me what it is that I am forgetting ;-)

: Serious, while I can hardly argue with anyone agreeing with me, I would still like to understand what is being said.

: I have racked my brain for SECONDS now and I can come up with nothing that PDA could stand for.

: Plesas help me out.

: Joe J.

[archiver]

Posted by Jerry Eckert, Engineer on team #140 from Tyngsboro, MA High School and New England Prototype/Brooks Automation.

Posted on 5/21/99 10:57 AM MST


In Reply to: Re: PDA? posted by Dan on 5/20/99 6:46 PM MST:



: PDA=Personal Digital Assistant (aka Palm Pilot) and if you're in high school, PDA=Public Display of Affection. :-Dan

Or, if you're an engineer, Power Distribution Assembly. :)

- Jerry

[archiver]

Posted by Thomas A. Frank, Engineer on team #121, The Islanders/Rhode Warrior, from Middletown (RI) High School and Naval Undersea Warfare Center.

Posted on 5/22/99 10:32 AM MST


In Reply to: PDA? posted by Joe Johnson on 5/20/99 5:10 PM MST:



Joe;

You're not reading all the postings...go up a few levels.

Jerry got it right down below.

Tom

[archiver]

Posted by Joe Johnson, Engineer on team #47, Chief Delphi, from Pontiac Central High School and Delphi Automotive Systems.

Posted on 5/22/99 11:28 AM MST


In Reply to: Re: PDA? posted by Thomas A. Frank on 5/22/99 10:32 AM MST:



Tom,

I read your message 10 times or more looking for any mention of PDA's.

The first line just did not register:

'...We need two boxes, a power distribution assembly which...'

I knew what you were talking about so I guess I didn't bother to read the words carefully.

My bad...

Joe J.

[archiver]

Posted by Joe Johnson, Engineer on team #47, Chief Delphi, from Pontiac Central High School and Delphi Automotive Systems.

Posted on 5/15/99 7:34 PM MST


In Reply to: Serious Controller Ideas posted by Joe Johnson on 5/15/99 7:02 PM MST:



Give us a microprocessor/language combination that has Realtime Multi-Tasking capability.

A real time clock goes without saying.

This would enable a lot of complex stuff to be written in relatively simple modules.

For instance, a 'get latest radio data' task, a 'wheel speed control' task, an 'arm control' task, a 'compute wheel speed' task, a 'monitor power consumption' task, etc.

I suppose the language should be 'C' but I am not fussy.


Failing this, I suppose I will settle for just a powerful microprocessor with access to the interrupt service rountines (with both internal and external interrupt triggers).

Comments?

Joe J.

[archiver]

Posted by Chris, Coach on team #308, Walled Lake Monster, from Walled Lake Schools and TRW Automotive Electronics.

Posted on 5/20/99 6:10 AM MST


In Reply to: Realtime Multi-Tasking C posted by Joe Johnson on 5/15/99 7:34 PM MST:



: Give us a microprocessor/language combination that has Realtime Multi-Tasking capability.

: A real time clock goes without saying.

: This would enable a lot of complex stuff to be written in relatively simple modules.

: For instance, a 'get latest radio data' task, a 'wheel speed control' task, an 'arm control' task, a 'compute wheel speed' task, a 'monitor power consumption' task, etc.

: I suppose the language should be 'C' but I am not fussy.

:
: Failing this, I suppose I will settle for just a powerful microprocessor with access to the interrupt service rountines (with both internal and external interrupt triggers).

: Comments?

: Joe J.

[archiver]

Posted by Joe Johnson, Engineer on team #47, Chief Delphi, from Pontiac Central High School and Delphi Automotive Systems.

Posted on 5/15/99 7:37 PM MST


In Reply to: Serious Controller Ideas posted by Joe Johnson on 5/15/99 7:02 PM MST:



Whatever the solution that FIRST comes up with, the entire system should be available for purchase.

I suggest that with radios and everything, FIRST should make the whole thing available for UNDER $3,000. Less is better of course.

Joe J.

[archiver]

Posted by Dodd Stacy, Engineer on team #95, Lebanon Robotics Team, from Lebanon High School and CRREL/CREARE.

Posted on 5/17/99 7:25 AM MST


In Reply to: Serious Controller Ideas posted by Joe Johnson on 5/15/99 7:02 PM MST:



: Eric has hinted that a new controller for FIRST is in the works for 2000.

Any chance FIRST might sell us the 99 controllers, if they're to be obsoleted? Lack of a controller is the straw that generally consigns the old bot to the bone yard, rather than letting him go to pasture as a sponsor demo unit and sparring partner for the new bot.

Dodd

[archiver]

Posted by Joe Johnson, Engineer on team #47, Chief Delphi, from Pontiac Central High School and Delphi Automotive Systems.

Posted on 5/17/99 7:34 PM MST


In Reply to: 99 Controllers? posted by Dodd Stacy on 5/17/99 7:25 AM MST:



Great idea!

If they are destined for the scrap heap, I propose we all start a fund to pay for professional dumpster divers to keep an eye on the trash outback of 200 Bedford Street, Manchester, NH ;-)

Joe J.

[archiver]

Posted by Joe Johnson, Engineer on team #47, Chief Delphi, from Pontiac Central High School and Delphi Automotive Systems.

Posted on 5/20/99 5:25 PM MST


In Reply to: Serious Controller Ideas posted by Joe Johnson on 5/15/99 7:02 PM MST:



I have suggested this before, but it was a while ago so I will repeat myself.

FIRST should include a proto area and an approved set of components (e.g. any inductor

[archiver]

Posted by Thomas A. Frank, Engineer on team #121, The Islanders/Rhode Warrior, from Middletown (RI) High School and Naval Undersea Warfare Center.

Posted on 5/23/99 11:02 AM MST


In Reply to: add a custom curcuit area posted by Joe Johnson on 5/20/99 5:25 PM MST:



Another great idea, Joe!

But there might have to be just a few more rules...like only DIP package IC's allowed, or
some such restriction, to keep people from buying things at the die level and making up
something really serious in the available space.

I know we'd try it! (assuming the microelectronics lab would volunteer it's time...)

Tom Frank

[archiver]

Posted by Joe Johnson, Engineer on team #47, Chief Delphi, from Pontiac Central High School and Delphi Automotive Systems.

Posted on 5/20/99 5:42 PM MST


In Reply to: Serious Controller Ideas posted by Joe Johnson on 5/15/99 7:02 PM MST:



This year we put in a 'learn' mode in our RX code that allowed us to train the controller to adjust the joystick's nuetral and max and min outputs (The raw data was scaled so that an untouched joystick always read 128, a full forward joystick always read 254, a full back joystick always read 0, etc.).

It wasn't terribly complicated, but on the current controller, it took up resources that were already pretty scarce.

What do folks think of a set of switches on the TX box (perhaps recessed in holes and only pressable with a small screwdriver) that would allow the TX box to learn these values for a each joystick and then do the conversion prior to sending the data?

While it IS exciting to adjust those joystick trims as 1000's watch from the stands, I think I could manage to live a fulfilled life without doing it again ;-)

Any thoughts?

Joe J.

[archiver]

Posted by Tom Vanderslice, Student on team #275, ORHS/AST/Hitachi, from Academy of Science and Technology and Hitachi.

Posted on 5/20/99 6:29 PM MST


In Reply to: learn mode for joystick inputs posted by Joe Johnson on 5/20/99 5:42 PM MST:



Ain't it great to watch that light come on and your robot jump all over the place...great feeling... ;)


Tom

[archiver]

Posted by Joe Johnson, Engineer on team #47, Chief Delphi, from Pontiac Central High School and Delphi Automotive Systems.

Posted on 5/20/99 6:58 PM MST


In Reply to: Serious Controller Ideas posted by Joe Johnson on 5/15/99 7:02 PM MST:



Regardless of what controller changes are made, I propose that FIRST publish a generic PID control mudule (PID = Proportional Integral Derivative).

The current controller is not powerful enough (in my opinion) or fast enough to implement a robust PID control routine.

I propose that the module would have do all the hard work and allow the users (like us) to set the gains for the propotional, integral and derivative feedback loops.

There are well know methods for determining the gains for PID control (I will pull together a PID controller primer if someone will develop the code).

If teams have well behaved feedback routines available, I think that many robot arms would be MUCH better behaved.

Am I the only one out here who can't stand to see these herky-jerky robot arms out there?

Give me robust feedback.

Joe J.

[archiver]

Posted by Joe Johnson, Engineer on team #47, Chief Delphi, from Pontiac Central High School and Delphi Automotive Systems.

Posted on 5/20/99 7:05 PM MST


In Reply to: Serious Controller Ideas posted by Joe Johnson on 5/15/99 7:02 PM MST:



More feedback inputs on the RX side would be good too.

I think that more teams would have used the Yaw Rate Sensor if there were more analog inputs available (assuming also that the microprocessor is powerful enough to handle more inputs of course)

If it were up to me, I would have feedback on almost every motor on our robot.

16 or 32 analog inputs should be enough to keep us for a few years.

Joe J.

[archiver]

Posted by Mike, Student on team #175, Buzz, from Enrico Fermi High School and UTC - Hamilton Standard Space Systems.

Posted on 5/21/99 4:20 PM MST


In Reply to: Serious Controller Ideas posted by Joe Johnson on 5/15/99 7:02 PM MST:



I would definitely like to have processing power on
both the receiver and the transmitter side. This will coincide
with the other great idea of RF Ethernet because we will now
have an up-link from the robot. This will help drivers 'see'
things from the robot's perspective.

I would like to propose an idea from a technical design
aspect. I think there should be two computers on the receiver
side. The first would be the one we're all talking about: more
memory, lightning fast processor. This computer would be
responsible for the RF Ethernet, all inputs, and the processing
of data. This computer would send it's output to a modified version
of the current receiver, and then out to the motors. This setup
would save FIRST some cash (which gets us a better system) but
would also allow us to use something that we have come accustomed
to. Anybody have any suggestions or comments?

[archiver]

Posted by Joe Johnson, Engineer on team #47, Chief Delphi, from Pontiac Central High School and Delphi Automotive Systems.

Posted on 5/21/99 6:16 PM MST


In Reply to: Re: Serious Controller Ideas posted by Mike on 5/21/99 4:20 PM MST:



I think that two user programmable CPU's on the RX side sounds okay, but I object to keeping the current RX box as one of them.

The basic loop time is too slow to be useful in many situations.

As long as we are going to bite the bullet and go to a new controller, I say do it right, don't compromise performance to get one or two more years out of the current (very good, but definitely improvable) controllers.

As to saving money, I don't think that much would really be saved. Remember that we are on a 40% growth curve. This means that over 100 new controllers are required even if we change nothing!

Just my two cents.

Joe J.

[archiver]

Posted by Rick Berube, Engineer on team #121, Rhode Warriors, from Middletown H.S..

Posted on 5/22/99 10:56 PM MST


In Reply to: Serious Controller Ideas posted by Joe Johnson on 5/15/99 7:02 PM MST:




Joe,

I like the modular approach and the isolation of the power electronics from the processor. Consider the Motorola 683xx series of controllers for the task of receiver controller. I think it has more than enough 'bang-for-the-buck'. More specifically, check out the 68PM302 and 68EN302/MC68160 pair. They provide ethernet/PCMCIA support? How about high-level language, operating system and BDM debugging support?
The 683xx series is 68K based and is surrounded by all sorts of peripheral goodies like interrupts, A/Ds and high speed timers, etc. Regardless of the micro selected, if you mount it on a mezzanine card, and add your 'black-box' design for relays and switches, you have the makings of an upgradable controller box. Good for many years to come. You'll need more receiver horsepower to utilize the LAN idea anyway.

Ok. NOW FOR A REALITY CHECK. with a more powerful contoller and functional system comes a price. And I'm not talking about monetary value either! We must ensure no one gets left in the dust trying to make use of this wonderful new controller. We (read the FIRST software community) need to get together and establish a development 'environment'.
The beauty of the Basic Stamp was its easy of use and readily available support. Will the formation of a 'GNU-like' consortium be needed, or will it this all fall upon FIRST shoulders? how steep will the learning curve be to program this new controller? remember you only have a few weeks to master the beast and get it to jump thru hoops.

To simplify the task of programming the beast with all these new features, we'll need consider (amoung others):
1)publishing a library of software accesible to all (and complete with source code)
2)writting a FIRST executive (a mircokernel by any other name). We need to ensure user programs cannot execute outside the saftey boundries established by FIRST (I'm to old to chace runaway robots;). the concept of priveledged(FIRST)/user(your team)tasks works well here.
3)writting a new default program is needed to provide basic functionality, and a place to start for more advanced programs. if my team doesn't have a programmer, this is my only recourse.
4)let's not forget the need for a new transmitter and some PC software (if we're going to use this new system to its fullest potential we'll need the tools to do it). teams will need a place to start to make use of all these new features.
5)oh yeah. I almost forgot. Last but not least, we need a ton of documentation (luckily something we all love to do;) We'll have to develop an Application Programmers Interface document so everyone knows what is available and how to used it. How many man hours do you think something like would take?

Don't get me wrong, I too would like more controller features at my disposal. But be careful what you ask for, you may just get it.
There is a great deal of work here. A significant hardware & software undertaking for sure. It would surly be a challenge to come up with a design which adds all this functionaly while minimizing the complexity which normally accompanies such systems.

I bet Eric is having trouble trying to estimate how all this will impact his customer support hours (not!).

[archiver]

Posted by Tom Vanderslice, Student on team #275, ORHS/AST/Hitachi, from Academy of Science and Technology and Hitachi.

Posted on 5/22/99 11:48 PM MST


In Reply to: Re: Serious Controller Ideas posted by Rick Berube on 5/22/99 10:56 PM MST:



Maybe if they sent the new control system a little early (say before x-mas)
it would give everyone a chance to 'get to know' the new controller...
write some simple programs and hook up an old robot or some old motors
or little motors you just have lying around (ok...we all know we do)...
This would be fairly simple and would allow the 'learning curve' to be not
so steep by giving us a few weeks...maybe a month if they sent them early
enough...

Just a thought...

Tom
Team 275

[archiver]

Posted by Rick Berube, Engineer on team #121, Rhode Warriors, from Middletown H.S..

Posted on 5/23/99 10:16 AM MST


In Reply to: Maybe a Partial Solution to the Learning Curve posted by Tom Vanderslice on 5/22/99 11:48 PM MST:



: Maybe if they sent the new control system a little early (say before x-mas)
: it would give everyone a chance to 'get to know' the new controller...

Certain an idea worth entertaining regardless of what the new controller looks like. Although I haven't been to a kick-off mtg yet in NH, I believe the manufactures of the animation software provide a seminar to those who wish to attend. This same type of thing for the controller would certain help the un-initiated to get over the learning curve. However, realize this is just a start. Aside from the controller hardware and software, there would also be the potential learning curve of real-time multi-tasking, operating system/kernel, development tools, etc.
Engineering will always be about tradeoffs. This new controller is no different. How fast does the micro have to be? what programming language will you make available for teams to program in? what type of development environment should be established? I'm not saying we can't strike a balance. I guess the point I'm trying to make, is that while all these suggestions are valid, there must be some thought put into the final product and the level of expertise required to program it (have mercy on the rookie teams).

Again, I'm not saying this can't be done with a well published API. Maybe it's done by starting with a well documented micro and OS, with networking and multi-tasking support built-in. Typically your talking about using the C programming language here however not Basic. But if the software is layer properly, and you can minimize the shear number learning curves to overcome, it becomes more feasible.

[archiver]

Posted by Joe Johnson.

Engineer on team #47, Chief Delphi, from Pontiac Central High School and Delphi Automotive Systems.

Posted on 5/24/99 6:55 PM MST


In Reply to: Re: Maybe a Partial Solution to the Learning Curve posted by Rick Berube on 5/23/99 10:16 AM MST:



To my mind, your comments are exactly why FIRST should go with a nearly off the shelf system.

3 years back, I tried to roll my own robot controller using a 68332 based New Micros Inc single board computer. It almost killed me...

The machine had TONS of CPU speed, what I needed was a standard library of useful functions. Before I gave up, I had the onboard TPU (Time Processing Unit) performing the PWM function in an automonous mode, much like the Serial Servo Controller (SSC) does now only much quicker to access (a single write to memory rather than a serial stream to the SSC). In the future, such partial solutions can be made available to all.

I think that it is possible for FIRST to use an off the shelf or nearly off the shelf single board CPU.

But, there will be problems to deal with:

1) Control of high current loads

This can be dealt with in a number of ways already discussed.

2) Watch dog curcuitry to cut off power in case of a lost radio signal or the end of a match

It is pretty standard to have watchdog curcuitry onboard single board computers, if first used a radio with the checksum and security stuff incorporated inside its internal CPU then it could also provide the watchdog signal(s) to the watchdog curcuit. I suppose that a bit of care would have to be taken to see to it that clever EE-types don't disable the watchdog (you have to watch those highly paid sneaky electrical folks ;-) but I think that this would not be too much of a problem. If it were we would have already seen some cheating because the current system is far from invulnerable (A snip here a cut trace there and your robot could continue to run regardless of what FIRST did to the TX signal). It is no more or less an honor system than whether or not a team's BOM actually matched the robot.

3) High learning curve.

For my money, the best way to beat this is for FIRST to decide to use an off the shelf controller NOW or ASAP and then tell the world where to get it.

I would like nothing more than to teach a CPU class or a C class or a digital curcuitry class next fall to the students on my team.

Winning animations are already being designed and built for next year. Why can't the winning control program already begin?

Also, I think that if we choose an off the shelf system, then we can all go to existing user groups for help. There are a lot of very clever people online, many of them give advice and consulting free if asked. This could be no different.

In addition to this, an off the shelf controller has existing documentation and support for its product. Once again, this puts us ahead of the game.

As to the difficulties of C, I agree, that C is a language for consenting adults, but with enough examples and a fall back default code, we can all get through this. After all, we don't tell teams that heat treatment of steel is tricky business best left to folks who know what they are doing. No, we allow heat treatment or not as teams see fit. This C thing could be just like that. Many teams may choose to use the default code with only minor changes. Others may be implementing Kalman filters and State Space control schemes -- let us all seek our own depth.

I think that the GNU model mentioned in a prior message is not far from how the FIRST online community would support a new commercially available computer. If we (ChiefDelphi.com) put up a forum on code issues, don't you think that we could all climb that learning curve faster than you can say, 'Realtime Multitasking C'?

4) Others I have not thought of...


I think that we can do this. I think that we SHOULD do this. Now is the time to do this.

Who will join me in finding an appropriate commercial solution? I think that if we find a good solution we can sell it to Eric and the gang back in NH.

Joe J.

[archiver]

Posted by Rick Berube.

Engineer on team #121, Rhode Warriors, from Middletown H.S..

Posted on 5/25/99 10:06 PM MST


In Reply to: Nearly off the shelf... posted by Joe Johnson on 5/24/99 6:55 PM MST:



Ok. Let's see if I can address these issues one at time. I have nothing against C. It's probably the best embedded high level language for mid to lower-level micros going. And its only one step away from C++. It has been around for ages (at least in computer years;) and is well supported by just about every development environment I can think of.

As far as the 'off-the-shelf' bullet is concerned, I heard a rumor that FIRST is having someone develop the controller for them. So perhaps you will get your wish for a COTS controller that can be purchsed. Regardless, we are talking about the need for some type of integrated development environment (IDE). I can see something like a Motorola micro which supports background debug mode (BDM). This is a great way to go. Its functional, register level access and cost effective (read CHEAP!). Mike isn't the only one on a budget. No emulators, or JTAG debuggers need apply, thank you.

I'll argue however, that if FIRST were to provided a system complex enough to require a battery of development tools, you'll see more complaints regarding this issue than those attacking the lack of power in the earlier models. I think a 'high-level, wiz-bang' system means embedding a microkernel/OS. This means someone must write one or purchase one. Last time I looked, vxWorks and Windows CE both came with a pretty good IDEs, but neither is cheap. Is someone going to strike a deal with Jerry or Bill? Are they on-board for this project?

Whatever the IDE provided, if the controller goes the route of a generic micro, one where the entire application programmer's interface (API) were a custom design, its has to be an open system. One with plenty of documentation. One where FIRST teams could contribute in a GNU-like fashion. But it has to have some straight forward tools to leverage or it'll never make it as a commercial product. There's a reason companies like Wind River and Microsoft are doing so well. Software at this level is hard to write and make bullet proof in short order. I think starting from scratch with a custom IDE and API would kill this project dead. I just don't think there's enough time to do it well unless you leverage off an existing COTS software, or 'Simplify' the design of teh controller itself.