G.A. vd. Hoorn

It would indeed make sense to use values calculated/derived by the controller if possible. That would be preferable over `dx/dt` on the ROS side.

@hartmanndennis: would you be interested in making the changes to read the joint velocity from the RSI datastream?

I seem to remember joint velocities being available through the RSI function blocks as well. But I'm not sure, would have to check the manual again.

Hm, no: `POSACT`, `AXISACT` and `GEARTORQUE`. No velocities. Thought: what about making RSI do the `dx/dt` for us? There is a `D` object.

Is this with the `D` RSI block, or calculated on the ROS side?

Ok. would you be up for trying the `D` component? I'm rather curious to see whether there would be any difference.

Ok, fair enough. It would be good if we could use `IPOC_(t_n+1) - IPOC_(t_n)` for these `dx/dt`s as well. So we can avoid having to configure that as a parameter....

Btw: I believe what you're seeing in those plots is exactly why using a real-time OS with deterministic scheduling is so important for RSI (and a host of other tasks).

Related previous discussion: #87 and #161 (which actually removed the `EffortJointInterface`) and #227 (which makes it configurable again).

We could also configure a set of both position *and* effort controllers in the controller configuration `.yaml`s. The position ones will be started by default, with the option for the...