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

Herman Bruyninckx Herman.Bruyninckx at mech.kuleuven.be
Tue Nov 16 14:50:15 UTC 2010


On Tue, 16 Nov 2010, Konrad Banachowicz wrote:

> 2010/11/16 Herman Bruyninckx <Herman.Bruyninckx at mech.kuleuven.be<mailto:Herman.Bruyninckx at mech.kuleuven.be>>
> On Tue, 16 Nov 2010, Konrad Banachowicz wrote:
>
>
> 2010/11/16 Herman Bruyninckx <Herman.Bruyninckx at mech.kuleuven.be<mailto:Herman.Bruyninckx at mech.kuleuven.be><mailto:Herman.Bruyninckx at mech.kuleuven.be<mailto:Herman.Bruyninckx at mech.kuleuven.be>>>
>
> On Tue, 16 Nov 2010, Konrad Banachowicz wrote:
>
> - 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'.
>
> Yes  you are right but look how image processing code is developed in ROS.
> It begin as independent nodes/packages and over time move into OpenCV.

I am not so convinced that is approach is good practice.

> - 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.
>
> Yes but these parameters is specified for every trajectory point independently through JointTrajectoryPoint message.
> http://www.ros.org/doc/api/trajectory_msgs/html/msg/JointTrajectoryPoint.html
>
>
> I find it better practice to separate the Communication from the
> Configuration: the most basic, reusable approach is to provide a
> configuration API, and only then wrap this into a message-based communication.
> I don't understand how it would be implemented.
> Can you point my to some code implementing this approach ?

Most of the KDL code is being designed in this way: first virtual
interfaces (generic to a full family of kinematic chains), then various
concrete implementations, each with its own configuration parameters, and
only then embedding into a component model (be it RTT TaskContexts, or ROS
nodes) with asynchronous message types.

Herman



More information about the ros-users mailing list