On Tue, 16 Nov 2010, Konrad Banachowicz wrote: > 2010/11/16 Herman Bruyninckx > > On Tue, 16 Nov 2010, Konrad Banachowicz wrote: > > > 2010/11/16 Herman Bruyninckx >> > > 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 am not so convinced that is approach is good practice. > - 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 ? Most of the KDL code is being designed in this way: first virtual interfaces (generic to a full family of kinematic chains), then various concrete implementations, each with its own configuration parameters, and only then embedding into a component model (be it RTT TaskContexts, or ROS nodes) with asynchronous message types. Herman