DPRG List

 [DPRG] Another encoder counting issue (plus a rant against FP ) Message index sorted by: [ date ] [ thread ] [ subject ] [ author ] Previous message: [DPRG] Home-brew Next message: [DPRG] RPL 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... ``` Previous message: [DPRG] Home-brew Next message: [DPRG] RPL Message index sorted by: [ date ] [ thread ] [ subject ] [ author ] More information about the DPRG mailing list