Thanks you for reply.

2010/11/15 Herman Bruyninckx <Herman.Bruyninckx@mech.kuleuven.be>

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

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

> - 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 ?

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

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

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

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