On Tue, 16 Nov 2010, Konrad Banachowicz wrote:
- mixing the creation of a TaskContext with a specific implementation of a
generic interface (trajectory generation in this case) is not a good
practice; these three things should be separated, in order to improve
modular reuse.
- more in particular, new trajectory generation algorithms are preferably
submitted to Orocos/KDL as contributions, instead of "hiding" them inside
a ROSified node, where they are very difficult to reuse in other
frameworks or stand-alone applications.
Trajectory generation reside in ROS stack because it is intended to be as much as possible compatible with trajectory generation used in ROS.
I have no problem with using ROS nodes to improve interoperability, but
functional algorithms belong in component/node-independent source trees,
for maximal reusability within whatever 'component framework'.
Yes you are right but look how image processing code is developed in ROS.
It begin as independent nodes/packages and over time move into OpenCV.
- I do not see much Configuration options, while this subject of trajectory
generation, servoing etc lends itself extremely well to fine tuning and
customization via setting of configuration properties.
I have not seen any parameters that can by configured in trajectory
generation algorithm which i implemented.
Strange. Typically, I expect parameters such as maximum speeds, minimal
time steps, required tolerance, etc.
Yes but these parameters is specified for every trajectory point independently through JointTrajectoryPoint message.
http://www.ros.org/doc/api/trajectory_msgs/html/msg/JointTrajectoryPoint.html