Revision history [back]

I believe the 'problem' here is that in a ROS 'context', motion planning is considered at a much higher level than what you are referring to. In (industrial) robotics, motion planning is often 'just' trajectory generation, which at that level essentially is interpolation between two Cartesian ..

(or joint) poses.

Secondly, none of the pkgs you mention were meant for what you tried to do with them, which is low-level, hard real-time motion profile interpolation and trajectory generation. That is typically left to either hw or a low(er)-level software (stack). One example could be machinekit, but there are more.

If/when you have that level of abstraction and control sorted out, then start looking at the motion planning tools in ROS.

re: ros-i traj filter: that does actually include functionality for equidistant trajectory resampling, which seems like it would be what you want/need, but I've not used it, so I can't say anything about the quality of the output.

Your 'last question' also points a bit to the conceptual differences between motion planning in various fields or communities: IK solvers are just that: solvers for IK queries. They can be used as part of a motion planner (or trajectory generator in your case), but on their own are definitely not meant (or designed) for those tasks. They deal with a completely different part of the problem (namely: mapping of joint space to Cartesian space poses and vice versa).