Thanks you for reply.<div><br><div>2010/11/15 Herman Bruyninckx <span dir="ltr"><<a href="mailto:Herman.Bruyninckx@mech.kuleuven.be">Herman.Bruyninckx@mech.kuleuven.be</a>></span><div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div class="im">On Fri, 12 Nov 2010, Konrad Banachowicz wrote:<br></div>
<br>
- most files do not contain any license information; if you make<br>
  Orocos-derived work (which you do, I think, and which is, of course,<br>
  allowed and even stimulated) you are bound by using the same license as the<br>
  work you derive from; and in the case of Orocos that is LGPL and not BSD<br>
  (most of the time).<br></blockquote><div>Yes I know about this problem, but there is no simple solution.</div><div>I need to do some more research on that. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">


- your naming is somewhat misleading/incomplete at multiple places. An<br>
  illustrative example is "JointSplineTrajectoryGenerator": the name nor<br>
  the (lack of) documentation inside the .h and .cpp files indicate that<br>
  those files are making components (TaskContext) in which to run a<br>
  trajectory generator.<br>
- the trajectory generator mentioned above happens to be the exception to<br>
  this rule: it _does_ generate a trajectory. But I find no information<br>
  about what algorithm is being used, by which publications or other code you<br>
  have been inspired, who to give credit, and why this particular<br>
  implementation was chosen.<br>
- a documentation file explaining the design, the inspiration, the vision,<br>
  and the roadmap of your efforts would make it much easier for others to<br>
  start contributing. (Or to decide whether it makes sense to contribute or<br>
  not.)<br></blockquote><div>I am working on improvement of documentation.  </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
- hence, you leave little room for other people to add other trajectory<br>
  generator algorithms.<br>
- this use case of having multiple algorithms that can serve the same<br>
  purpose is rater common, and that's where the "plug-in services" in<br>
  Orocos have been designed for.<br></blockquote><div>Can you point me to some example on  "plug-in services" in orocos ?</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">


- mixing the creation of a TaskContext with a specific implementation of a<br>
  generic interface (trajectory generation in this case) is not a good<br>
  practice; these three things should be separated, in order to improve<br>
  modular reuse.<br>
- more in particular, new trajectory generation algorithms are preferably<br>
  submitted to Orocos/KDL as contributions, instead of "hiding" them inside<br>
  a ROSified node, where they are very difficult to reuse in other<br>
  frameworks or stand-alone applications.<br></blockquote><div> Trajectory generation reside in ROS stack because it is intended to be as much as possible compatible with trajectory generation used in ROS.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">


- the link to GitHub, on the ROS website<br>
  "Source: git <a href="https://github.com/RCPRG-ros-pkg/orocos_controllers.git" target="_blank">https://github.com/RCPRG-ros-pkg/orocos_controllers.git</a>"<br>
  is faulty: the last ".git" extension need not be there.<br></blockquote><div>These links are generated automatically by ROS wiki.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">


- I do not see much Configuration options, while this subject of trajectory<br>
  generation, servoing etc lends itself extremely well to fine tuning and<br>
  customization via setting of configuration properties.<br></blockquote><div>I have not seen any parameters that can by configured in trajectory generation algorithm which i implemented.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">


In any case, I appreciate very much your efforts, and I hope they can turn<br>
into something the community finds worthwhile enough to contribute to.<br>
Personally, I would prefer a much more decoupled approach, separating<br>
algorithms from services, from components/nodes, and from data flow<br>
definitions.<br>
<br>
Best regards,<br><font color="#888888">
<br>
Herman<br>
</font></blockquote></div><br></div></div></div>