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

[Herman Bruyninckx]

On Fri, 12 Nov 2010, Konrad Banachowicz wrote:

> I would like to announce first release of orocos_tools and
> orocos_controllers stacks.

Thanks!

> These stacks are intended to simplify development of OROCOS based robot
> controllers and integrating them with ROS by providing set of commonly
> used components.  My vision is, that integration with new hardware should
> be as simple as possible, you only need to implement some low-level
> components like hardware interface and servo algorithm. And reuse common
> components for trajectory generation, force-control and integration with
> ROS. You can see schematic of simple controller on
> http://www.ros.org/wiki/orocos_controllers .
>
> Implementation is very experimental, but i have succesfully run irp6
> manipulator using this. It need much more testing, but i think this is
> good time to start discussion on what users would expect from those
> stacks.
>
> Pozdrawiam
> Konrad Banachowicz

Some feedback:

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

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