Is this encoder error expected?

Question

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.

Answer 1

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

Answer 2

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.