Accurate timestamps for robot joint positions

[alonks1234]

Hi, I would like to understand if/how we can access the timestamps of the encoder measurements and convert into the system time of a host machine.

This is important for aligning against camera image timestamps along with other external sensors.

Currently I am not sure if this information is accessible beyond just calling "get_servo_angle" and noting the timestamp on the computer, which does not account for latency at all.

Please advise, and thanks!

[vimior]

@alonks1234 First of all, the acquisition of the position of the mechanical arm, the acquisition of camera image data or other external sensor data, these tasks are all implemented on your host, and the required timestamp should be the timestamp when you acquire various data on your host. Alignment needs to be done according to the acquisition time of various devices. Deviation:

• The position of the robotic arm acquired through the interface is not the encoder data at this time. The control box collects data at 250HZ, so the position acquired by the host computer through the interface is only the latest encoder position.
• Network time consumption
• Time-consuming collection of various data

[alonks1234]

To be clear, the timestamps need to be at the moment of data acquisition not when the host computer reads the sensor. For example, Realsense cameras maintain 4 distinct timestamps corresponding to when the camera is 50% through exposure, when the camera finishes exposure (and puts first packet on the USB), when the host computer receives the data at the kernel level, and finally when the data is received in the library.

This level of transparency allows me to know the specific timestamp of a single image frame, even though there may be dozens of milliseconds of latency between when it is captured and when my host computer receives it.

So far as I can tell, the xArm API does not allow for this level of transparency. I can sample at ~250hz, sure, but I don't actually have any sort of insight as the latency properties of the measurement. Am I 4ms behind? 40? Latency and throughout are unfortunately different things.

Suggested solution could look something like this:

• Control box samples encoder data and associates a timestamp with each sample, according to control box computer current time.
• Ensure latency of control box sampling of encoders is sufficiently small (eg, <100 microseconds). Ideally the timestamp would be as close as possible to the moment the encoders is read.
• An optional argument to get_servo_angle to return the timestamp in the time of the control box computer (note, this is not directly comparable to host cpu time)
• An API call to sample control box computer time. With this call, I could synchronize the clocks by sampling cpu time a few dozen times, averaging out the network latency, and get a pretty good sense of how to convert control box time into host cpu time.

Thanks!