Difference between hardware_receive_time and receive time
-
- Posts: 15
- Joined: Wed Aug 26, 2020 2:52 am
Difference between hardware_receive_time and receive time
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.
- florian_enner
- HEBI Official
- Posts: 33
- Joined: Wed Mar 25, 2020 11:31 am
- Location: Austria
Re: Difference between hardware_receive_time and receive time
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.
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.
-
- Posts: 15
- Joined: Wed Aug 26, 2020 2:52 am
Re: Difference between hardware_receive_time and receive time
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?
group.feedback_frequency = x
thn receive_time - transmit_time should be theoretically equal to 1/x right?
- florian_enner
- HEBI Official
- Posts: 33
- Joined: Wed Mar 25, 2020 11:31 am
- Location: Austria
Re: Difference between hardware_receive_time and receive time
No, you would get the frequency by looking at the diff of any of the timestamps, so e.g., 1/diff(pc_transmit_time)
-
- Posts: 15
- Joined: Wed Aug 26, 2020 2:52 am
Re: Difference between hardware_receive_time and receive time
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?
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?
- florian_enner
- HEBI Official
- Posts: 33
- Joined: Wed Mar 25, 2020 11:31 am
- Location: Austria
Re: Difference between hardware_receive_time and receive time
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
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