Another idea for future competitions

[archiver]

Posted by Kris Verdeyen at 04/12/2001 11:42 AM EST


Engineer on team #118, Robonauts, from CCISD and NASA - Johnson Space Center and Friends.



One thing that I've noticed about FIRST is its emphasis on mechanical engineering and design to the extent of virtually eliminating any creative electrical and software designs. IMHO, FIRST needs to rectify this. Perhaps by allowing more purchase of electrical parts (by opening up the Digi-Key catalog similarly to the SPI arrangement), or by letting the robots compete autonomously for 15 seconds or so before the controllers turn on.

Now, before I get hate mail describing the autobalancing functions and wearable controls that we saw at nats, let me just say that I recognize the engineering and programming ability that went into them, but such innovations are still being unduly limited.

[archiver]

Posted by Patrick Dingle at 04/12/2001 12:19 PM EST


College Student on team #639, Red B^2, from Ithaca High School and Cornell University.


In Reply to: Another idea for future competitions
Posted by Kris Verdeyen on 04/12/2001 11:42 AM EST:



I would love to see room for more programming and electrical control of the robot. The Innovation FIRST systems are great -- but can they do better? Replace the BASIC stamp chip with a chip that lets us download precompiled code, perhaps? One of the most interesting things to me is when robots do have automated things, such as autobalance.

Probably too complicated and expensive, but I can imagine...

Patrick

: One thing that I've noticed about FIRST is its emphasis on mechanical engineering and design to the extent of virtually eliminating any creative electrical and software designs. IMHO, FIRST needs to rectify this. Perhaps by allowing more purchase of electrical parts (by opening up the Digi-Key catalog similarly to the SPI arrangement), or by letting the robots compete autonomously for 15 seconds or so before the controllers turn on.

: Now, before I get hate mail describing the autobalancing functions and wearable controls that we saw at nats, let me just say that I recognize the engineering and programming ability that went into them, but such innovations are still being unduly limited.

[archiver]

Posted by Matt Leese at 04/12/2001 2:40 PM EST


College Student on team #73, Tigerbolt, from Edison Technical HS and Alstom & Fiber Technologies & RIT.


In Reply to: Another idea for future competitions
Posted by Kris Verdeyen on 04/12/2001 11:42 AM EST:



The main reason that such components to the competition will probably not be added is the fact that to this day, many teams have serious problems with programming and wiring. If you read the Tech Forum this year during the 6 weeks, there were numerous simple questions asked about programming and wiring -- even from veteran teams. The main reason we have such strict wiring rules is the fact that so many teams have problems with wiring. Because of this I doubt we'll see an increased EE/CE/CS component of the competition.

Matt who hopes he shows up as a college student and not an other.....

[archiver]

Posted by Michael Betts at 04/12/2001 7:33 PM EST


Engineer on team #177, Bobcat Robotics, from South Windsor High School and International Fuel Cells.


In Reply to: Re: Another idea for future competitions
Posted by Matt Leese on 04/12/2001 2:40 PM EST:



:...The main reason we have such strict wiring rules is the fact that so many teams have problems with wiring. Because of this I doubt we'll see an increased EE/CE/CS component of the competition.

Matt,

People have problems with gear ratios and the concept of a fastener. Maybe we should do away with them as well... I'm only kidding (I think).

Seriously, raise the bar and people will step up.

Electron Jockey Mike

[archiver]

Posted by Kris Verdeyen at 04/13/2001 12:09 AM EST


Engineer on team #118, Robonauts, from CCISD and NASA - Johnson Space Center and Friends.


In Reply to: Re: Another idea for future competitions
Posted by Michael Betts on 04/12/2001 7:33 PM EST:



I agree wholeheartedly with Mike.

There's no reason that we couldn't simply _allow_ more freedom while keeping the basics the same for those teams that choose not to expand into that arena.


: :...The main reason we have such strict wiring rules is the fact that so many teams have problems with wiring. Because of this I doubt we'll see an increased EE/CE/CS component of the competition.

