Expected time delta between Timer.system() and. Rotation.timestamp()

VEX V5 Technical Support OFFICIAL Tech Support
1

Hi, I was trying to capture data from our tracking wheels setup and not sure why I’m seeing what’s going on with the timing values comparing Timer.system() rand Rotation.timerstamp().

Based on my understanding, Rotation sensors update by default every 20ms, so a ~10ms loop capturing data should see up to 20ms delta between the system time and the sensor timestamp + some delta accounting for internal Brain and VexOS sensor update delay, so maybe up to 30ms?

What I’m seeing on the other hand is the time delta starting off being delayed between 30-40ms and slowly increasing. After about 7 seconds the delta is bouncing between 80-90ms. The code here is very simple:

def sampling_thread_callback(self):
    brain.screen.print("Sampling Thread Started")
    global run_sampling

    rot_l = [] # list for left rotation sensor
    rot_r = [] # list for right rotation sensor
    rot_s = [] # list for sideways rotation sensor

    system_times = [] # list for system times

    system_timer = Timer()

    total_samples = 0

    # Capture data
    while self.run_sampling:
        current_time = system_timer.system()
        system_times.append(current_time)

        rot_l.append([RotationLeft.position(TURNS), RotationLeft.timestamp()])
        rot_r.append([RotationRight.position(TURNS), RotationRight.timestamp()])
        rot_s.append([RotationRear.position(TURNS), RotationRear.timestamp()])

        total_samples = total_samples + 1

        wait(10, MSEC)

    # Print data 
    print("Total Samples = ", total_samples)
    print("idx, time, rotl TURNS, rotl TIME, rotr TURNS, rotr TIME, rots TURNS, rots TIME")
    wait(10,MSEC)
    for i in range(total_samples):
        rotl_val, rotl_time = rot_l[i]
        rotr_val, rotr_time = rot_r[i]
        rots_val, rots_time = rot_s[i]
        print(i, ",", system_times[i], ",", rotl_val, ",", rotl_time, ",", rotr_val, ",", rotr_time, ",", rots_val, ",", rots_time)
        wait(500,MSEC)

Captured results from this is below (note sideways sensor omitted for brevity). The last two columns are just the difference between the system time “Time” and the respective sensor timestamps “rotl TIME” and “rotr TIME”.

run6_rotonly
run6_rotonly990×988 97.1 KB

Any help appreciated here …

Thanks,
Nick

1 Like
2

You’re witnessing clock drift (and several other factors) I believe.

Rotation.timestamp() is not the Brain’s timestamp when it recieved the packet, but rather the device’s recorded timestamp when it sent the packet. Since the clock hardware between the devnce and the brain are different (Cortex-A9 vs. Cortex-M0+) there’s always some amount hardware clock drift, though I don’t think that’s the main issue here.

There’s also the fact that you’re comparing the timestamp of when the device sent the packet vs. the time you accessed the data. Those times can be vastly different, since it takes time for the device data to be sent to the Brain and processed in the background by VEXos. VEXos will only process incoming packets from devices every 10ms by a background task, regardless of how fast the device is sending data to the brain. As such, the Device.timestamp() value will always have at minimum a ~10mS gap between packets.

There’s also the question of scheduler timings. Your code that reads the timestamp value off the sensor is not perfectly synchronized with the background task responsible for updating device data, meaning you aren’t immediately reading the data as it becomes available to you. VEX’s cooperative scheduler is doing other things between those wait(500,MSEC) calls and you don’t have exact control over when your code runs. That means there may be any amount of time between when VEXos decides to update device data in its 10mS interval and when your code actually gets to read that data.

1 Like
3

Actually it is the time that the brain received (or rather initially processed in cpu0) the packet. Now it may take time to pass to cpu1 and then to user code. At some point, if I ever get any free time, I’ll try and reproduce what OP is seeing here.

3 Likes
4

Interesting, never knew that, though it explains a lot. A few months ago I was testing a method of more robust disconnect detection using those values and was confused why the value didn’t reset when the device lost voltage. :sweat_smile:

Is that timestamp different from the raw position getter on motors? I know that people have attempted more accurate velocity estimation using that outvalue in the past. Guess it’d still be accurate than CPU1’s clock value, but it would mean that those estimations are more off than expected.

1 Like
5

Thanks @Tropical, yes I’m expecting some amount of internal delay for this to actually get passed through to the code itself, which is why I was expecting the delta to be more like 30ms with a fair amount of jitter. The fact that I’m seeing 30-40ms therefore at the start of sampling was a little higher than expected, but not by itself much of a concern.

However, the delta steadily increases which is not expected. Every second it seems to add about 10ms to the delta. Speaking of which, the pre-auton code takes about 3 seconds for sensor initialization, so temporarily removing this and allowing the sampling code here to start straightaway provides initial deltas more in the 10-20ms range (but then starts increasing at the same rate as before).

Nick

6

Thanks @jpearman. For now I’ll use the Rotation.changed() and then use the Timer.system() to act as a timestamp, although this is probably slightly delayed from what the actual timestamp would be. Doing it this way I’m seeing an average of 10ms :+1:

Related to the changed() callbacks, I had noticed previously that for the older 3-wire ports there was a filter on when changed gets called ( What is criteria to calling analog_in.changed()? - VEX V5 Technical Support - VEX Forum. Wondering if that applies to other sensors like Rotation sensor? I’ll see at least try to see if I can get it to register a 1 LSB rotation.

Nick

7

Just a suggestion for Vex (which has been made before), but maybe adding more details about each device’s specifications (including notes about data rates between the device and the brain/software environment) would be nice. For example, one would need to find VexForum posts (mainly from you, which sort of helps) to find information like the FOV on the Distance Sensor, it’s data update rate, etc.

Adding this data to each sensor’s Product Sheet would be nice

5 Likes