DPRG
DPRG List  



DPRG: Re: Still more Questions for experts

Subject: DPRG: Re: Still more Questions for experts
From: Robert L. Jordan rljordan at airmail.net
Date: Mon Nov 1 20:14:14 CST 1999

You goofs make me grin!:-))))
Thanks
Robert Jordan

David Philip Anderson wrote:

> Howdy
>
> Dan Miner writes:
>
> >> The robot position is calculated and stored in floating
> >> point, so we ought to be able to keep track of zillions of inches.
>
> > Not zillions of inches.  After the exponent gets > N, then the least
> > significant mantissa bit represents a number > 1.  When this happens
> > and you want to add 1 more incremental odometer tick, then it gets lost.
> > (I'm keeping it terse here.  If anyone wants the longer and clearer
> > version, ask.)
>
> Pretty picky, Dan!  If you need to be precise, SR04 uses IEEE #754 single
> precision (32 bit) floating point numbers which can represent values
> roughly covering the range +- 10^38.   My units conversion utility says
> that's about 1.57828e+33 miles.  To put it another way, that's about
> 269,808,720,749,580,964,634 lightyears.   Or, in hobby robot terms, that's
> approx = 1 zillion inches.
>
> > My belief is that for slow (<10MHz) CPU's with limited memory,
> > floating point should not be used.  Instead, fixed point and
> > digital differential analyzers (DDA) should be used.
> >
> > The largest counter-argument against my viewpoint is that it takes
> > lots of hours to write this code vs. simply using an existing
> > floating point library in C or similar.
>
> Floating point is only required for the trig used in the odometry functions.
> This means implementing not only a specialized multi-byte fixed point scheme,
> but also the sin, cos, and arctan functions.  I've looked at doing this with
> table lookup and simple interpolation, or implementing CORDIC functions like
> most pocket calculators use.
>
> Or one might just load in the floating point library and go back to work on
> the interesting part, the robot behaviors.  You pays your money and you makes
> your choice.  I think this largely depends on what piece of the problem you
> are interested in solving.
>
> > I intend to look at the
> > contest maze from area A to see most of the cans and then plan the
> > robot's path before it even leaves A to start the timer.  The previous
> > sentence holds true even if the robot "sees" with sonar or a camera.
>
> Talk talk talk.  I won't be convinced until I hear a description of what
> the robot IS doing, rather than what it "will do."  I can do that, too!
> I *intend* to have my robot hover at the next contest, and tell jokes to
> the audience as it expertly locates full soda cans and distributes them
> to the lovely ladies in attendance.
>
> Hey, this is fun!  I'll also have it take us all out to dinner and cook
> a delicious and healthful meal, clean up the kitchen, and tuck the children
> in bed with a happy bedtime story.
>
> Then, at contest time, all I have to do is say, "Well, I stayed up all
> night long, just about had it all working, but still have some little
> software bug I need to straighten out.  Next time, for sure!  You guys
> better look out, 'cause I'm gonna have it all working by next time!"
>
> (Mr. Godot?  No, he won't be able to be here today.  But tomorrow, I'm sure
> he'll be here tomorrow.)
>
> Now, for the delicate among us, this is all intended in friendly jest, so
> please don't send me nasty flames or demand apologies from your cave... er...
> I mean ... your VMS terminal.  Humor sometimes doesn't come off too well
> across the internet.  :(
>
> However, if some are annoyed enough to actually sit down and start working
> on their long neglected robots, so much the better!  :)
>
> Hope to see you all Saturday.
>
> peace,
> dpa

------------------------------

More information about the DPRG mailing list