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

[Konrad Banachowicz]

2010/11/16 Herman Bruyninckx <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>>
>>
>> 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 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 ?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20101116/2cefe1c2/attachment-0003.html>