: Matt,

: People have problems with gear ratios and the concept of a fastener. Maybe we should do away with them as well... I'm only kidding (I think).

: Seriously, raise the bar and people will step up.

: Electron Jockey Mike

[archiver]

Posted by Ken Patton at 04/13/2001 3:49 PM EST


Engineer on team #65, The Huskie Brigade, from Pontiac Northern High School and GM Powertrain.


In Reply to: Re: Another idea for future competitions
Posted by Michael Betts on 04/12/2001 7:33 PM EST:



Mike-

I generally agree with you, especially about the part where we keep raising the bar.

However, if FIRST follows the same thinking they have used on the mechanical side (i.e., don't buy any SPI materials until after kickoff, don't use anything built prior to kickoff), all of these options for new sensing and control technology (which most likely would get developed in the off-season) would contribute to making the playing field less level. Just my guess on how they might view this.

I had a long discussion with a guy from SPI about the "don't buy until after kickoff" rule, and he pretty strongly stated that the motivating factor was equity among teams. I have no way of know how close he is to the actual decision.

Ken

[archiver]

Posted by Chris Hibner at 04/12/2001 3:04 PM EST


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


In Reply to: Another idea for future competitions
Posted by Kris Verdeyen on 04/12/2001 11:42 AM EST:



: One thing that I've noticed about FIRST is its emphasis on mechanical engineering and design to the extent of virtually eliminating any creative electrical and software designs. IMHO, FIRST needs to rectify this. Perhaps by allowing more purchase of electrical parts (by opening up the Digi-Key catalog similarly to the SPI arrangement), or by letting the robots compete autonomously for 15 seconds or so before the controllers turn on.

This is a great idea. I made a similar suggestion to FIRST a couple of years ago. The biggest problem limiting this is the microprocessor that is being used. We would need to switch to something a little more powerful like a Motorola HC11 or something like that. Since Motorola is a big sponsor, they might be willing to help out to make the transition. The biggest problem with making a transition is that Innovation FIRST would most likely have to do a big overhaul of the control system. I doubt we'll see anything like this for a few years.

-Chris

[archiver]

Posted by Joe Johnson at 04/12/2001 10:01 PM EST


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


In Reply to: More computational power needed
Posted by Chris Hibner on 04/12/2001 3:04 PM EST:



I really have come full circle on this issue.

I used to long for a more powerful language, but at
this point so many teams are totally overwhelmed by the
current system, I a very reluctant to give the newbies
anything more complex to deal with.

For the most part, my biggest complaint has to do with
trying to implement PID control with the relatively
limiting micro that we have available. My second &
third biggest complaints are that there is no easy
method to know wheel speed and motor current.

I think that all these could be fixed without major
overhaul of the current system.

As to PID control, I have had several thoughtful
conversations with Tony and Bob at Innovation First
about how to perhaps release a "PID control" flavor of
the Victor. This could address much of the arm control
issues for most teams.

As to current sensing and wheelspeed sensing, I have
proposed that FIRST make a class of chips available
(say the 74LS00 series or the 4000 CMOS series) as well
as passive stuff like resistors and caps and a certain
square inches of prototype board. With this stuff,
teams could make whatever sensor they liked. The
problem of how to get these sensor to the PBASIC
program can also be easily solved. I propose teams
could hook up another STAMP2 chip (perhaps mounted on a
standard Parallax prototype board) -- this STAMP2 chip
would communicate with the Innovation First STAMP2 chip
via the PROGRAMMING PORT -- look it up -- when not
programming the stamp2 chip, this port is available as
via Serin and Serout -- it would make debug statements
even less easy to use, but it would not require FIRST
or Innovation First to make a new controller. This
Auxillary STAMP2 could collect the data from these
custom sensor, perhaps do some processing and pass it
all along to the normal STAMP2.

Anyway, that is my proposal to get some more EE type
stuff into the FIRST program.

What do you folks think?

Joe J.

