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