On Tue, 16 Nov 2010, Konrad Banachowicz wrote: > Thanks you for reply. > > 2010/11/15 Herman Bruyninckx > > On Fri, 12 Nov 2010, Konrad Banachowicz wrote: > > - most files do not contain any license information; if you make > Orocos-derived work (which you do, I think, and which is, of course, > allowed and even stimulated) you are bound by using the same license as the > work you derive from; and in the case of Orocos that is LGPL and not BSD > (most of the time). > Yes I know about this problem, but there is no simple solution. > I need to do some more research on that. No need to do this effort on your own! These mailing lists are there to help you out :-) > - your naming is somewhat misleading/incomplete at multiple places. An > illustrative example is "JointSplineTrajectoryGenerator": the name nor > the (lack of) documentation inside the .h and .cpp files indicate that > those files are making components (TaskContext) in which to run a > trajectory generator. > - the trajectory generator mentioned above happens to be the exception to > this rule: it _does_ generate a trajectory. But I find no information > about what algorithm is being used, by which publications or other code you > have been inspired, who to give credit, and why this particular > implementation was chosen. > - a documentation file explaining the design, the inspiration, the vision, > and the roadmap of your efforts would make it much easier for others to > start contributing. (Or to decide whether it makes sense to contribute or > not.) > I am working on improvement of documentation. Good! Don't hesitate to call in the help of the mailinglist, as soon as you have a preliminary version ready. > - hence, you leave little room for other people to add other trajectory > generator algorithms. > - this use case of having multiple algorithms that can serve the same > purpose is rater common, and that's where the "plug-in services" in > Orocos have been designed for. > Can you point me to some example on "plug-in services" in orocos ? It is a rather new 2.x feature, so there is not that much "prior art" available yet. General information can be found in the Component Builders manual: Or here: You might ask around on the Orocos-dev mailinglist, to find others that have already used services for similar purposes. > - 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'. > - the link to GitHub, on the ROS website > "Source: git https://github.com/RCPRG-ros-pkg/orocos_controllers.git" > is faulty: the last ".git" extension need not be there. > These links are generated automatically by ROS wiki. Oops. > - 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. > In any case, I appreciate very much your efforts, and I hope they can turn > into something the community finds worthwhile enough to contribute to. > Personally, I would prefer a much more decoupled approach, separating > algorithms from services, from components/nodes, and from data flow > definitions. > Best regards, Herman