Some time ago, I introduced the CommandBuffer class to act as a single-element buffer for high-frequency commands, mostly devised for CSP mode (IPositionDirect):
This feature allowed to decouple the rate of incoming commands (those flowing through the YARP network) from the CSP rate (i.e. commands sent via CAN to the iPOS drives) while also performing linear interpolation (LERP). Prior to that, clients needed to send IPositionDirect commands at exactly the same rate as --syncPeriod; otherwise, a sloppy behavior was to be expected.
I observed that this can be further improved as the behavior is still far from ideal when commands flow irregularly and in lower frequencies. I suggest a dual mechanism to achieve this:
Spline interpolation via higher-order polynomials, i.e. (beyond linear ones) cubic and perhaps even quintic polynomials. I'm also thinking of minimum jerk trajectory generators, see this YARP implementation for Gazebo: hpp, cpp.
Some time ago, I introduced the CommandBuffer class to act as a single-element buffer for high-frequency commands, mostly devised for CSP mode (IPositionDirect):
https://github.com/roboticslab-uc3m/yarp-devices/blob/42b3091a91d202baab46b62df3886176d28ae79b/libraries/YarpPlugins/TechnosoftIpos/CommandBuffer.hpp#L11-L30
(implementation)
This feature allowed to decouple the rate of incoming commands (those flowing through the YARP network) from the CSP rate (i.e. commands sent via CAN to the iPOS drives) while also performing linear interpolation (LERP). Prior to that, clients needed to send IPositionDirect commands at exactly the same rate as
--syncPeriod
; otherwise, a sloppy behavior was to be expected.I observed that this can be further improved as the behavior is still far from ideal when commands flow irregularly and in lower frequencies. I suggest a dual mechanism to achieve this: