I would like to announce first release of orocos_tools and
orocos_controllers stacks.
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
[release] orocos_tools 0.1.0 and orocos_controllers 0.1.0
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
[release] orocos_tools 0.1.0 and orocos_controllers 0.1.0
Thanks you for reply.
2010/11/15 Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...>
> On Fri, 12 Nov 2010, Konrad Banachowicz wrote:
>
> - 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).
>
Yes I know about this problem, but there is no simple solution.
I need to do some more research on that.
> - 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.)
>
I am working on improvement of documentation.
> - 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.
>
Can you point me to some example on "plug-in services" in orocos ?
> - 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.
> - 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.
>
These links are generated automatically by ROS wiki.
> - 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.
> 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
>
[release] orocos_tools 0.1.0 and orocos_controllers 0.1.0
On Tue, 16 Nov 2010, Konrad Banachowicz wrote:
> Thanks you for reply.Herman [dot] Bruyninckx [..] ...>>
>
> 2010/11/15 Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...
> On Fri, 12 Nov 2010, Konrad Banachowicz wrote:
>
> - 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).
> Yes I know about this problem, but there is no simple solution.
> I need to do some more research on that.
No need to do this effort on your own! These mailing lists are there to
help you out :-)
> - 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.)
> I am working on improvement of documentation.
Good! Don't hesitate to call in the help of the mailinglist, as soon as you
have a preliminary version ready.
> - 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.
> Can you point me to some example on "plug-in services" in orocos ?
It is a rather new 2.x feature, so there is not that much "prior art"
available yet. General information can be found in the Component Builders
manual:
<http://people.mech.kuleuven.be/~orocos/pub/documentation/rtt/v2.1.x/doc-xml/orocos-components-manual.html#task-services>
Or here:
<http://people.mech.kuleuven.be/~orocos/pub/documentation/rtt/v2.1.x/doc-xml/orocos-rtt-plugins.html#id359475>
You might ask around on the Orocos-dev mailinglist, to find others that
have already used services for similar purposes.
> - 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'.
> - 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.
> These links are generated automatically by ROS wiki.
Oops.
> - 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.
> 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
[release] orocos_tools 0.1.0 and orocos_controllers 0.1.0
On 16/11/10 08:45, Herman Bruyninckx wrote:
>>> - 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'.
+Infinity.
Geoff
[release] orocos_tools 0.1.0 and orocos_controllers 0.1.0
On Nov 16, 2010, at 09:51 , Geoffrey Biggs wrote:
> On 16/11/10 08:45, Herman Bruyninckx wrote:
>>>> - 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'.
>
> +Infinity.
+I
[release] orocos_tools 0.1.0 and orocos_controllers 0.1.0
2010/11/16 Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...>
> 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...
[release] orocos_tools 0.1.0 and orocos_controllers 0.1.0
On Tue, 16 Nov 2010, Konrad Banachowicz wrote:
>Herman [dot] Bruyninckx [..] ...>>
> 2010/11/16 Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...
> 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...
>
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.
Herman
[release] orocos_tools 0.1.0 and orocos_controllers 0.1.0
2010/11/16 Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...>
> On Tue, 16 Nov 2010, Konrad Banachowicz wrote:
>
>
>> 2010/11/16 Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...
>>
>> 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...
>>
>>
> 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 ?
[release] orocos_tools 0.1.0 and orocos_controllers 0.1.0
On Tue, 16 Nov 2010, Konrad Banachowicz wrote:
> 2010/11/16 Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...Herman [dot] Bruyninckx [..] ...>>Herman [dot] Bruyninckx [..] ...><mailto:Herman [dot] Bruyninckx [..] ...Herman [dot] Bruyninckx [..] ...>>>
> On Tue, 16 Nov 2010, Konrad Banachowicz wrote:
>
>
> 2010/11/16 Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...
>
> 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...
>
>
> 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
[release] orocos_tools 0.1.0 and orocos_controllers 0.1.0
2010/11/16 Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...>
> On Tue, 16 Nov 2010, Konrad Banachowicz wrote:
>
> 2010/11/16 Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...
>> On Tue, 16 Nov 2010, Konrad Banachowicz wrote:
>>
>>
>> 2010/11/16 Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...
>> Herman [dot] Bruyninckx [..] ...<mailto:
>> Herman [dot] Bruyninckx [..] ...>>>
>>
>>
>> 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.
>
> - 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...
>>
>>
>> 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
>
I would like to discuss more design of orocos robot controller than internal
design of individual components.
I think we should start from communication between hardware/sorvo component
and trajectory generation.
I created oro_servo_msgs for this purpose but i developend it with IRP6
manipulators in mind.
I imagine that it could be common way of communication with any modern
manipulator like KUKA LWR.
[release] orocos_tools 0.1.0 and orocos_controllers 0.1.0
On Nov 18, 2010, at 05:06 , Konrad Banachowicz wrote:
> 2010/11/16 Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...>Herman [dot] Bruyninckx [..] ...>>Herman [dot] Bruyninckx [..] ...><mailto:Herman [dot] Bruyninckx [..] ...Herman [dot] Bruyninckx [..] ...>>>
> On Tue, 16 Nov 2010, Konrad Banachowicz wrote:
>
> 2010/11/16 Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...
> On Tue, 16 Nov 2010, Konrad Banachowicz wrote:
>
>
> 2010/11/16 Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...
>
>
> 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
[ros-users] [release] orocos_tools 0.1.0 and orocos_controllers
On Mon, Nov 15, 2010 at 3:12 PM, Konrad Banachowicz <konradb3 [..] ...> wrote:
>> - 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.
>
> These links are generated automatically by ROS wiki.
The URL it uses is the URL of the actual source repository, which has
a .git extension. If you go to [1], you will see that the .git URL is
the one listed.
The ROS wiki has no explicit knowledge of github URL practices. Other
Git repositories do not allow you to strip the .git suffix.
- Ken
[1]: https://github.com/RCPRG-ros-pkg/orocos_controllers
[release] orocos_tools 0.1.0 and orocos_controllers 0.1.0
2010/11/18 S Roderick <kiwi [dot] net [..] ...>
> 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.
>
Yes i understand the work-flow but i use ROS build system for my components
which grab KDL from ROS distribution. I can create overlay for KDL in ROS
but then everyone who want to build my stack need overlay too.
[release] orocos_tools 0.1.0 and orocos_controllers 0.1.0
On Thursday 18 November 2010 13:15:52 Konrad Banachowicz wrote:
> 2010/11/18 S Roderick <kiwi.net
> 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. Yes i understand the
> work-flow but i use ROS build system for my components which grab KDL from
> ROS distribution. I can create overlay for KDL in ROS but then everyone
> who want to build my stack need overlay too.
There is an orocos_kdl package in our orocos_kinematics_dynamics stack that
tracks the trunk of kdl.
Ruben