P.S. I would recommend that FIRST switch to the "P"
version of the STAMP2 as well as allowing us to use the
"P" flavor on the auxillary version. This "P" version
allows for some better time based stuff. It is not as
good as having "real" interrupts but it is a big step
ahead of the current "SX" flavor. Go to the
ParallaxInc.com web site for more info. if you are
interested.

[archiver]

Posted by Patrick Butler at 04/14/2001 9:47 AM EST


Student on team #122, NASA Knights, from NHGS and NASA Langley Research Center.


In Reply to: learning to like PBASIC + some suggestions for improvement
Posted by Joe Johnson on 04/12/2001 10:01 PM EST:



: I used to long for a more powerful language, but at
: this point so many teams are totally overwhelmed by the
: current system, I a very reluctant to give the newbies
: anything more complex to deal with.

I think the biggest problem to designing almost any programs in these chips is not so much the power of the chip but more importantly the language. There is no real sense of if-blocks in PBASIC. It makes it difficult to program using the backwards ifs with gotos. I am working on a small program that will convert if-elsif-else blocks to PBASIC backward-ifs, which could help in this. A real sense of functions would be helpful, too. We devised a scheme for emulating these by using the scratchpad as a stack, but it was never used becuase each time the function was called it had to use a different set of constants, and there was not enough space in RAM to store those constants to the RAM. Though, unless you are a hardcore coder this is not common knowledge.

Basically, the language needs 3 things, before we should jump for a new processor
1) If-elsif blocks, this could be implemented without making any real changes, run it through a preprocessor
2) Real functions, we should be able to pass arguments somehow
3) More variables, this would be the hardest to impleme nt, requiring a new processor, but not significantly new, i.e. it could function w/ the rest of the control system w/o any changes or so one would hope. I think 64 variables would be sufficient. With this #2 could be faked :).

With these three things, I think that designing the control systems would be easier and more powerful control systems could result. Of course we all know Dean Kamen would probably never allow this because it would make it too easy. After all this is about excercising our minds. And I enjoy a challenge, so I am almost biased to not wanting it myself.

Patrik

[archiver]

[archiver]

Posted by Nick at 04/12/2001 10:25 PM EST


Student on team #240, Mach V, from Jefferson Monroe High School and Visteon.


In Reply to: More computational power needed
Posted by Chris Hibner on 04/12/2001 3:04 PM EST:



The main problem I have with PBASIC is that it doesn't
support simple trig functions like inverse cos and
inverse sin. If we had those functions we could change
the joysticks into a polar coordinate system instead of
the same old rectangular coordinate system. This would
be optimal for swerve drive systems. By the way does
anyone know of a joystick that outputs polar
coordinates, preferably serial?

[archiver]

Posted by Joe Johnson at 04/12/2001 10:40 PM EST


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


In Reply to: my big beef about pbasic...
Posted by Nick on 04/12/2001 10:25 PM EST:



Every time I think I can't live without an inverse trig
function, I end up finding an approximation that gets
me near enough to it without the fuss of actually
having to use them.

Most of the time, I am able to approximate them close
enough with a simple linear function, but if that is
not good enough, the lookup/lookdown functions can give
about as complex of a function as you could want or
need.

Finally, if you HAVE to have it, simply devote the EEPROM
space to defining ARCSIN, ARCCOS and ARCTAN.

It would use up 3/8's of your code space in each
programming slot you need the funtions, but this would
not be too hard to manage if you break your code up
into several slots. I think you could do it if you really
needed it.

Just my opinion. I have been wrong before (once ;-)

Joe J.

[archiver]

Posted by Patrick Dingle at 04/13/2001 4:28 PM EST


College Student on team #639, Red B^2, from Ithaca High School and Cornell University.


In Reply to: Approximate!
Posted by Joe Johnson on 04/12/2001 10:40 PM EST:



