2010/11/16 Herman Bruyninckx > On Tue, 16 Nov 2010, Konrad Banachowicz wrote: > > >> 2010/11/16 Herman Bruyninckx > Herman.Bruyninckx@mech.kuleuven.be>> >> >> 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 >> >> > I find it better practice to separate the Communication from the > Configuration: the most basic, reusable approach is to provide a > configuration API, and only then wrap this into a message-based > communication. > I don't understand how it would be implemented. Can you point my to some code implementing this approach ?