[ros-users] [Orocos-users] [release] orocos_tools 0.1.0 and orocos_controllers 0.1.0

[Herman Bruyninckx]

On Tue, 16 Nov 2010, Konrad Banachowicz wrote:

> Thanks you for reply.
>
> 2010/11/15 Herman Bruyninckx <Herman.Bruyninckx at mech.kuleuven.be<mailto:Herman.Bruyninckx at 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.

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:
  <http://people.mech.kuleuven.be/~orocos/pub/documentation/rtt/v2.1.x/doc-xml/orocos-components-manual.html#task-services>
Or here:
  <http://people.mech.kuleuven.be/~orocos/pub/documentation/rtt/v2.1.x/doc-xml/orocos-rtt-plugins.html#id359475>

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