Yay this is one of the rare occasions where you can use calculus... For virtually all functions you can find a power series that does a really good job at approximating the actual function (for example, sine, cosine, arctangent, etc...). The higher the order, the more accuracy you get. For sine and cosine, you can use only the first four terms of the series below and get a function remarkably similar to the real functions... at least for the applicable domain of angles between -180 and 180.

For example,

sin x = x - x^3/3! + x^5/5! - x^7/7! + x^9/9! - ...
cos x = 1 - x^2/2! + x^4/4! - x^6/5! + x^8/8! - ...
arctan x = x - x^3/3 + x^5/5 - x^7/7 + x^9/9 - ...

(! means factorial; n! = n * n-1 * n-2 * ... * 1; e.g. 5! = 5*4*3*2*1 = 120)

This area of calculus is known as Maclaurin series... check it out if you really are inspired to do so. ;p

Patrick

: Every time I think I can't live without an inverse trig
: function, I end up finding an approximation that gets
: me near enough to it without the fuss of actually
: having to use them.

: Most of the time, I am able to approximate them close
: enough with a simple linear function, but if that is
: not good enough, the lookup/lookdown functions can give
: about as complex of a function as you could want or
: need.

: Finally, if you HAVE to have it, simply devote the EEPROM
: space to defining ARCSIN, ARCCOS and ARCTAN.

: It would use up 3/8's of your code space in each
: programming slot you need the funtions, but this would
: not be too hard to manage if you break your code up
: into several slots. I think you could do it if you really
: needed it.

: Just my opinion. I have been wrong before (once ;-)

: Joe J.

[archiver]

Posted by Patrick Dingle at 04/13/2001 4:39 PM EST


College Student on team #639, Red B^2, from Ithaca High School and Cornell University.


In Reply to: Re: Approximate!
Posted by Patrick Dingle on 04/13/2001 4:28 PM EST:



In case anyone actually wants to use these approximations, I made a mistake in the cosine series. It should be:

sin x = x - x^3/3! + x^5/5! - x^7/7! + x^9/9! - ...
cos x = 1 - x^2/2! + x^4/4! - x^6/6! + x^8/8! - ...
arctan x = x - x^3/3 + x^5/5 - x^7/7 + x^9/9 - ...

Also I should point out that all angles in these are in radians. 180 Degrees = Pi radians. So, one radian is about 57.296 degrees. You'll have to use these conversions if you plan on keeping track of angles in degrees.

Patrick

: Yay this is one of the rare occasions where you can use calculus... For virtually all functions you can find a power series that does a really good job at approximating the actual function (for example, sine, cosine, arctangent, etc...). The higher the order, the more accuracy you get. For sine and cosine, you can use only the first four terms of the series below and get a function remarkably similar to the real functions... at least for the applicable domain of angles between -180 and 180.

: For example,

: sin x = x - x^3/3! + x^5/5! - x^7/7! + x^9/9! - ...
: cos x = 1 - x^2/2! + x^4/4! - x^6/5! + x^8/8! - ...
: arctan x = x - x^3/3 + x^5/5 - x^7/7 + x^9/9 - ...

: (! means factorial; n! = n * n-1 * n-2 * ... * 1; e.g. 5! = 5*4*3*2*1 = 120)

: This area of calculus is known as Maclaurin series... check it out if you really are inspired to do so. ;p

: Patrick

: : Every time I think I can't live without an inverse trig
: : function, I end up finding an approximation that gets
: : me near enough to it without the fuss of actually
: : having to use them.

: : Most of the time, I am able to approximate them close
: : enough with a simple linear function, but if that is
: : not good enough, the lookup/lookdown functions can give
: : about as complex of a function as you could want or
: : need.

: : Finally, if you HAVE to have it, simply devote the EEPROM
: : space to defining ARCSIN, ARCCOS and ARCTAN.

: : It would use up 3/8's of your code space in each
: : programming slot you need the funtions, but this would
: : not be too hard to manage if you break your code up
: : into several slots. I think you could do it if you really
: : needed it.

: : Just my opinion. I have been wrong before (once ;-)

: : Joe J.