Encoder reports too low distance when requesting distance at high frequency (from micro-controller)

[benska13]

• When you ask too often, <100 ms, the distance becomes incorrect.

[BjAlvestad]

In the micro-controller code for the encoder, inside the i2c_request() method (triggered every time data is requested), the following calculation is performed, and stored in a long:

(sign * encoder0Pos) / ticks_per_cm

After this the encoder0pos gets set to 0.

Since the calculation gives a decimal number, and it gets truncated when stored in the long. The reported distance may therefore be incorrect by up to 0.999... cm per request.

This would not show up as an issue when requesting infrequently (where the car has driven several meters prior to request). However with frequent requests where the distance traveled since last time is relatively short, up to 1 cm incorrect measurement per request will add up to a large total deviation.

Suggested fix:

• Store the calculation first in a float.
• Then store the truncated value that should be sent (as a long)
• Store the difference between the two back into encoder0Pos (instead of just resetting to 0, which would cause data to be lost).

I.e.
Replace old code:

long longs_to_be_sent[] = { (sign * encoder0Pos) / ticks_per_cm, millisecond };
encoder0Pos = 0;

With somthing like:

float distanceTraveled = (sign * encoder0Pos) / ticks_per_cm;
long distanceTraveledInWholeCm = distanceTraveled;
long longs_to_be_sent[] = { distanceTraveledInWholeCm, millisecond };
encoder0Pos = distanceTraveled - distanceTraveledInWholeCm;

Of course making changes to the microcontroller code at this stage would require re-testing, therefore the issue has been logged here, together with information regarting what the team thinks the issue may be.
To be fixed next time modifications are made on the microcontroller code of the car.