Difference between hardware_receive_time and receive time

Questions, comments, and issues that aren't related to a specific product
Post Reply
abdulaleey
Posts: 14
Joined: Wed Aug 26, 2020 2:52 am

Difference between hardware_receive_time and receive time

Post by abdulaleey » Wed Jun 16, 2021 7:50 am

I have a doubt related to the two feedback parameters. What is the difference between hardware_receive_time and receive_time and the same is the case with the trasmit_time and hardware_transmit_time. A thing that is confusing in the document is local or remote in the explanation of both the terms. Please clarify for me.
User avatar
florian_enner
HEBI Official
Posts: 21
Joined: Wed Mar 25, 2020 11:31 am
Location: Austria

Re: Difference between hardware_receive_time and receive time

Post by florian_enner » Wed Jun 16, 2021 10:09 am

We currently track 4 timestamps and a sequence number for every packet:

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.
abdulaleey
Posts: 14
Joined: Wed Aug 26, 2020 2:52 am

Re: Difference between hardware_receive_time and receive time

Post by abdulaleey » Wed Jun 16, 2021 10:49 am

Thanks for the answer. In our controlling if we set before
group.feedback_frequency = x

thn receive_time - transmit_time should be theoretically equal to 1/x right?
User avatar
florian_enner
HEBI Official
Posts: 21
Joined: Wed Mar 25, 2020 11:31 am
Location: Austria

Re: Difference between hardware_receive_time and receive time

Post by florian_enner » Thu Jun 17, 2021 8:03 am

No, you would get the frequency by looking at the diff of any of the timestamps, so e.g., 1/diff(pc_transmit_time)
abdulaleey
Posts: 14
Joined: Wed Aug 26, 2020 2:52 am

Re: Difference between hardware_receive_time and receive time

Post by abdulaleey » Thu Jun 17, 2021 8:11 pm

How can we set feedback frequency of our own by that I mean suppose I want HEBI to act in 0.01s or 0.001s? with 100Hz or 1kHz.

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?
User avatar
florian_enner
HEBI Official
Posts: 21
Joined: Wed Mar 25, 2020 11:31 am
Location: Austria

Re: Difference between hardware_receive_time and receive time

Post by florian_enner » Mon Jul 05, 2021 12:38 pm

PID Loop
The internal PID loops run in firmware and is always running at 1Khz. The controller rate can be thought of as "perfectly periodic".

High-level Loop
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.

Jitter
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
Post Reply