[Polymetis] Reading Gripper (Franka Hand) State Slow

[AlexanderKhazatsky]

It seems that reading the gripper state is over 10x slower than reading from the robot state, and I was wondering if it would be possible to get them both on par :)

Extra details: I'm using a robotic gripper

Robot State Reading:
Avg Delay: 0.0021165368556976317
Std Delay: 0.0008280045818800743
Min Delay: 0.000965118408203125
Max Delay: 0.011021852493286133

Gripper State Reading:
Avg Delay: 0.032056391954421996
Std Delay: 0.0017448229778961374
Min Delay: 0.02130889892578125
Max Delay: 0.05079293251037598

[1heart]

Seems expected when comparing a 200Hz vs. 1kHz robot. See #756 if you want non-blocking reads.

[AlexanderKhazatsky]

Hmm so a couple questions:

1. I can't seem to find a non-blocking read, but I do see non blocking commands
2. The commands with blocking=Flase still seem to still take a significant amount of time? Usually on the scale of 0.01 seconds. Is this expected?

[AlexanderKhazatsky]

Similarly, I'm observing that even robot.update_desired_joint_positions takes ~7ms to run. I was under the impression it would be non blocking and pretty much instantaneous?

[exhaustin]

Non-blocking reads does not provide any value as it would be nearly as fast as a blocking read.

Sending non-blocking commands should indeed be quite fast, can you check your ping between the two machines to see if you're being bottlenecked by internet speed? Also, arm commands usually takes a bit longer than gripper commands to send (especially the move_to commands) because it's a bit more complicated to construct the commands.

[AlexanderKhazatsky]

Definitely not blocked by server speed, ping time is under ~0.5 ms.

Also, actually finding that arm commands are ~3ms faster than gripper commands :)

[AlexanderKhazatsky]

I also have a temp fix of running the commands in a new thread

[exhaustin]

That is interesting, thanks for the detailed info.
We'll try to repro/fix when bandwidth allows, reopening the issue to keep track.
Good to know you have a working fix!

[AlexanderKhazatsky]

Thank you as always! Oh also one argument for the non-blocking read:

I'd like to get current gripper width to feed into a policy. Giving it current pose / joints takes ~1ms, but if I want to give it gripper it requires an extra ~10ms currently. I'd much prefer a quicker, but less potentially older read :)

[AlexanderKhazatsky]

I'm now realizing that this command runs in ~1ms. How did you guys fix this? :)

[exhaustin]

We didn't make any changes with regard to this issue :D
Should we consider it resolved now?

[AlexanderKhazatsky]

Hahah interesting!! Especially since the gripper hz is stil 200…

I wouldn’t consider it fully resolved since robot.update_desired_joint_positions takes ~7ms for some reason, but the running the command in a thread solution works works well :)