# translation the shaft encoder data

I am designing a robot in real world and i want to plot everything in X,Y (Cartesian) coordinates

I just want to use the encoders of wheels to determine the current position of mobile robot and its orientation depending on a specific calculation formula (like this http://rossum.sourceforge.net/papers/DiffSteer/ ) even if that will lead to inaccurate calculations .

Actually , I found out this formula below to compute x, y coordinates from encoder data but I still confused in some sides of this formula  I had a Rover 5 chassis form Dagu with two normal DC motors and two encoders (incremental rotary encoder) per each wheel, how could I translate the pulses of encoders or how to work out the x.y position of the robot based on the shaft encoder data.

I deduced some of values from Rover 5 chassis :

cm = conversion factor that translates encoder pulses into linear wheel displacement

Dn = nominal wheel diameter (in mm) : about 20 Cm

Ce = encoder resolution (in pulses per revolution) : Encoder resolution: 1000 state changes per 3 wheel rotations

n = gear ratio of the reduction gear between the motor (where the encoder is attached) and the drive wheel. : Gearbox ratio: 86.8:1

In Rover 5 chassis there are 4 small wires with female headers. RED is +5V for the encoder , BLACK is 0V (ground) , WHITE is signal A , YELLOW is signal B . The important wires in each encoder are signal A and signal B ,so

How to get values of NL , NR in the formula above from signal A & signal B ?

Is the value of NL is the direct value from wire signal A or signal B ? the same question for NR .

Thanks a lot

• Welcoms to Robotics Maria, but it is generally a bad idea to post scans of textbook pages. While it should be considered fair use, it could open us up to accusations of copyright violation, and it is much better to use MathJax to reproduce just the equations you need. Take a look at the tutorial for more info, it isn't difficult once you get the hang of it. Oct 27 '14 at 16:18

Encoders

Quadrature encoders have two sensors that look at a rotating wheel with black and white bins alternating in regular intervals (or magnetic sensors looking at alternating magnets). These two sensors are shifted relative to each other, so that when one looks at a center of one bin, the other is precisely at the edge between two bins.

Now, when the wheel spins, you will get a change on the sensors' outputs for every time one of them crosses the bin boundary. If you have $n$ bins, the value will change $2n$ times per rotation. At any time at most one of the A or B values will change, and you can calculate direction of rotation from the pattern. Also, if your microcontroller is not fast enough and misses a tick, you can detect this as both A and B changing value at once.

So, to get $N_L$ you will have to monitor the A and B signals from the left encoder and keep count of the changes. +1 for change in one direction, -1 for change in the other direction. The same goes for $N_R$, only this time you do it with the right side encoder.

concerning the $c_m$ factor, you have specified that there are 1000 state changes per three wheel rotations. That means that your $c_m$ is wheel perimeter times $\frac{3}{1000}$.

Calculating $x$ and $y$
$$x_i = x_{i - 1} + \Delta{U_i} \cos (\theta_{i - 1} + \frac{\Delta\theta_i}{2})$$ $$y_i = y_{i - 1} + \Delta{U_i} \sin (\theta_{i - 1} + \frac{\Delta\theta_i}{2})$$
One thing I can add this that odometer only works for a short distance. A few meters and not even that if outdoors running over rocks and grass. You need some other kind of sensor and then combine the data. One of those 9DOF compass/accelerometer/gyros work well can now you can get them for $5 or$6 on a breakout board. Use this and the wheel data and you are better off.