# Is this encoder error expected?

I'm working with the iRobot Create 2. When I read the encoder count and sum it for total, I'm able to do so without apparent error. I've used this to 'successfully' estimate position combining with heading from a gyro. However, when I try to estimate velocity from the encoder count, the signal seems pretty noisy.

I'll get maybe 10-15 values that are expected, and then a random outlier or two. For example: If I set the wheels to 100 mm/s and calculate the change of time between cycles (which also appears to agree with the sample time i've set of 0.017s), maybe 10-14 values will be within +-10 of 100mm/s, but then I'll get a one or two values that differ by +-50-100 mm/s.

Is this normal and I'll need to filter for a better estimation, or could there be a possible timing issue? The only thing that really impacts the program speed is the checksum used to initially discard corrupted packets.

I had this problem in my project. If you are sampling very quickly, then sometimes you get zero ticks and sometimes one. That causes a lot of noise. The solution is to only calculate velocity after a sampling time AND minimum number of ticks has passed. I do that in this project. See discussion in docs; https://github.com/Ezward/Esp32CameraRover2/blob/master/docs/wheel_encoders.md#reducing-noise-in-velocity-measurements

This might be "normal", depending on how the signal is acquired. Whenever a signal is derived, timing of the signal acquisition is crucial.

Counting ticks is not time sensitive, as it does not matter if one tick is acquires a few microseconds later or earlier, what matter is, that it is acquired.

For deriving a velocity from the ticks of an encoder, we need to know exactly when the tick happened. Given a constant velocity of 100 mm/s, we can assume a wheel circumference of 100mm, meaning 1 rotation per second. If an encoder has 1024 ticks per rotation, translates to approximately 1 tick every millisecond.

So if we do the calculation backwards, 1024 translates to 100mm/s, to make the calculations easier let us assume 1 tick translates to 0.1mm movement.

1 tick every 1 millisecond translating to 0.1 mm movement every millisecond.

In order to calculate the velocity for every tick, means that we need to measure the time between ticks, which translates to registering the exact time of the tick event or stating a timer and stopping a timer at tick events. The precision of the time measurement can be influenced by:

• The timer precision. If the timer has a millisecond precision, that, in an extreme worst case could mean that we have 0 registered milliseconds between two ticks resulting in an unfeasible velocity. A 0.1 millisecond precision of the timer would mean a 10% precision of the velocity for the example above

• The event detection. Before we get to start top timers or register time, we need to actually detect the event. If the encoder can trigger hardware interrupts, that translates to starting the interrupt routine at clock frequency (e.g. 8Mhz for a microcontroller). If we are regularly polling the state of the encoder, the polling rate has a major influence on the precision. If we are polling with 0.1 milliseconds the extreme worst case is that we register the tick event 0.1 ms late, but we register the next tick exactly at the right moment. So 0.1 ms polling would lead to a 10% precision on the velocity for the example above.

• First thanks for the detailed response, i appreciate the time you took to write that out. T he create publishes the encoders as data packets using a stream which updates every 15ms. So im not even able to get the individual change between 1 count to the next, unless im misunderstanding. From what ive read theyre pretty cheap encoders. i request the encoder data along with all the internal sensors when starting the stream so maybe i should request them seperately? I feel like i could filter the data with like low pass to cut out the random spikes but is that normal to do with encoders? @50k4 Feb 26, 2021 at 1:13
• You can filter, yes (maybe mean or median filter) or use more then 2 samples for the derivation (calculate finite difference over 5-8 samples). Do you get timestamps for the position data? If you get source time stamps they are more precise, than the communication time stamps. 15ms update cycles for precise motion control is already not normal. Generally for a position control loop 1 - 4 ms is current practice, 0.5 ms is currently considered very good.
– 50k4
Feb 26, 2021 at 7:36