DPRG
DPRG List  



DPRG: Re: Still more Questions for experts

Subject: DPRG: Re: Still more Questions for experts
From: Dan Miner miner at centtech.com
Date: Tue Nov 2 16:07:17 CST 1999

> From: David Philip Anderson [mailto:dpa at io.isem.smu.edu]
> Sent: Monday, November 01, 1999 5:48 PM
> 
> 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. 

Mike beat me to the punch on this one.  Assuming you need/want
to increment by 1.0, then what he said is accurate.  However if
you want to increment by .5 or .25 (...) then it is smaller yet.
Not really an issue anyway since the robot's batteries will die
before you reach the limit.  I was just pointing out that it's 
not 1e+38 inches and a 24 bit integer works just as well for
simply incrementing to keep track of position.  

My robots use a 16 bit integer of encoder ticks.  
  Frankenstein = +/- 682 ft.
  Drilbert = +/ 124 ft.  
If this is ever a problem, I'll just go up to a 32 bit integer.

Hmmm... Considering that I will probably want fractional 
position when I get my dead reckoning code written, I'll change 
this to 24.8 fixed point.  (+/- 6 miles)

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

This is what I'm planning on doing.  (And actually HAVE done
on some of my arithmetic code already.)  However, even I
(the great hater of floating point) may break down and use
a C library for some of this trig. stuff.  But, I'm not
caving just yet!  :-)  Trade off is coding time vs. code 
space and execution time.  Also, I'd like to learn about
how CORDIC works so there would also be that benefit to me.

What I really hate is sucking up >10kB (or whatever?) of code 
space for something that could take up < 2kB (or so).  

David, is the rumor true that you are now out of code space and 
need to re-code some C to assembly to make room for new features?

> > 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! 

Well, I INTEND to tell you all about how it DOES work BEFORE
the next contest!  :-)

> 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.  :( 

Careful here!  I worked for DEC for > 10 years and VMS is The
World's Greatest and Best Operating System.  It just suffers
>from lack of market share!  :-)

> However, if some are annoyed enough to actually sit down and
> start working on their long neglected robots, so much the better!  :)

Be careful what you wish for, you may get it!  :-)  ;-)

				- Dan

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

More information about the DPRG mailing list