I am currently experimenting with velocity estimation using data from the v5 motor’s integrated encoder. Using PROS, I have noticed strange inconsistencies between position readings which seem to come in small clusters rather than single blips. I have graphed the change in tick count with respect to time to illustrate the behavior:
On the highlighted cell you can see that the tick count did not increase between the two samples. If the missed ticks always occurred like this with no change between samples I would assume that the problem had to do with the fact that the internal buffer is only updated every 20ms by vexOS and this was happening due to phase difference between the buffer updates and the calls to get_position(). However, most of these glitches seem to occur with anomalous tick differences ranging from 120 to 30 ticks (where the nominal / expected tick difference due to the motor velocity is around 68). I am struggling to identify the source of this behavior.
Here is my small code snippet which I used to collect this data:
I have heard that the Sylib velocity estimator uses some tricks to synchronise its tasks to the underlying vexOS update loop but I am struggling to find the original post. Any ideas?
It’s somewhat to be expected.
The motor is keeping track of the encoder count, it sends that data to the V5 approximately every 5mS based on its internal timers.
vexos will update internal counts for the get_position call approximately every 10mS based on when the PROS/FreeRTOS scheduler allows that to run. You are reading the count that vexos has updated every 20mS. The motor and V5 clocks are asynchronous, there will be instances where a count update is either missed by vexos or two happen in that time period.
Thanks, I see your point about the desynchronization of the timers, however i am struggling to see how this has such a pronounced effect to the point where 4 samples in a row slip by at least one 5ms cycle. I have put together a very simple simulation for the raw count, internal count, get_position buffer and 20ms readings with a large variance in each of the timers but I still don’t quite see why 4 slips would be able to occur consecutively:
However, I imagine you are right and there is nothing I can do within the code to better synchronise the readings. I will have to try working on some much more error tolerant velocity estimation filters. I would be interested to know how the v5 OS internally estimated encoder velocity, or is this done at a hardware level on the motor chip? Thanks again for the insight!
Accidentally posted this on my alt-account oops! I hope this makes more sense to anyone reading now! Again if anyone knows of the sylib timer synchronisation feature I referred to earlier I would like to find out more about how this was done and if it would help. Thanks.
