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

S Roderick kiwi.net at mac.com
Thu Nov 18 12:02:34 UTC 2010


On Nov 18, 2010, at 05:06 , Konrad Banachowicz wrote:

> 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:
> 
> 
> 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.
> 
> Inclusion of these trajectory generation code is a way to go for me.
> But from my point of view there is reason against including it directly in KDL.
> Waiting on inclusion of my patches, release of KDL, update of KDL in ROS would stop my development for a while.
> I think that things can be done in parallel, i can develope my components with embedded trajectory generation and work on inclusion in KDL.
> When new KDL would be released i will swich may nodes to new implementation. 

Git allows you to bypass this issue completely. Track KDL's master branch, use your own topic branch for your modifications to KDL, and then publish this branch so that the KDL maintainer's can pull it in. When your changes are integrated to KDL (some time in the future) then your next update of KDL will grab them, rebase your topic branch, and continue development. You get the benefit of always having _your_ latest and greatest, and everyone else gets the benefit of your contributions.

We do all our open-source work this way, as do most contributors.
S
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20101118/c2c46da1/attachment-0003.html>


More information about the ros-users mailing list