DPRG List  

[DPRG] Another encoder counting issue (plus a rant against FP )

Subject: [DPRG] Another encoder counting issue (plus a rant against FP )
From: Dan Miner miner at centtech.com
Date: Wed Aug 29 11:47:31 CDT 2001

> -----Original Message-----
> From: Clay Timmons [mailto:ctimmons at cadence.com]
> Another issue I've run into with encoders relates to the number of
> tics per inch.   On my robot I get something like 40.357 tics 
> per inch.
> Since I don't use floating point math my code has 40 tics per inch.
> The round off error adds up,   for 20 feet = 240 inches
> 240 * 40 = 9600 tics
> 240 * 40.357 = 9685 tics

I solve these issues by not thinking in inches.  
The unit that I use is an "encoder tick".

In other words (to use your example), a contest course of
20 feet is not 240 inches.  Instead, it is 9685 ticks.
Besides, the robot cannot measure any distance finer than
1 tick anyway, so why worry about fractions of a tick?

That way, my caluclator does the floating point math and my 
robot can stick to integer.  Speeds are ticks per second 
(not inches/sec) or sometimes it is more convienent to think 
of microseconds per tick.  Even my sensor routines (sonar, IR) 
compute their results in (motor) encoder ticks.  Now that does 
take some integer fraction work (or a lookup table for 
non-linear sensors) but I solve it like this:

Let's say that I want to multiply by pi = 3.14159265358979...
A very good approximation is 355/113 = 3.14159292...
(Note: Of course, any typical fraction works here.)

A 68HC12 has an instruction to take a 16 bit number (N) and 
multiply by another 16 bit number (355) yielding a 32 bit result.  
Another instruction takes a 32 bit number (N*355) and divides by a 
16 bit number (113) yielding a 16 bit result (N*355/113 = N*pi).

	LDY	#355		;  2 clks (D already contains N)
	EMUL			;  3 clks  D * Y => Y:D = N*355
	LDX	#113		;  2 clks
	EDIVS			; 11 clks  Y:D / X => Y = quotient
				;             D = remainder (for rounding)

In 18 CPU clocks (8MHz = 2.25 microseconds) I have a very good
approximation to N*pi.  Let's see any floating point library
beat that with anything less that FP in hardware (or a Pentium)!

	- Dan "We don't need no stinkin' floating point" Miner

PS - I thought the quadrature encoder solution of placing the
sensors 180 degrees apart and using any odd number of bars (except 
1) was very clever.  So simple yet it eluded lots of us.  I wish I 
had thought of it...

More information about the DPRG mailing list