frankaemika/libfranka

Reduced message size for standard UDP protocol?

Closed this issue · 5 comments

markusgft commented

Dear all,
I am testing the possibilities to control the Panda using the FCI using a small embedded computing unit. The network chip of this computing unit has an MTU-size of 1500 bytes and is not equipped with a Gigabit ethernet port.
While outgoing UDP control messages for the franka robot have a size of ca 370 bytes, incoming robot-state messages sent by the robot have more than 1500 bytes, which consistently leads to significant delays due to package fragmentation.
Is there any way to reduce the size of the incoming robot state messages to something smaller than 1500 bytes? Even temporary or hacky solutions would be highly appreciated!

sgabl commented

Hi,
we thought about going back to 1472 bytes for the robot state to avoid packet fragmentation e.g. by using compression. However, this is more of a longterm goal. There is no way to reduce the size of the robot state without changing the FCI, what would require an update of the firmware of the robot.

What is your result of the ping test? In general, 100 Mbit/s (full duplex) would be more than enough for FCI.

markusgft commented

Thank you for the quick response, I see that this might be a long-term issue then.
At the core of the problem is that my hardware is not equipped with a dedicated network chip, the fragmentation/reassembly is handled by the CPU, which only frees up time for this every 10ms.

Would you mind commenting on your rough time-horizon for your plans to update the FCI as described above?

sgabl commented

Okay, how often are packets processed in general? You should get a RRT of at least 0.35 to 0.4 ms.
I can not provide a time horizon as we first need to evaluate if this even would make sense (e.g. additional delay due to compression)

gavanderhoorn commented

Would it be an option to implement some sort of subscription system? Some other robot manufacturers allow you to register for specific data, instead of always streaming a full message.

For the default setup, it could just subscribe to everything.

For other uses, consumers could express interest in subsets which could lower datarate requirements (and the issue that @markusgft is running into) significantly.

  • 👍2
markusgft commented

A subscription system like the one proposed by @gavanderhoorn would certainly be a great solution.

Another potential mid-term solution (not requiring compression/decompression) would be to simply reduce the message size. I think the current robot state message is just slightly larger than 1500 bytes. At the same time it I find it very "verbose", e.g.

  • the strings descripting failure or robot states could potentially be made much leaner
  • the orientation-states could be expressed in terms of quaternions rather than rotation matrices
  • etc...

In any case, I do not have the feeling that there will be a quick solution. Lets close this for now.