1. transmit_time: time when the request goes out (relative to the pc clock)
2. hardware_receive_time: time when the request gets received on the device (relative to the hardware clock)
3. hardware_transmit_time: time when the response gets built/sent on the device (relative to the hardware clock)
4. receive_time: time when the response gets received by the computer (relative to the pc clock)
Since the clocks are not synced the hardware timestamps can not be directly compared to the pc timestamps. The most common uses are:
receive_time - transmit_time = shows end-to-end round trip time (network + network stack + encoding/decoding)
diff(pc_transmit_time) = shows jitters in the scheduler on the host pc
diff(hardware_receive_time) = shows jitters in the arrival rate at the device (host pc jitter + network 1 way jitter)
diff(sequence) = shows packet loss
I hope this helps. Let us know in case it is still unclear.
group.feedback_frequency = x
thn receive_time - transmit_time should be theoretically equal to 1/x right?
Also that difference between (receive_time - transmit_time) does not give us the time duration in which the whole process falls? And the control frequency is perfectly periodic?
The internal PID loops run in firmware and is always running at 1Khz. The controller rate can be thought of as "perfectly periodic".
The "feedback frequency" corresponds to the loop rate at which the high-level controller receives feedback and updates commands. This is typically run at 100Hz, but can be run at up to 1KHz.
Round Trip Time
The "receive_time - transmit_time" corresponds to the network round trip time, i.e., the duration between a feedback packet being requested and the feedback arriving. The network delay is independent of the loop rate, i.e., on a local wired network it may be <1ms, and when communicating over the Internet it may be in the hundreds of ms.
The execution of the "feedback frequency" follows a best effort algorithm that is subject to the scheduler on the host computer. On RT Linux you will see significantly less jitter than on Windows, but typically the jitter is at a level where it does not impact the controller. The real "hard-real time" loops are run on an RTOS on board, so the rest of the system can withstand some amount of jitter. You can find more information on OS jitter on this blog post: https://ennerf.github.io/2016/09/20/A-P ... stems.html