Rosanswers logo


Perhaps I should make the question even broader: I have a simple motion controller which needs to receive positions and velocities every 4ms (it's firmware is written in c++). I want to use ROS (currently using kinetic) to plan some trajectory (complicated or simple), and feed it to the motion controller. The problem I'm facing now is that the generated trajectory is not smooth and is not ready to be fed as is to the motion controller. Should I use other motion planning tools? or should I use tools to smoothen the trajectory?

More deatails:

I think I understand all of the tool-chain of ROS-I, but I'm missing the part of motion planning. I saw some questions about it, but most of them are pretty old.

The ROS-I tutorials show two ways (in general) for motion planning. One is using MoveIt! and the other is using descartes (which is still experimental?).

I've tried using MoveIt!, however, I need to interpolate the generated trajectories in constant time gaps and feed that to my controller (I do it in the robot driver - not with ROS). The trajectory that MoveIt! generates is pretty awful. The acceleration profile is really bad, and it affects the velocity and position. for example: image. Anyway, as I understand, MoveIt! is good for complicated motion planning tasks, for example obstacle avoidance, but the paths that it generates are not smooth.

This question talks about interpolating, does the given answer is still valid? Someone wrote there that using ROS Industrial Trajectory Filter is the solution, but after reading about it and looking at the code, I don't think it solves the problem.

What I'm looking for, is a motion planning tool that is more suitable for basic industrial robotics motion planning that generates smooth reliable paths. Is descartes the tool I'm looking for?

Last question: I saw there are Inverse-Kinematics solvers (such as KDL, trac_IK) . Are they just used by the motion planners? Or do these packages also allow to make motion planning?

Originally posted by ManMan88 on ROS Answers with karma: 44 on 2017-12-24

Post score: 1

Original comments

Comment by ManMan88 on 2017-12-25:
I saw this issue, and this issue I'm not sure if I fall to the same category and if this is fixed already


1 Answer 1


Rosanswers logo

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).

Originally posted by gvdhoorn with karma: 86574 on 2018-01-12

This answer was ACCEPTED on the original site

Post score: 2

Original comments

Comment by ManMan88 on 2018-01-15:
Thanks you


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.