Expected average package loss for real-time communication loop (UDP)

[markusgft]

Using the panda, we get a non-insignificant rate of package loss (according to the test-executable "communication test" that is shipped with libfranka, up to 10% of package loss can be considered a "success", in my own work I normally see 2-4 % of average package loss).

When talking to other Franka panda users, the statements about communication loss rate vary (anything between 0.5 and 5% gets mentioned frequently), but it seems that the community is generally not clear if this is expected behaviour. Of course the package loss using UDP may vary with overall network traffic, hardware performance etc. Still it would be great if someone could elaborate on expected average package loss values on a clean and correctly installed system (using a standard PC).

The topic was originally brought up in this issue, but is more general in scope and should be treated here.

[markusgft]

@sgabl @fwalch pushing this on top of your stack again. Any comments are highly appreciated.

[gavanderhoorn]

I'd be interested in this as well.

[jrmout]

From our experience, our standard office laptops with their integrated Ethernet card are enough for most use cases and are typically in the 1 - 5 % range. If you need the best possible performance we also tried server ethernet cards (we tried for instance Intel's I350-T4), where you reach on average around 0-1%. How much you really need depends on your application. As a rule of thumb:

• For motion generations
  • If you are moving very slowly a not so perfect communication (up to 5%) is probably enough, your packet losses will produce only tiny discontinuities that the robot can handle. The low pass filter and the rate limiter will also help here.
  • If you want to move very fast and close to the limits of the robot you will probably need a very good communication. The low pass filtering and the rate limiter are just not enough for figuring out the motions during the discontinuities.
• For the torque interface
  • If you are targeting a very compliant controller packet losses up to 5% are fine. The torques involved are not high and the low pass filter, the rate limiter and the constant torque packet loss policy can deal well with this issues.
  • If you want very high stiffness control then you will need a very good communication, especially if you want to filter yourself some signals, otherwise you will easily end up with instabilities or vibrations.

[markusgft]

Dear @jrmout, thanks a lot for your answers.

We ordered and tested a the I350-T4 network card with our robots, and in fact we can now achieve higher gains and better performance with our custom controllers using the torque interface.

However, I am still wondering how far the ambitions research-driven user can go with the franka torque interface running at 1 kHz with non-insignificant package loss. I assume the default franka cartesian impedance and joint impedance controllers are running on the control PC which is shipped with the robot - does this one internally use a higher controller update rate, e.g. 5 kHz or similar? In other words, even with good network cards and solid software engineering, will it ever be possible for the research-user to match the performance of your default impedance controllers?

[AndreasKuhner]

Hi @markusgft,
I might be a bit late to the party here... but our controls running on the control PC is also 1kHz. This also allows the user to (theoretically) control the robot as good as we can.

Of course, we have a bit more freedom on the 'what' we do but the goal is/was definitely to give the user as much freedom and control as possible.

Interesting side-note... we are working on multi arm setups - which puts again more pressure on the communication. Hence, we also try to robustify this a bit more...

Cheers,
Andreas