To LUGNET HomepageTo LUGNET News HomepageTo LUGNET Guide Homepage
 Help on Searching
 
Post new message to lugnet.robotics.rcxOpen lugnet.robotics.rcx in your NNTP NewsreaderTo LUGNET News Traffic PageSign In (Members)
 Robotics / RCX / 977
976  |  978
Subject: 
Another way to avoid Float
Newsgroups: 
lugnet.robotics.rcx
Date: 
Fri, 19 Jan 2001 12:58:46 GMT
Viewed: 
1430 times
  
For the navigation of my robot, I do not plan to use float or trig function.
I will use long integer (32bits).
the high 16 bit are the true integer value.
the low 16 bits are 1/65535 value.

let say
1           = 0x00010000
2           = 0x00020000
2.5         = 0x00028000
2.25        = 0x00024000
2.125       = 0x00022000
2.0625      = 0x00021000
2.03125     = 0x00020800
2.015625    = 0x00020400
2.0078125   = 0x00020200
2.00390625  = 0x00020100
2.001953125 = 0x00020080
and so on...

With this system , I will have number from -32768 to 32767 with a precision of
1/65536 ( = 0.000015255878 ) which is enough.
My wheels have a diameter of 40 mm.
I have a ratio 1:3 between wheel and rotation sensor (1 turn = 3x16 = 48 ticks)
So the sensor precision is 40 mm x PI  / 48 = 2.61 mm / tick
and the range of my pseudo floating integer will be 2.61 x 32768 = 85524.48mm =
85 meters (-85m to +85m) which is larger than the robot area (aka my house).

In term of rotation precision, the two middle wheel have 160 mm between them.
So when the robot rotate 360°, each wheel run on a circle of 160 mm diameter.
this gives 160*PI / 40*PI wheel turns  = 160/40= 4 turns = 4*48ticks = 192
ticks for a 360° turns.
So after a 360° rotation, one wheel will have +192 ticks and the opposite wheel
will have -192 ticks.
the diff will be 192 + 192 = 384 ticks.
the precison of sensor is 360°/384 = 0.93 ° / tick

The next step : coordinate computing without using sin() nor cos() !
In fact, instead of calling heavy trig function, I 'll use a pre rendered table
of sinus value. Because of symetries in sinus and cosinus, it 's enough to have
a array representing 0° to 90°.
In my case I will fill this array with 96 (=90°/0.93°) constant values (0° ,
0.93°; 1.86°, ... and so on till 90°. )
Naturally the value inside the array will be coded with my pseudo floating
integer. (I'll just multiply the sinus by 65536).

Normally, as the sensor precision is far less than the precision of my pseudo
float, I think there is no need to use real float.
It will be a fastest and smallest code without significant loss
This pseudo float and pre rendered sinus table were used in the beginning of
flight simulator, when PC hadn't any Floating Point Processor.

See you,
Michael.



Message has 1 Reply:
  Re: Another way to avoid Float
 
(...) them. (...) diameter. (...) wheel (...) This is all well and good, but the all consuming problem with location tracking is slippage. What happens if one wheel slips? What about if it hits an obstacle at an angle? If you find some way around (...) (24 years ago, 26-Jan-01, to lugnet.robotics.rcx)

3 Messages in This Thread:

Entire Thread on One Page:
Nested:  All | Brief | Compact | Dots
Linear:  All | Brief | Compact
    

Custom Search

©2005 LUGNET. All rights reserved. - hosted by steinbruch.info GbR