Encoders Analysis - WPISmartmouse/Smartmouse_2018 GitHub Wiki

how high resolution do our encoders need to be?

Let's set our constraints. We want to estimate our wheel velocity every 1.5ms (which we do because 650Hz). We want to be able to measure between 0.2m/s and 1m/s (0.2 is the will then be the slowest we are able to go), with less than 5% error.

If we read the encoder every 1.5ms, and we are traveling 0.2m/s, given wheel radius of 0.0145m, then our rotational speed is $\frac{0.2m}{1s} \frac{1}{2\pi0.0145m} = 2.195$ rotations per second. If we want to measure this 650 times a second, that's $\frac{2.195rot}{1s} \frac{1s}{650cycle}=0.00337rot/cycle$. Here a cycle refers to a control loop update. If we have a 10 bit resolution encoder, then we have $\frac{0.00337rot}{1\text{cycle}} \frac{2^{10}\text{counts}}{1rot} = 3\frac{\text{count}}{\text{cycle}}$. This is not enough, because being off by one count would mean 33% error in velocity estimate. Essentially, we want 20counts/cycle so that we have 5% error. Of course this error is less problematic at higher speeds (more counts). But to acheive 5% error at 20m/s we need $0.00337*2^n=20$, so n=12.535, which rounds up to 13. We can then see what happens at 1m/s. At 1m/s we go $\frac{1m}{1s}\frac{1s}{2\pi0.0145m}=10.976rot/s$, then $10.976rot/s \frac{1s}{650\text{cycle}} = 0.0169rot/cycle$, then $0.0169\frac{\text{rot}}{\text{cycle}} \frac{2^{13}\text{count}}{1rot}=138.33\frac{\text{count}}{\text{cycle}}$ which is a bit more than we need.

So, we need a 13 bit encoder on the output shaft if we want to be able to measure speeds within 0.2 and 1m/s at 650Hz with at most 5% error.

Lets consider what would happen if we put it on the input shaft. We have a gear ratio of 50:1 (the input shaft spins 50 times faster than the output shaft). Solve the following for n: $\frac{0.00337rot \text{(output)}}{1cycle} \frac{50 rot \text{(input)}}{1rot \text{(output)}} \frac{n counts}{1rot} = 20\frac{\text{counts}}{\text{cycle}}$. If you solve this, n=119.

This means we would need an encoder with 119 CPR or more on the input shaft

Lets figure out how many interrupts will happen per second at 1m/s. $\frac{119counts}{1rot} \frac{10.9762rot}{1s} = 1.306\text{kHz}$ (interrupts per second).

Profiling encoder counts

In order to decide whether we should do our encoder counting on the teensy or another chip, we need to count how much CPU encoder counting eats up. We do this by comparing the amount of time a blocking piece of code takes when motors are moving versus stationary. When the motor is stationary, the encoders will not generate any interrupts. When they are moving, the encoder will generate lots of interrupts and the same for loop will take up more time.

Run the profile_encoders program in real/main to generate these numbers:

microseconds per count = 0.575us

So, if we want use 14 bit output-shaft encoders at 0.9m/s how long per control loop will it take to count encoders?

$$0.9\frac{\text{m}}{\text{s}} \frac{1rot}{2\pi0.0145m} \frac{1s}{650\text{cycle}} \frac{2^{14}\text{count}}{1rot} \frac{0.575\mu s}{1\text{count}} = 127.26 \frac{\mu\text{s}}{\text{cycle}}$$

In other words, it will take 127 microseconds per control loop to count our encoders at 90cm/s with 14 bit encoder on the output shaft. That is non-trivial but acceptable.

Evaluating The AS5048A as our Encoder datasheet

The AS5048A is a 14bit magnetic rotation position sensor. You mount the board a few millimeters from a 5mm dimaeter magnet, and you can read the position via SPI. We must first consider the error on the sensor, which according to the datasheet is 2.73LSB rms. Therefore, the number of ticks it can be off by at any given position is $2^{\sqrt{2.73}} = 3.14$ ticks. Out of a total $2^{14}=16384$ ticks, this error of 3.14 ticks is "negligible".

Because this is an SPI encoder, we don't even need to worry about encoder counting! But we must still consider the timing. Each command to the AS5048A is a 16bit command, and the response to the read command will be received in response to the next command. All command responses are delayed by one command. How long does one command take? Each command is 16 bits, so with a baud rate of 921600 it will take $16\text{bits}\frac{1s}{921600\text{bit}} = 17.3\mu s$. We will have to do this twice per control loop,so that's 34.6us total. We will simply ignore the result of the first read command and use the second.

Testing the Real AS4058A

We observe $\pm4.5$ of ADV values of noise, which is $log_2(4.5)^2 = 4.70857$ LSB rms. This is just slightly higher than the datasheet reports, which means it's slightly less accurate than expected.