The node currently stamps all stamped data with the ROS time when a new RTDE package is received. This has two issues:
- Data isn't stamped with the time when it's published on the robot, but with the time processed on the ROS side. Thus, the timestamp doesn't physically match the measurement time.
- RTDE data comes in with a jitter (roughly with periods of 1.5 - 2.5 ms). Thus, though generated with a fixed period of 2 ms, ROS data will not be equidistant in the time domain.
Thus, using the robot's timestamp as sent with the RTDE data might be useful. The timestamp contains the time elapsed since the controller was started [s]. We could save the ROS time $t_0$ with the first timestamp $T_{0}$ that we receive. Then, at any given package, the timestamp would be $t_n=t_0 + T_n - T_0$.
I think, that behavior should be opt-in with a parameter and properly documented.
That approach doesn't solve the first issue, though. We could potentially add a parameter to substract a constant value $t_{delay}$ from the time that estimates the communication delay (basically from the first timestamp). I think, if we add that, the default $t_{delay}$ should be 0, as we cannot generally estimate this. With this, timestamps would evaluate to $t_n = t_0 - t_{delay} + T_n - T_0$.
The node currently stamps all stamped data with the ROS time when a new RTDE package is received. This has two issues:
Thus, using the robot's timestamp as sent with the RTDE data might be useful. The timestamp contains the time elapsed since the controller was started [s]. We could save the ROS time$t_0$ with the first timestamp $T_{0}$ that we receive. Then, at any given package, the timestamp would be $t_n=t_0 + T_n - T_0$ .
I think, that behavior should be opt-in with a parameter and properly documented.
That approach doesn't solve the first issue, though. We could potentially add a parameter to substract a constant value$t_{delay}$ from the time that estimates the communication delay (basically from the first timestamp). I think, if we add that, the default $t_{delay}$ should be 0, as we cannot generally estimate this. With this, timestamps would evaluate to $t_n = t_0 - t_{delay} + T_n - T_0$ .