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
>
(text/plain)