[Pod] Improve wheel encoder measurements

[taesungh]

Following from #11/#43, we added a preliminary wheel encoder implementation which does not utilize the full resolution of the encoder or track undersampling. Rather than updating the counter when only one of the phases changes, we can track both pin values and calculate the incremental difference. The current implement is also unable to distinguish between forwards and backwards. Having an accurate velocity is particularly important since LIM control depends on it.

[SM-dot]

Can you elaborate a bit more on " calculate the incremental difference"? from both pins we will be getting 0/1 and only on a mismatch do you get a valid pulse as implemented in the code which checks both pin values. It first checks a shift in the phase for each of the pins and then a change between A and B. For backwards I was thinking we could decrement it like last year or test to see which pin leads in each scenario as given in the documentation.

[taesungh]

The wheel encoder has two pins out of phase which produce a 2-bit Gray code

AB: 00 → 01 → 11 → 10 → cycle

and a full rotation of the wheel has four of these cycles (4 CPR), so we want the counter to change by 16 for each rotation. The current implementation considers only when A and B become different: we should also consider when A and B align.

We can enumerate the four states and compute the difference between any two states as an integer from -1 to 2.

• -1 when moving backwards
• 0 when no motion
• 1 when moving forwards
• 2 when undersampling

and this difference value can be directly added to the counter value unless when undersampling.

See last year's wheel_encoder.py for more detail.

[SM-dot]

This makes a lot more sense. Thank you! So this is what I am thinking -
-> We multiply the distance covered in each counter movement with the counter at that moment and get the distance. The count would be updated using the 2-bit gray code logic. For example:
If in 1 count the wheel moves 0.025
then Distance = counts so far * 0.025

-> Since we are factoring in the counter moving backwards as well, we can use velocity = distance/ time. Distance decreases, naturally the velocity will also decrease.

-> How would you like to handle state 2 in counts so far? I am thinking we skip it (means that we do not update counts so far) and log an error.

This approach should handle tracking both pins, account for backward movement, and improve accuracy as suggested. Does this approach seem better and work for you?

[taesungh]

The distance scalar was already considered in #43 and is being further improved in #63, so that's not a big concern. The main area of focus is calculating the state difference and using that to update the counter value. The velocity calculation can then be based on the difference in counter and time since the last counter update.

When encountering undersampling, I might see two viable approaches:

• Either assume moving in the same direction as before
• Or indicate an error and transition the FSM to the Faulted state