correct idiom for time-aligned network tables?

[truher]

hey, i spent awhile measuring our camera latency, which varies depending on the alignment of the sensor row loop, the coprocessor cpu loop, and the rio main loop. i'd like to get the end-to-end latency to be correct, and i imagined the time-alignment of network tables would help. before i get too far down that road, i just wanted to verify (@PeterJohnson ?) what i'm supposed to do:

in the (python) coprocessor client, i have an estimate of the "age" of a pose:

publisher.set(pose, ntcore._now() - age_in_microsec)

and in my (java) rio listener, i go:

void listen(NetworkTableEvent event) {
    var value = event.valueData.value;
    var time = value.getServerTime() / 1e6;
    var pose = someDecoder(value.getRaw());
    poseEstimator.addVisionMeasurement(pose, time)
}

so the "age" of the signal on the coprocessor is translated into the server time base.

is that right? i think the key question is whether ntcore._now() - age_in_microsec matches the nt time base.

[PeterJohnson]

Yes, that’s the correct approach.

[truher]

ok, thanks. is there a reason for the little "pretty-please-private" underscore in ntcore._now()?

[rzblue]

Unrelated to the original question- keep in mind that if you're using a listener callback, it will be called from a separate thread, so you'll want to synchronize accesses to the pose estimator. It's usually easier to either use readQueue on a subscriber, or if you actually need to read events, use a listener poller

[truher]

yeah, that's a good point, thanks. we noticed the concurrency issue some time ago and made a less-complainy pose estimator with ConcurrentSkipListMap, but we've never really looked very hard at any of it. each camera goes slightly slower than the rio itself, so something much simpler would probably be fine.

[truher]

I was poking at an issue in simulation today, and realized that getServerTime has the important caveat, "May be 0 or 1 for locally set values."

Have we talked about this before? It's super confusing for some values to be, like, the time, but for other values to be magically zero, depending on who wrote them. How should the consumer know what is what?

[truher]

I realize now that I really have no idea what the distinction is between getTime and getServerTime, or why it is useful.

On the RIO, are they the same?

[PeterJohnson]

getServerTime returns the value's time in the server's time base. getTime returns the value's time in the local time base. As the RIO is the server, these are both the same for code running on the RIO (for values set on clients). On a client (such as a dashboard), getTime returns the local clock version of the value's time, while getServerTime returns the value's time in the RIO time base.

When you write a value locally (e.g. call a set or setDefault function), it can be impossible to know what the server time is (e.g. a client that hasn't yet connected to a server has no idea what the server time is). You can also create a NT instance before configuring it as either a client or a server, and even switch which it is, so it would be pretty unpredictable if we e.g. looked at the current state of the instance and conditionally set the server time field for values based on that.

You can set the server time for locally set values by passing it to the NetworkTableValue constructor and using the corresponding setter, but this is pretty unusual.

The reason it can be 0 or 1 is that 0 is a special value used for setDefault. So if you call setDefault, it forces both time and serverTime to 0; if you do a normal set, the time will be the local time and serverTime will be 1.

[truher]

So why would anyone ever want to use server time?

• In the coprocessor I never use it, I just use ntcore._now() when writing.

• On the RIO I should use value.getTime() to get a local time I can always compare to FPGATime (never 0 or 1).

It seems like the purpose of server time is so that a coprocessor can know the remote (server) time base, but I can't think of a reason a coprocessor would want to know that. Isn't the whole point of the NT time sync mechanism to avoid mixing timebases?

[PeterJohnson]

Yes, for nearly all use cases, you want time in the local time base. The server time is there for clients that want to have that visibility, which is mostly dashboards or programmer debugging tools, not coprocessors.

[truher]

I apologize for my ongoing trouble here. I'm investigating drift between the RoboRIO and the Raspberry Pi, and it seems like the time sync protocol isn't being used at all. Is there a simple way to check?

What I have is a simple RoboRIO program that does two things: (a) publish the fpga time, and (b) listen for time sync. so literally the following:

public Robot() {
    listener = NetworkTableListener.createTimeSyncListener(
                NetworkTableInstance.getDefault(), true, this::consume);
}
...
public void robotPeriodic() {
    pub.set(RobotController.getFPGATime());
}

(the "consume" function just prints)

On the Raspberry Pi side, it just runs a loop every 20ms that computes the difference between the two clocks:

        servernow = sub.getAtomic()
        pinow = ntcore._now()
        pub.set(servernow.time - pinow)

This measurement drifts about 10 millisec in 200 seconds, which is enough for us to care, and seems like about the same as the Raspberry Pi clock drift.

The bigger question is why my "consume" function is only called at startup.

I've also measured the offset on the pi, just publishing the value in the same main loop:

        offset = ntcore.NetworkTableInstance.getDefault().getServerTimeOffset()
        if offset is not None:
            offset_pub.set(offset)

this appears to be set once and then never changed.

Any advice? How do you observe the behavior of the time sync mechanism?

[truher]

ohhhhhhhh

#5224

[ntcore] Only measure network latency/exchange timestamps on initial connection

8b7c685

- Measure RTT only at start of connection, rather than periodically

So this is apparently working as intended. The time sync thing only syncs at the start of each session, and isn't intended to adjust the offset to compensate for clock drift.

Sooooooo any suggestions about what should we do about clock drift?