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