DPRG List

 DPRG: Re: Still more Questions for experts Message index sorted by: [ date ] [ thread ] [ subject ] [ author ] Previous message: DPRG: More answers from experts Next message: 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 ------------------------------ ``` Previous message: DPRG: More answers from experts Next message: DPRG: Re: Still more Questions for experts Message index sorted by: [ date ] [ thread ] [ subject ] [ author ] More information about the DPRG mailing list