Hi all,
I create a new thread because I think it is not good to continue in an other
thread
As I am beginning to interface my hardware on my robot (especially my CAN
bus), I wondered about where I could find others components or publish my
code to help others, I asked :
> [...]where is the place for such a
> component ? is it the job of OCL v2 ?
Peter's answer :
> No. Create a package repository similar to how a ROS package tree works
(ie
> identical :-) , and point people to that repository. You can use git or
svn,
> or whatever you feel most comfortable with.
First of all, I am not complaining about a miss, but trying to understand
what's the Orocos roadmap about "community integration". I think there is a
lack and as I love Orocos I can't accept it can't conquer the world :p
I totally agree on the fact it is not the job of Orocos developpers to
provide such "users components". But what about a common place where users
provide their components ? For exemple eclipse market place, your favorite
web browser plugin download page, the ROS wiki ... ?
Is it a clear will not to provide such a place or a lack of hands to
create,maintain this ?
Of course I may publish my SVN (it is not currently interesting but let
imagine it is), how a new user may find ready-to-use-components ? I can't
even find a link to the huge work DFKI has done from the Orocos web site
(and I know what I am searching) !
Is it because Orocos is not mature enougth to wish to handle all this stuff
?
Are you expecting more and more people using Orocos as a ROS stack and let
user using the ROS wiki to do this ?
The place for sharing users component
On Tuesday 22 February 2011 18:58:24 Willy Lambert wrote:
> Hi all,
>
> I create a new thread because I think it is not good to continue in an
> other thread
>
> As I am beginning to interface my hardware on my robot (especially my CAN
> bus), I wondered about where I could find others components or publish my
>
> code to help others, I asked :
> > [...]where is the place for such a
> > component ? is it the job of OCL v2 ?
>
> Peter's answer :
> > No. Create a package repository similar to how a ROS package tree works
>
> (ie
>
> > identical :-) , and point people to that repository. You can use git or
>
> svn,
>
> > or whatever you feel most comfortable with.
>
> First of all, I am not complaining about a miss, but trying to understand
> what's the Orocos roadmap about "community integration". I think there is a
> lack and as I love Orocos I can't accept it can't conquer the world :p
>
> I totally agree on the fact it is not the job of Orocos developpers to
> provide such "users components". But what about a common place where users
> provide their components ? For exemple eclipse market place, your favorite
> web browser plugin download page, the ROS wiki ... ?
> Is it a clear will not to provide such a place or a lack of hands to
> create,maintain this ?
>
> Of course I may publish my SVN (it is not currently interesting but let
> imagine it is), how a new user may find ready-to-use-components ? I can't
> even find a link to the huge work DFKI has done from the Orocos web site
> (and I know what I am searching) !
>
> Is it because Orocos is not mature enougth to wish to handle all this stuff
> ?
> Are you expecting more and more people using Orocos as a ROS stack and let
> user using the ROS wiki to do this ?
Okay... I have no clue where to start responding to this thread, so I'll start
at the top again.
First about user concerns about migrating from 1.x to 2.x to 3.x ? The upgrade
path might seem bumpy from an observers point of view, but lots of the issues
raised come from 'new features' users are testing, instead of the 'old code'.
For example: the BFL typekit has been written in a way that was impossible in
1.x, ie, the BFL maintainers wrote a 2.x typekit with much more features than
the 1.x version. It were these new features that caused some pain, not 'a pure
upgrade' from 1.x. We did identify one backwards compatibility issue (the
lacking of the (de)compose functions), which was fixed in 2.2.
Another example are the CMake macros. These are brand-new, and we encourage
people to test/use them because they add so much more (in terms of usability!)
than what was possible in 1.x. It's a new feature, it takes a release or two
to stabilize.
The best we have to support upgrading from 1.x is the earlier mentioned wiki
page "Upgrading from RTT 1.x to 2.0". It does contain all available documents,
which are quite a bunch imho. It does not contain an 'upgrading tutorial' as
Stephen suggested, I admit this is useful, but we're all picking our fights.
The comparison with 1.0 -> 1.6 versus 2.0 -> 2.3 is appallingly unfair. It
took us almost 5 years to get to the 1.6 release, while less than 6 months to
2.3. Also, 1.0 was not that different from 0.24.0, as 2.0 is from 1.0. We're
doing frequent major releases to provide updates asap.
Also, I have personally no plans for looking at/maintaining 3.x. I also have
no idea who would have the guts to write that anyway. I'm sticking to 2.x for
a long time to come [ Insert your Linux kernel analogy here :-) ]
So far for the defense. I consider any user input as the highest truth, even
if they are un- or misinformed. Perception is everything and I'm (and the
other core developers) so far off from the 'newbie user experience' that we
have no idea how it looks like from that side. So yes keep bashing, it keeps
us from developing exotic features and _forces_ us to work on improving what
people actually *use*. I would consider silence as a very bad sign as well.
Should everything (user contributed components, best practices, hardware
abstraction etc) belong in OCL ? When I decided to remove all these pieces
from OCL in 2.x, it was to make a clear statement: I Am Not Maintaining That
Code. I will remove any unmaintained code from the releases I make. I
suggested that people set up their own repositories, since then it's clear
who's the maintainer of which contributed component, something which is very
unclear in OCL 1.x, and which I wanted to avoid in 2.x. Although Herman has a
point that scattered maintainership leads to fragile dependencies, it also
allows you to point at someone when things break. When the CAN, Vision or
Cartesian control components broke in 1.x, who was to blame ? The reality
shows there that if it's unmaintained, it will also break with all-in-OCL. I
don't say there is a final decision here, but someone will have to step up and
prove that it can happen differently than it is now.
Should users use the ROS wiki ? I don't think that is the right place. First
of all, we have our own wiki, second, Orocos is definitely a distinct project
from ROS, providing a different experience and way of building applications. I
do see the shortcomings of our website, both in the sense of web design and in
the sense of usability/functionality. An upgrade to Drupal 6.x will help, if
we could combine this with a new 'theme', that would be great. This *is* on
the roadmap for the coming months. Volunteers welcome to speed this up.
2.3.0 is on the doorstep and it addresses most of the issues raised these past
2 months on this list. It's an amazing achievement, and it's much more in
terms of usability than I imagined when we started developing 2.0. Both ROS
and rock are being major contributors to leveraging what is in the 2.x series,
showing us that we won't have to solve everything in the RTT.
As for answering the original question. I agree with Willy that 'out-of-the-
box' software components for hardware are crucial to justify using a real-time
component model in the first place. We are working very hard to make providing
these components as easy as possible, being guided by the complaints of users.
I'm immensely thankful for people like Willy that just 'won't give up'. They
are paving the way for these less certain/determined users yet to come. So
even if these people on the list only contributed complaints and not code,
they did a great job already. Now let's make it for them easier to contribute
to the code part too.
Peter
The place for sharing users component
On Mon, 28 Feb 2011, Peter Soetens wrote:
[...]
> Should everything (user contributed components, best practices, hardware
> abstraction etc) belong in OCL ? When I decided to remove all these pieces
> from OCL in 2.x, it was to make a clear statement: I Am Not Maintaining That
> Code. I will remove any unmaintained code from the releases I make. I
> suggested that people set up their own repositories, since then it's clear
> who's the maintainer of which contributed component, something which is very
> unclear in OCL 1.x, and which I wanted to avoid in 2.x. Although Herman has a
> point that scattered maintainership leads to fragile dependencies, it also
> allows you to point at someone when things break.
I fully support this "responsibility driven" policy: committed maintenance
is worth more than code availability...
[...]
> 2.3.0 is on the doorstep and it addresses most of the issues raised these past
> 2 months on this list. It's an amazing achievement, and it's much more in
> terms of usability than I imagined when we started developing 2.0. Both ROS
> and rock are being major contributors to leveraging what is in the 2.x series,
> showing us that we won't have to solve everything in the RTT.
ROS and rock are two nice examples of "distributions" around Orocos; with
two very different ambitions and target public, but that's fine!
Herman
The place for sharing users component
On Feb 28, 2011, at 14:36 , Herman Bruyninckx wrote:
> On Mon, 28 Feb 2011, Peter Soetens wrote:
>
> [...]
>> Should everything (user contributed components, best practices, hardware
>> abstraction etc) belong in OCL ? When I decided to remove all these pieces
>> from OCL in 2.x, it was to make a clear statement: I Am Not Maintaining That
>> Code. I will remove any unmaintained code from the releases I make. I
>> suggested that people set up their own repositories, since then it's clear
>> who's the maintainer of which contributed component, something which is very
>> unclear in OCL 1.x, and which I wanted to avoid in 2.x. Although Herman has a
>> point that scattered maintainership leads to fragile dependencies, it also
>> allows you to point at someone when things break.
>
> I fully support this "responsibility driven" policy: committed maintenance
> is worth more than code availability...
Ok, but were all those OCL components truly broken/unused? We still use some of them and have been since I started with Orocos. We've also pushed some patches for them overtime. So I don't see the clear "that stuff wasn't maintained" distinction.
Your other point is valid. Scattered maintainership leads to problems. But is there any difference between having
"personal" repositories vs having someone named to maintain certain parts of OCL? You still have someone to point a finger at ... what else do you want?
I would volunteer to maintain the motion-control related components that my customers use (NB not the full suite from OCL v1), along with the unit test cases that we've devised, as part of OCL v2. Well as soon as I can get OCL v2 to cooperate ... :-)
S
The place for sharing users component
On Mon, 28 Feb 2011, S Roderick wrote:
> On Feb 28, 2011, at 14:36 , Herman Bruyninckx wrote:
>
>> On Mon, 28 Feb 2011, Peter Soetens wrote:
>>
>> [...]
>>> Should everything (user contributed components, best practices, hardware
>>> abstraction etc) belong in OCL ? When I decided to remove all these pieces
>>> from OCL in 2.x, it was to make a clear statement: I Am Not Maintaining That
>>> Code. I will remove any unmaintained code from the releases I make. I
>>> suggested that people set up their own repositories, since then it's clear
>>> who's the maintainer of which contributed component, something which is very
>>> unclear in OCL 1.x, and which I wanted to avoid in 2.x. Although Herman has a
>>> point that scattered maintainership leads to fragile dependencies, it also
>>> allows you to point at someone when things break.
>>
>> I fully support this "responsibility driven" policy: committed maintenance
>> is worth more than code availability...
>
> Ok, but were all those OCL components truly broken/unused? We still use
> some of them and have been since I started with Orocos. We've also pushed
> some patches for them overtime. So I don't see the clear "that stuff
> wasn't maintained" distinction.
I am happy that you step forward as the maintainer of the 1.x version of
OCL! :-)
It is clear that they are not maintained in 2.x. At least not for now,
since we have started an internal work group to investigate this issue.
Don't hold your breath though...
> Your other point is valid. Scattered maintainership leads to problems.
> But is there any difference between having "personal" repositories vs
> having someone named to maintain certain parts of OCL? You still have
> someone to point a finger at ... what else do you want?
I fully agree. Modern technology makes distributed ('scattered')
maintainership possible, so let's make use of that opportunity.
> I would volunteer to maintain the motion-control related components that
> my customers use (NB not the full suite from OCL v1), along with the unit
> test cases that we've devised, as part of OCL v2. Well as soon as I can
> get OCL v2 to cooperate ... :-)
Good suggestions! A more concrete discussion can probably start on the
orocos-dev list...
Herman
The place for sharing users component
2011/2/28 Peter Soetens <peter [..] ...>
> On Tuesday 22 February 2011 18:58:24 Willy Lambert wrote:
> > Hi all,
> >
> > I create a new thread because I think it is not good to continue in an
> > other thread
> >
> > As I am beginning to interface my hardware on my robot (especially my CAN
> > bus), I wondered about where I could find others components or publish my
> >
> > code to help others, I asked :
> > > [...]where is the place for such a
> > > component ? is it the job of OCL v2 ?
> >
> > Peter's answer :
> > > No. Create a package repository similar to how a ROS package tree works
> >
> > (ie
> >
> > > identical :-) , and point people to that repository. You can use git or
> >
> > svn,
> >
> > > or whatever you feel most comfortable with.
> >
> > First of all, I am not complaining about a miss, but trying to understand
> > what's the Orocos roadmap about "community integration". I think there is
> a
> > lack and as I love Orocos I can't accept it can't conquer the world :p
> >
> > I totally agree on the fact it is not the job of Orocos developpers to
> > provide such "users components". But what about a common place where
> users
> > provide their components ? For exemple eclipse market place, your
> favorite
> > web browser plugin download page, the ROS wiki ... ?
> > Is it a clear will not to provide such a place or a lack of hands to
> > create,maintain this ?
> >
> > Of course I may publish my SVN (it is not currently interesting but let
> > imagine it is), how a new user may find ready-to-use-components ? I can't
> > even find a link to the huge work DFKI has done from the Orocos web site
> > (and I know what I am searching) !
> >
> > Is it because Orocos is not mature enougth to wish to handle all this
> stuff
> > ?
> > Are you expecting more and more people using Orocos as a ROS stack and
> let
> > user using the ROS wiki to do this ?
>
> Okay... I have no clue where to start responding to this thread, so I'll
> start
> at the top again.
>
> First about user concerns about migrating from 1.x to 2.x to 3.x ? The
> upgrade
> path might seem bumpy from an observers point of view, but lots of the
> issues
> raised come from 'new features' users are testing, instead of the 'old
> code'.
> For example: the BFL typekit has been written in a way that was impossible
> in
> 1.x, ie, the BFL maintainers wrote a 2.x typekit with much more features
> than
> the 1.x version. It were these new features that caused some pain, not 'a
> pure
> upgrade' from 1.x. We did identify one backwards compatibility issue (the
> lacking of the (de)compose functions), which was fixed in 2.2.
> Another example are the CMake macros. These are brand-new, and we encourage
> people to test/use them because they add so much more (in terms of
> usability!)
> than what was possible in 1.x. It's a new feature, it takes a release or
> two
> to stabilize.
> The best we have to support upgrading from 1.x is the earlier mentioned
> wiki
> page "Upgrading from RTT 1.x to 2.0". It does contain all available
> documents,
> which are quite a bunch imho. It does not contain an 'upgrading tutorial'
> as
> Stephen suggested, I admit this is useful, but we're all picking our
> fights.
> The comparison with 1.0 -> 1.6 versus 2.0 -> 2.3 is appallingly unfair. It
> took us almost 5 years to get to the 1.6 release, while less than 6 months
> to
> 2.3. Also, 1.0 was not that different from 0.24.0, as 2.0 is from 1.0.
> We're
> doing frequent major releases to provide updates asap.
> Also, I have personally no plans for looking at/maintaining 3.x. I also
> have
> no idea who would have the guts to write that anyway. I'm sticking to 2.x
> for
> a long time to come [ Insert your Linux kernel analogy here :-) ]
>
agree on what you point and worth to be said, but If someone wants to
debate, please use another thread, it was not the aim of my request at all.
>
> So far for the defense. I consider any user input as the highest truth,
> even
> if they are un- or misinformed. Perception is everything and I'm (and the
> other core developers) so far off from the 'newbie user experience' that we
> have no idea how it looks like from that side. So yes keep bashing, it
> keeps
> us from developing exotic features and _forces_ us to work on improving
> what
> people actually *use*. I would consider silence as a very bad sign as well.
>
Noted !
>
> Should everything (user contributed components, best practices, hardware
> abstraction etc) belong in OCL ? When I decided to remove all these pieces
> from OCL in 2.x, it was to make a clear statement: I Am Not Maintaining
> That
> Code. I will remove any unmaintained code from the releases I make. I
> suggested that people set up their own repositories, since then it's clear
> who's the maintainer of which contributed component, something which is
> very
> unclear in OCL 1.x, and which I wanted to avoid in 2.x. Although Herman has
> a
> point that scattered maintainership leads to fragile dependencies, it also
> allows you to point at someone when things break. When the CAN, Vision or
> Cartesian control components broke in 1.x, who was to blame ? The reality
> shows there that if it's unmaintained, it will also break with all-in-OCL.
> I
> don't say there is a final decision here, but someone will have to step up
> and
> prove that it can happen differently than it is now.
>
As Nico Hochgeschwender suggested, packages could be regurlarly disabled if
not updated. You should read this Peter :
http://gearbox.sourceforge.net/gbx_doc_principles.html
They had a reflection on how to add user code with control and I think it is
worth to read. At least from my very low pratice in Open Source, it is
usefull to me to formalize workflows (I am sure I am not the only one who
need this). Open Source is maybe not top-down managed, but certainly not
developped without workflows. The couterpart of this is that the
functionnality offered by the releases (OCL or Hardware Component Library
for instance) are not guarented over time. I think the key in user
integration is to have a clear defined workflow with no compassion for
disturbing code (don't work=>dustbin). It's as the states of bug tickets.
They live their live, in different state, with different effervecence, but
at the end, you always has the control, for few effort, on what you managed
(on the release point of view).
>
> Should users use the ROS wiki ? I don't think that is the right place.
> First
> of all, we have our own wiki, second, Orocos is definitely a distinct
> project
> from ROS, providing a different experience and way of building
> applications. I
> do see the shortcomings of our website, both in the sense of web design and
> in
> the sense of usability/functionality. An upgrade to Drupal 6.x will help,
> if
> we could combine this with a new 'theme', that would be great. This *is* on
> the roadmap for the coming months. Volunteers welcome to speed this up.
>
Glad you react in this way. I was scattered it doesn't hurt anyone. Please
update the roadmap http://www.orocos.org/wiki/orocos/toolchain/roadmap with
this site updates wishes. It is worth to say publicly where you need help.
An acceptable to my thread question may be : "The glue between user code
will be the wiki, but their code will be in separate repositories", if the
wiki permits it in a very user friendly way, it will be enougth. The wiki
has just to provide as easy way to share repositories and installation
informations.
When a new user arrives, he wants to know what exists, a web site is
enougth. The technical details to obtain their will is not important, as far
as informations where clear and easy to access at the beginning.
I will be a mess of user code, with different qualities. But anyway. Then,
some user participations will mature and an official "Orocos distribution"
will be possible (I just say it is a __possibility__), it will be the way to
distribute officially a "quality" award for user code who reached the Orocos
standards (in term of decoupling, hard-realtime, thread safety, ...).
Because as Herman said, and I agree with it, Orocos is not for playing with
Lego's ! IMO having a mass of "dirty" user code won't affect Orocos's
seriousness since its official releases contains only "nice" code.
A possible request in the future wiki features will be to identify clearly
the state of the project (new, mature, retired) with regular review (manual
or automated) to mark as retired old project.
>
> 2.3.0 is on the doorstep and it addresses most of the issues raised these
> past
> 2 months on this list. It's an amazing achievement, and it's much more in
> terms of usability than I imagined when we started developing 2.0. Both ROS
> and rock are being major contributors to leveraging what is in the 2.x
> series,
> showing us that we won't have to solve everything in the RTT.
>
> As for answering the original question. I agree with Willy that
> 'out-of-the-
> box' software components for hardware are crucial to justify using a
> real-time
> component model in the first place. We are working very hard to make
> providing
> these components as easy as possible, being guided by the complaints of
> users.
> I'm immensely thankful for people like Willy that just 'won't give up'.
> They
> are paving the way for these less certain/determined users yet to come. So
> even if these people on the list only contributed complaints and not code,
> they did a great job already. Now let's make it for them easier to
> contribute
> to the code part too.
>
This kind of user (like I am) are also very gratefull for the heavy and
quick support we receive on our (sometimes) really noobish questions.
Personnaly it is what makes me persevering on Orocos.
>
> Peter
>
The place for sharing users component
On 02/28/2011 08:34 PM, Willy Lambert wrote:
>
>
> 2011/2/28 Peter Soetens <peter [..] ...
> <mailto:peter [..] ...>>
<sni
> I'm immensely thankful for people like Willy that just 'won't give
> up'. They
> are paving the way for these less certain/determined users yet to
> come. So
> even if these people on the list only contributed complaints and not
> code,
> they did a great job already. Now let's make it for them easier to
> contribute
> to the code part too.
>
>
> This kind of user (like I am) are also very gratefull for the heavy and
> quick support we receive on our (sometimes) really noobish questions.
> Personnaly it is what makes me persevering on Orocos.
Just wanted to +1 this. Orocos isn't easy to get off the ground with,
and I've always received solid support from this mailing list and that
has been a _very strong_ reason to continue using orocos on new projects.
Cheers,
Sagar
The place for sharing users component
On Mon, 28 Feb 2011, Sagar Behere wrote:
> On 02/28/2011 08:34 PM, Willy Lambert wrote:
>>
>>
>> 2011/2/28 Peter Soetens <peter [..] ...
>> <mailto:peter [..] ...>>
>
> <sni
>
>> I'm immensely thankful for people like Willy that just 'won't give
>> up'. They
>> are paving the way for these less certain/determined users yet to
>> come. So
>> even if these people on the list only contributed complaints and not
>> code,
>> they did a great job already. Now let's make it for them easier to
>> contribute
>> to the code part too.
>>
>>
>> This kind of user (like I am) are also very gratefull for the heavy and
>> quick support we receive on our (sometimes) really noobish questions.
>> Personnaly it is what makes me persevering on Orocos.
>
> Just wanted to +1 this. Orocos isn't easy to get off the ground with,
> and I've always received solid support from this mailing list and that
> has been a _very strong_ reason to continue using orocos on new projects.
Thanks for sharing this compliment! :-)
> Cheers,
> Sagar
Herman
The place for sharing users component
On Mon, 28 Feb 2011, Willy Lambert wrote:
[...]
> As Nico Hochgeschwender suggested, packages could be regurlarly disabled if not
> updated. You should read this Peter :
> http://gearbox.sourceforge.net/gbx_doc_principles.html
> They had a reflection on how to add user code with control and I think it is worth
> to read. At least from my very low pratice in Open Source, it is usefull to me to
> formalize workflows (I am sure I am not the only one who need this). Open Source is
> maybe not top-down managed, but certainly not developped without workflows.
Workflows are a good idea. But their implementation _also_ requires
committed people, so in the end this does not change thing fundamentally...
> The
> couterpart of this is that the functionnality offered by the releases (OCL or
> Hardware Component Library for instance) are not guarented over time. I think the
> key in user integration is to have a clear defined workflow with no compassion for
> disturbing code (don't work=>dustbin).
You point your finger to one (but only one!) of the responsibilities of a
committed maintainer: testing and "dustbinning"... But again, this
_pre-assumes_ a committed maintainer...
> It's as the states of bug tickets. They live
> their live, in different state, with different effervecence, but at the end, you
> always has the control, for few effort, on what you managed (on the release point of
> view).
>
> Should users use the ROS wiki ? I don't think that is the right place.
> First
> of all, we have our own wiki, second, Orocos is definitely a distinct
> project
> from ROS, providing a different experience and way of building
> applications. I
> do see the shortcomings of our website, both in the sense of web design
> and in
> the sense of usability/functionality. An upgrade to Drupal 6.x will
> help, if
> we could combine this with a new 'theme', that would be great. This *is*
> on
> the roadmap for the coming months. Volunteers welcome to speed this up.
>
> Glad you react in this way. I was scattered it doesn't hurt anyone. Please update
> the roadmap http://www.orocos.org/wiki/orocos/toolchain/roadmap with this site
> updates wishes. It is worth to say publicly where you need help.
> An acceptable to my thread question may be : "The glue between user code will be the
> wiki, but their code will be in separate repositories", if the wiki permits it in a
> very user friendly way, it will be enougth. The wiki has just to provide as easy way
> to share repositories and installation informations.
>
> When a new user arrives, he wants to know what exists, a web site is enougth.
No... One should never, _never_, judge a project on its web site. _The_
number one evaluation criterium for the vitality and promise of a project
is its developers mailinglist.
> The
> technical details to obtain their will is not important, as far as informations
> where clear and easy to access at the beginning.
>
> I will be a mess of user code, with different qualities. But anyway. Then, some user
> participations will mature and an official "Orocos distribution" will be possible (I
> just say it is a __possibility__), it will be the way to distribute officially a
> "quality" award for user code who reached the Orocos standards (in term of
> decoupling, hard-realtime, thread safety, ...). Because as Herman said, and I agree
> with it, Orocos is not for playing with Lego's ! IMO having a mass of "dirty" user
> code won't affect Orocos's seriousness since its official releases contains only
> "nice" code.
The Linux kernel also has its 'staging kernel' for these purposes:
<http://www.kroah.com/log/linux/linux-staging-update.html>
But, the first thing you should read there too is the following:
"The staging tree is not a place to dump code and run away, hoping that
someone else will to the cleanup work for you. While there are developers
available and willing to do this kind of work, you need to get them to
agree to "babysit" the code in order for it to be accepted."
> A possible request in the future wiki features will be to identify clearly the state
> of the project (new, mature, retired) with regular review (manual or automated) to
> mark as retired old project.
Again, this is a serious maintenance effort. And guess what we currently
lack most...? Indeed, committed maintainers :-)
> 2.3.0 is on the doorstep and it addresses most of the issues raised
> these past
> 2 months on this list. It's an amazing achievement, and it's much more
> in
> terms of usability than I imagined when we started developing 2.0. Both
> ROS
> and rock are being major contributors to leveraging what is in the 2.x
> series,
> showing us that we won't have to solve everything in the RTT.
>
> As for answering the original question. I agree with Willy that
> 'out-of-the-
> box' software components for hardware are crucial to justify using a
> real-time
> component model in the first place. We are working very hard to make
> providing
> these components as easy as possible, being guided by the complaints of
> users.
> I'm immensely thankful for people like Willy that just 'won't give up'.
> They
> are paving the way for these less certain/determined users yet to come.
> So
> even if these people on the list only contributed complaints and not
> code,
> they did a great job already. Now let's make it for them easier to
> contribute
> to the code part too.
>
> This kind of user (like I am) are also very gratefull for the heavy and quick
> support we receive on our (sometimes) really noobish questions. Personnaly it is
> what makes me persevering on Orocos.
>
>
> Peter
Herman
The place for sharing users component
On 01/03/11 05:03, Herman Bruyninckx wrote:
> On Mon, 28 Feb 2011, Willy Lambert wrote:
>
> [...]
>> As Nico Hochgeschwender suggested, packages could be regurlarly
>> disabled if not
>> updated. You should read this Peter :
>> http://gearbox.sourceforge.net/gbx_doc_principles.html
>> They had a reflection on how to add user code with control and I think
>> it is worth
>> to read. At least from my very low pratice in Open Source, it is
>> usefull to me to
>> formalize workflows (I am sure I am not the only one who need this).
>> Open Source is
>> maybe not top-down managed, but certainly not developped without
>> workflows.
>
> Workflows are a good idea. But their implementation _also_ requires
> committed people, so in the end this does not change thing fundamentally...
To make sure this is clear, it's not just committed project runners that
are needed, either. Gearbox had some good ideas, but ultimately the
project was a failure because it never attracted committed
_contributors_. Except for one submission, noone other than us put any
code in. That one submission hasn't responded since the peer review told
him he had to write documentation before his code would be accepted -
either he's been scared off by the requirements or he just doesn't have
time. I think that the reason noone else ever submitted anything is
because of this level of work required to produce acceptable code (the
Gearbox concept goal was "high-quality, peer-reviewed code"). ROS, on
the other hand, took the approach of "any code is good code" and a
really simple work flow, and they've achieved massive success in getting
and keeping contributors.
So defining a work flow is good, but you need to make sure it doesn't
scare _new_ people off from contributing to and committing to the project.
Geoff
The place for sharing users component
2011/3/1 Geoffrey Biggs <geoffrey [dot] biggs [..] ....j
> On 01/03/11 05:03, Herman Bruyninckx wrote:
> > On Mon, 28 Feb 2011, Willy Lambert wrote:
> >
> > [...]
> >> As Nico Hochgeschwender suggested, packages could be regurlarly
> >> disabled if not
> >> updated. You should read this Peter :
> >> http://gearbox.sourceforge.net/gbx_doc_principles.html
> >> They had a reflection on how to add user code with control and I think
> >> it is worth
> >> to read. At least from my very low pratice in Open Source, it is
> >> usefull to me to
> >> formalize workflows (I am sure I am not the only one who need this).
> >> Open Source is
> >> maybe not top-down managed, but certainly not developped without
> >> workflows.
> >
> > Workflows are a good idea. But their implementation _also_ requires
> > committed people, so in the end this does not change thing
> fundamentally...
>
> To make sure this is clear, it's not just committed project runners that
> are needed, either. Gearbox had some good ideas, but ultimately the
> project was a failure because it never attracted committed
> _contributors_. Except for one submission, noone other than us put any
> code in. That one submission hasn't responded since the peer review told
> him he had to write documentation before his code would be accepted -
> either he's been scared off by the requirements or he just doesn't have
> time. I think that the reason noone else ever submitted anything is
> because of this level of work required to produce acceptable code (the
> Gearbox concept goal was "high-quality, peer-reviewed code"). ROS, on
> the other hand, took the approach of "any code is good code" and a
> really simple work flow, and they've achieved massive success in getting
> and keeping contributors.
>
> So defining a work flow is good, but you need to make sure it doesn't
> scare _new_ people off from contributing to and committing to the project.
>
>
Agree, thanks for balancing.
> Geoff
> --
> Orocos-Users mailing list
> Orocos-Users [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>
The place for sharing users component
2011/2/28 Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...>
> On Mon, 28 Feb 2011, Willy Lambert wrote:
>
> [...]
>
> As Nico Hochgeschwender suggested, packages could be regurlarly disabled
>> if not
>> updated. You should read this Peter :
>> http://gearbox.sourceforge.net/gbx_doc_principles.html
>> They had a reflection on how to add user code with control and I think it
>> is worth
>> to read. At least from my very low pratice in Open Source, it is usefull
>> to me to
>> formalize workflows (I am sure I am not the only one who need this). Open
>> Source is
>> maybe not top-down managed, but certainly not developped without
>> workflows.
>>
>
> Workflows are a good idea. But their implementation _also_ requires
> committed people, so in the end this does not change thing fundamentally...
>
>
> The
>> couterpart of this is that the functionnality offered by the releases (OCL
>> or
>> Hardware Component Library for instance) are not guarented over time. I
>> think the
>> key in user integration is to have a clear defined workflow with no
>> compassion for
>> disturbing code (don't work=>dustbin).
>>
>
> You point your finger to one (but only one!) of the responsibilities of a
> committed maintainer: testing and "dustbinning"... But again, this
> _pre-assumes_ a committed maintainer...
>
>
> It's as the states of bug tickets. They live
>> their live, in different state, with different effervecence, but at the
>> end, you
>> always has the control, for few effort, on what you managed (on the
>> release point of
>> view).
>>
>> Should users use the ROS wiki ? I don't think that is the right
>> place.
>> First
>> of all, we have our own wiki, second, Orocos is definitely a distinct
>> project
>> from ROS, providing a different experience and way of building
>> applications. I
>> do see the shortcomings of our website, both in the sense of web
>> design
>> and in
>> the sense of usability/functionality. An upgrade to Drupal 6.x will
>> help, if
>> we could combine this with a new 'theme', that would be great. This
>> *is*
>> on
>> the roadmap for the coming months. Volunteers welcome to speed this
>> up.
>>
>> Glad you react in this way. I was scattered it doesn't hurt anyone. Please
>> update
>> the roadmap http://www.orocos.org/wiki/orocos/toolchain/roadmap with this
>> site
>> updates wishes. It is worth to say publicly where you need help.
>> An acceptable to my thread question may be : "The glue between user code
>> will be the
>> wiki, but their code will be in separate repositories", if the wiki
>> permits it in a
>> very user friendly way, it will be enougth. The wiki has just to provide
>> as easy way
>> to share repositories and installation informations.
>>
>> When a new user arrives, he wants to know what exists, a web site is
>> enougth.
>>
>
> No... One should never, _never_, judge a project on its web site. _The_
> number one evaluation criterium for the vitality and promise of a project
> is its developers mailinglist.
>
>
> The
>> technical details to obtain their will is not important, as far as
>> informations
>> where clear and easy to access at the beginning.
>>
>> I will be a mess of user code, with different qualities. But anyway. Then,
>> some user
>> participations will mature and an official "Orocos distribution" will be
>> possible (I
>> just say it is a __possibility__), it will be the way to distribute
>> officially a
>> "quality" award for user code who reached the Orocos standards (in term of
>> decoupling, hard-realtime, thread safety, ...). Because as Herman said,
>> and I agree
>> with it, Orocos is not for playing with Lego's ! IMO having a mass of
>> "dirty" user
>> code won't affect Orocos's seriousness since its official releases
>> contains only
>> "nice" code.
>>
>
> The Linux kernel also has its 'staging kernel' for these purposes:
> <http://www.kroah.com/log/linux/linux-staging-update.html>
> But, the first thing you should read there too is the following:
> "The staging tree is not a place to dump code and run away, hoping that
> someone else will to the cleanup work for you. While there are developers
> available and willing to do this kind of work, you need to get them to
> agree to "babysit" the code in order for it to be accepted."
If an Official Orocos wiki is the place to receive the user participation,
it's not the same, linux staging is a "linux" maintained tree (that's what
OCL v1.x was), Orocos wiki will be a list of repositories.
>
>
> A possible request in the future wiki features will be to identify clearly
>> the state
>> of the project (new, mature, retired) with regular review (manual or
>> automated) to
>> mark as retired old project.
>>
>
> Again, this is a serious maintenance effort. And guess what we currently
> lack most...? Indeed, committed maintainers :-)
>
>
> 2.3.0 is on the doorstep and it addresses most of the issues raised
>> these past
>> 2 months on this list. It's an amazing achievement, and it's much
>> more
>> in
>> terms of usability than I imagined when we started developing 2.0.
>> Both
>> ROS
>> and rock are being major contributors to leveraging what is in the
>> 2.x
>> series,
>> showing us that we won't have to solve everything in the RTT.
>>
>> As for answering the original question. I agree with Willy that
>> 'out-of-the-
>> box' software components for hardware are crucial to justify using a
>> real-time
>> component model in the first place. We are working very hard to make
>> providing
>> these components as easy as possible, being guided by the complaints
>> of
>> users.
>> I'm immensely thankful for people like Willy that just 'won't give
>> up'.
>> They
>> are paving the way for these less certain/determined users yet to
>> come.
>> So
>> even if these people on the list only contributed complaints and not
>> code,
>> they did a great job already. Now let's make it for them easier to
>> contribute
>> to the code part too.
>>
>> This kind of user (like I am) are also very gratefull for the heavy and
>> quick
>> support we receive on our (sometimes) really noobish questions. Personnaly
>> it is
>> what makes me persevering on Orocos.
>>
>>
>> Peter
>>
>
> Herman
The place for sharing users component
On Mon, 28 Feb 2011, Willy Lambert wrote:
>
> 2011/2/28 Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...>
> On Mon, 28 Feb 2011, Willy Lambert wrote:
>
> [...]
> As Nico Hochgeschwender suggested, packages could be
> regurlarly disabled if not
> updated. You should read this Peter :
> http://gearbox.sourceforge.net/gbx_doc_principles.html
> They had a reflection on how to add user code with control
> and I think it is worth
> to read. At least from my very low pratice in Open Source,
> it is usefull to me to
> formalize workflows (I am sure I am not the only one who
> need this). Open Source is
> maybe not top-down managed, but certainly not developped
> without workflows.
>
>
> Workflows are a good idea. But their implementation _also_ requires
> committed people, so in the end this does not change thing fundamentally...
>
> The
> couterpart of this is that the functionnality offered by the
> releases (OCL or
> Hardware Component Library for instance) are not guarented over
> time. I think the
> key in user integration is to have a clear defined workflow with
> no compassion for
> disturbing code (don't work=>dustbin).
>
>
> You point your finger to one (but only one!) of the responsibilities of a
> committed maintainer: testing and "dustbinning"... But again, this
> _pre-assumes_ a committed maintainer...
>
>
> It's as the states of bug tickets. They live
> their live, in different state, with different effervecence, but
> at the end, you
> always has the control, for few effort, on what you managed (on
> the release point of
> view).
>
> Should users use the ROS wiki ? I don't think that is the
> right place.
> First
> of all, we have our own wiki, second, Orocos is definitely a
> distinct
> project
> from ROS, providing a different experience and way of
> building
> applications. I
> do see the shortcomings of our website, both in the sense of
> web design
> and in
> the sense of usability/functionality. An upgrade to Drupal
> 6.x will
> help, if
> we could combine this with a new 'theme', that would be
> great. This *is*
> on
> the roadmap for the coming months. Volunteers welcome to
> speed this up.
>
> Glad you react in this way. I was scattered it doesn't hurt
> anyone. Please update
> the roadmap http://www.orocos.org/wiki/orocos/toolchain/roadmap
> with this site
> updates wishes. It is worth to say publicly where you need help.
> An acceptable to my thread question may be : "The glue between
> user code will be the
> wiki, but their code will be in separate repositories", if the
> wiki permits it in a
> very user friendly way, it will be enougth. The wiki has just to
> provide as easy way
> to share repositories and installation informations.
>
> When a new user arrives, he wants to know what exists, a web site
> is enougth.
>
>
> No... One should never, _never_, judge a project on its web site. _The_
> number one evaluation criterium for the vitality and promise of a project
> is its developers mailinglist.
>
> The
> technical details to obtain their will is not important, as far as
> informations
> where clear and easy to access at the beginning.
>
> I will be a mess of user code, with different qualities. But
> anyway. Then, some user
> participations will mature and an official "Orocos distribution"
> will be possible (I
> just say it is a __possibility__), it will be the way to
> distribute officially a
> "quality" award for user code who reached the Orocos standards (in
> term of
> decoupling, hard-realtime, thread safety, ...). Because as Herman
> said, and I agree
> with it, Orocos is not for playing with Lego's ! IMO having a mass
> of "dirty" user
> code won't affect Orocos's seriousness since its official releases
> contains only
> "nice" code.
>
>
> The Linux kernel also has its 'staging kernel' for these purposes:
> <http://www.kroah.com/log/linux/linux-staging-update.html>
> But, the first thing you should read there too is the following:
> "The staging tree is not a place to dump code and run away, hoping that
> someone else will to the cleanup work for you. While there are developers
> available and willing to do this kind of work, you need to get them to
> agree to "babysit" the code in order for it to be accepted."
>
>
> If an Official Orocos wiki is the place to receive the user participation, it's not
> the same, linux staging is a "linux" maintained tree (that's what OCL v1.x was),
> Orocos wiki will be a list of repositories.
>
You can choose to use whatever kind of description you like, or whatever
workflow, or whatever website support, but _the_ essential bottleneck
remains: committed maintainership... It's really just that simple.
Herman
The place for sharing users component
On Monday 28 February 2011 21:03:25 Herman Bruyninckx wrote:
> On Mon, 28 Feb 2011, Willy Lambert wrote:
>
> [...]
>
> > As Nico Hochgeschwender suggested, packages could be regurlarly disabled
> > if not updated. You should read this Peter :
> > http://gearbox.sourceforge.net/gbx_doc_principles.html
> > They had a reflection on how to add user code with control and I think
> > it is worth to read. At least from my very low pratice in Open Source,
> > it is usefull to me to formalize workflows (I am sure I am not the only
> > one who need this). Open Source is maybe not top-down managed, but
> > certainly not developped without workflows.
>
> Workflows are a good idea. But their implementation _also_ requires
> committed people, so in the end this does not change thing fundamentally...
>
> > The
> > couterpart of this is that the functionnality offered by the releases
> > (OCL or Hardware Component Library for instance) are not guarented over
> > time. I think the key in user integration is to have a clear defined
> > workflow with no compassion for disturbing code (don't work=>dustbin).
>
> You point your finger to one (but only one!) of the responsibilities of a
> committed maintainer: testing and "dustbinning"... But again, this
> _pre-assumes_ a committed maintainer...
>
> > It's as the states of bug tickets. They live
> > their live, in different state, with different effervecence, but at the
> > end, you always has the control, for few effort, on what you managed
> > (on the release point of view).
> >
> > Should users use the ROS wiki ? I don't think that is the
> > right place. First
> > of all, we have our own wiki, second, Orocos is definitely a
> > distinct project
> > from ROS, providing a different experience and way of
> > building
> > applications. I
> > do see the shortcomings of our website, both in the sense of
> > web design and in
> > the sense of usability/functionality. An upgrade to Drupal
> > 6.x will
> > help, if
> > we could combine this with a new 'theme', that would be
> > great. This *is* on
> > the roadmap for the coming months. Volunteers welcome to
> > speed this up.
> >
> > Glad you react in this way. I was scattered it doesn't hurt anyone.
> > Please update the roadmap
> > http://www.orocos.org/wiki/orocos/toolchain/roadmap with this site
> > updates wishes. It is worth to say publicly where you need help. An
> > acceptable to my thread question may be : "The glue between user code
> > will be the wiki, but their code will be in separate repositories", if
> > the wiki permits it in a very user friendly way, it will be enougth.
> > The wiki has just to provide as easy way to share repositories and
> > installation informations.
> >
> > When a new user arrives, he wants to know what exists, a web site is
> > enougth.
>
> No... One should never, _never_, judge a project on its web site. _The_
> number one evaluation criterium for the vitality and promise of a project
> is its developers mailinglist.
Well, that's maybe your measure for vitality, but new users first see the
website. And only if it's attractive enough or shows enough new information
they will maybe go on and look for a link where they can subscribe to the
mailinglist.
> > The
> > technical details to obtain their will is not important, as far as
> > informations where clear and easy to access at the beginning.
> >
> > I will be a mess of user code, with different qualities. But anyway.
> > Then, some user participations will mature and an official "Orocos
> > distribution" will be possible (I just say it is a __possibility__), it
> > will be the way to distribute officially a "quality" award for user
> > code who reached the Orocos standards (in term of decoupling,
> > hard-realtime, thread safety, ...). Because as Herman said, and I agree
> > with it, Orocos is not for playing with Lego's ! IMO having a mass of
> > "dirty" user code won't affect Orocos's seriousness since its official
> > releases contains only "nice" code.
>
> The Linux kernel also has its 'staging kernel' for these purposes:
> <http://www.kroah.com/log/linux/linux-staging-update.html>
> But, the first thing you should read there too is the following:
> "The staging tree is not a place to dump code and run away, hoping that
> someone else will to the cleanup work for you. While there are developers
> available and willing to do this kind of work, you need to get them to
> agree to "babysit" the code in order for it to be accepted."
>
> > A possible request in the future wiki features will be to identify
> > clearly the state of the project (new, mature, retired) with regular
> > review (manual or automated) to mark as retired old project.
>
> Again, this is a serious maintenance effort. And guess what we currently
> lack most...? Indeed, committed maintainers :-)
>
> > 2.3.0 is on the doorstep and it addresses most of the issues
> > raised
> > these past
> > 2 months on this list. It's an amazing achievement, and it's
> > much more in
> > terms of usability than I imagined when we started
> > developing 2.0. Both ROS
> > and rock are being major contributors to leveraging what is
> > in the 2.x series,
> > showing us that we won't have to solve everything in the
> > RTT.
> >
> > As for answering the original question. I agree with Willy
> > that
> > 'out-of-the-
> > box' software components for hardware are crucial to justify
> > using a real-time
> > component model in the first place. We are working very hard
> > to make providing
> > these components as easy as possible, being guided by the
> > complaints of users.
> > I'm immensely thankful for people like Willy that just
> > 'won't give up'. They
> > are paving the way for these less certain/determined users
> > yet to come. So
> > even if these people on the list only contributed complaints
> > and not code,
> > they did a great job already. Now let's make it for them
> > easier to
> > contribute
> > to the code part too.
> >
> > This kind of user (like I am) are also very gratefull for the heavy and
> > quick support we receive on our (sometimes) really noobish questions.
> > Personnaly it is what makes me persevering on Orocos.
> >
> >
> > Peter
>
> Herman
Ruben
The place for sharing users component
On Mon, 28 Feb 2011, Ruben Smits wrote:
> On Monday 28 February 2011 21:03:25 Herman Bruyninckx wrote:
>> On Mon, 28 Feb 2011, Willy Lambert wrote:
[...]
>>> When a new user arrives, he wants to know what exists, a web site is
>>> enougth.
>>
>> No... One should never, _never_, judge a project on its web site. _The_
>> number one evaluation criterium for the vitality and promise of a project
>> is its developers mailinglist.
>
> Well, that's maybe your measure for vitality, but new users first see the
> website. And only if it's attractive enough or shows enough new information
> they will maybe go on and look for a link where they can subscribe to the
> mailinglist.
Subscription comes _later_! Being able to _browse_ the mailinglist is the
primary requirement. And our dual mailing list/forum architecture on the
_website_ serves this purpose _very_ well :-) It was one of the two "best
decisions" Peter and I took (quite) some years ago...
(The second "best decision" is a question in the "Know your Orocos
history!" quizz, to be released when all current maintainers will have
nothing better on their hands... :-) )
Herman
The place for sharing users component
On Feb 28, 2011, at 15:18 , Herman Bruyninckx wrote:
> On Mon, 28 Feb 2011, Ruben Smits wrote:
>
>> On Monday 28 February 2011 21:03:25 Herman Bruyninckx wrote:
>>> On Mon, 28 Feb 2011, Willy Lambert wrote:
> [...]
>>>> When a new user arrives, he wants to know what exists, a web site is
>>>> enougth.
>>>
>>> No... One should never, _never_, judge a project on its web site. _The_
>>> number one evaluation criterium for the vitality and promise of a project
>>> is its developers mailinglist.
>>
>> Well, that's maybe your measure for vitality, but new users first see the
>> website. And only if it's attractive enough or shows enough new information
>> they will maybe go on and look for a link where they can subscribe to the
>> mailinglist.
>
> Subscription comes _later_! Being able to _browse_ the mailinglist is the
> primary requirement. And our dual mailing list/forum architecture on the
> _website_ serves this purpose _very_ well :-) It was one of the two "best
> decisions" Peter and I took (quite) some years ago...
You both have a point. But I would argue that a good ML alone isn't enough. Having a good website with solid examples and tutorials reduces the load on the ML, so freeing up maintainers/developers to do actual work. Qt is a wonderful example of this. I've seldom used the ML because the online examples and API doc's have been so good.
One without the other just limits a project ...
S
The place for sharing users component
On Mon, 28 Feb 2011, S Roderick wrote:
> On Feb 28, 2011, at 15:18 , Herman Bruyninckx wrote:
>
>> On Mon, 28 Feb 2011, Ruben Smits wrote:
>>
>>> On Monday 28 February 2011 21:03:25 Herman Bruyninckx wrote:
>>>> On Mon, 28 Feb 2011, Willy Lambert wrote:
>> [...]
>>>>> When a new user arrives, he wants to know what exists, a web site is
>>>>> enougth.
>>>>
>>>> No... One should never, _never_, judge a project on its web site. _The_
>>>> number one evaluation criterium for the vitality and promise of a project
>>>> is its developers mailinglist.
>>>
>>> Well, that's maybe your measure for vitality, but new users first see the
>>> website. And only if it's attractive enough or shows enough new information
>>> they will maybe go on and look for a link where they can subscribe to the
>>> mailinglist.
>>
>> Subscription comes _later_! Being able to _browse_ the mailinglist is the
>> primary requirement. And our dual mailing list/forum architecture on the
>> _website_ serves this purpose _very_ well :-) It was one of the two "best
>> decisions" Peter and I took (quite) some years ago...
>
> You both have a point. But I would argue that a good ML alone isn't enough. Having a good website with solid examples and tutorials reduces the load on the ML, so freeing up maintainers/developers to do actual work. Qt is a wonderful example of this. I've seldom used the ML because the online examples and API doc's have been so good.
>
> One without the other just limits a project ...
Sure... But you name one of those projects that were (until very recently
at least) copiously funded by a mega corporation, in casu Nokia. They have
dedicated professional maintainers for those things...
> S
Herman
The place for sharing users component
On Tue, 22 Feb 2011, Willy Lambert wrote:
> Hi all,
>
> I create a new thread because I think it is not good to continue in an other
> thread
>
> As I am beginning to interface my hardware on my robot (especially my CAN bus),
> I wondered about where I could find others components or publish my code to help
> others, I asked :
> > [...]where is the place for such a
> > component ? is it the job of OCL v2 ?
>
> Peter's answer :
> > No. Create a package repository similar to how a ROS package tree works (ie
> > identical :-) , and point people to that repository. You can use git or svn,
> > or whatever you feel most comfortable with.
I do not agree with Peter completely: the original idea of OCL (6-7 years
ago) was for it to become the place to collect "best practice" solutions,
and only those. Because of a lack of insight in what "best practice" really
means, OCL ended up in becoming the "wast basket" of the Orocos project,
that is, the branch were everything got dumped that did not nicely fit in
the core parts of the project's source tree :-(
I think it is high time to resurrect OCL as "the" place for users to go an
look for proven, documented, best practice systems. I think this is to some
extent what you are also hinting at, isn't it?
In addition to that, Peter's suggestion for the "ROS like" approach of
various, unreviewed code repositories also makes sense. But the practice
proves that this becomes a chaotic bunch of bits and pieces without any
quality control or guarantee. I think we should do better with Orocos,
since there is a major difference between ROS and Orocos: we want to be the
best possible solution in a small niche of robotics.
> First of all, I am not complaining about a miss, but trying to understand what's
> the Orocos roadmap about "community integration". I think there is a lack and as
> I love Orocos I can't accept it can't conquer the world :p
It should conquer only a small piece of the world, but conquer that niche
without leaving any room for competition :-)
> I totally agree on the fact it is not the job of Orocos developpers to provide
> such "users components".
It _is_, but then only for a small set of proven, best practice components!
> But what about a common place where users provide their
> components ? For exemple eclipse market place, your favorite web browser plugin
> download page, the ROS wiki ... ?
> Is it a clear will not to provide such a place or a lack of hands to
> create,maintain this ?
> Of course I may publish my SVN (it is not currently interesting but let imagine
> it is), how a new user may find ready-to-use-components ? I can't even find a
> link to the huge work DFKI has done from the Orocos web site (and I know what I
> am searching) !
>
> Is it because Orocos is not mature enougth to wish to handle all this stuff ?
It definitely was not, until quite recently. But currently, as proven by
the activity on this mailing list and its developers' companion
"orocos-dev", the project has reached a much more mature status, with a
surprisingly broad group of dedicated people. So, I think that time might
have come to try to resurrect the original OCL idea again...
Accepting a design into that "best practices" repository should be the
result of a more or less structured and 'standardized' evaluation process,
with extensive possibility for community inputs.
I see one particular "best practice" design as being almost mature enough
to become the first OCL entry: the "motion control stack" that many of us
are already using in one way or another on their robots, consisting of a
HAL, a joint space control, a Cartesian control, and a iTaSC task
specification coordinator on top.
> Are you expecting more and more people using Orocos as a ROS stack and
> let user using the ROS wiki to do this ?
>
Herman
The place for sharing users component
On Feb 22, 2011, at 15:29 , Herman Bruyninckx wrote:
> On Tue, 22 Feb 2011, Willy Lambert wrote:
>
>> Hi all,
>>
>> I create a new thread because I think it is not good to continue in an other
>> thread
>>
>> As I am beginning to interface my hardware on my robot (especially my CAN bus),
>> I wondered about where I could find others components or publish my code to help
>> others, I asked :
>>> [...]where is the place for such a
>>> component ? is it the job of OCL v2 ?
>>
>> Peter's answer :
>>> No. Create a package repository similar to how a ROS package tree works (ie
>>> identical :-) , and point people to that repository. You can use git or svn,
>>> or whatever you feel most comfortable with.
>
> I do not agree with Peter completely: the original idea of OCL (6-7 years
> ago) was for it to become the place to collect "best practice" solutions,
> and only those. Because of a lack of insight in what "best practice" really
> means, OCL ended up in becoming the "wast basket" of the Orocos project,
> that is, the branch were everything got dumped that did not nicely fit in
> the core parts of the project's source tree :-(
>
> I think it is high time to resurrect OCL as "the" place for users to go an
> look for proven, documented, best practice systems. I think this is to some
> extent what you are also hinting at, isn't it?
I'm with Herman on this one. Orocos' biggest fault is that it is developer-centric, not user-centric. IMHO trimming down OCL was an example of this. The project is wonderful for developers. It is tough to be a user in this ecosystem.
> In addition to that, Peter's suggestion for the "ROS like" approach of
> various, unreviewed code repositories also makes sense. But the practice
> proves that this becomes a chaotic bunch of bits and pieces without any
> quality control or guarantee. I think we should do better with Orocos,
> since there is a major difference between ROS and Orocos: we want to be the
> best possible solution in a small niche of robotics.
I agree that there is, and should be, a distinction between best practice examples, and user-contributed code. But we also need examples of both.
>> First of all, I am not complaining about a miss, but trying to understand what's
>> the Orocos roadmap about "community integration". I think there is a lack and as
>> I love Orocos I can't accept it can't conquer the world :p
>
> It should conquer only a small piece of the world, but conquer that niche
> without leaving any room for competition :-)
>
>> I totally agree on the fact it is not the job of Orocos developpers to provide
>> such "users components".
>
> It _is_, but then only for a small set of proven, best practice components!
It absolutely is the developer's responsibility - if you want the project to last. Developers need to provide a framework within which new users can rapidly get used to a system. Without fostering your user base, projects die. New users need solid system examples of how to use Orocos in a system. No such example exists. This leaves new users foundering without direction, leading them to seek alternatives. I know groups who've already done this.
>> But what about a common place where users provide their
>> components ? For exemple eclipse market place, your favorite web browser plugin
>> download page, the ROS wiki ... ?
>> Is it a clear will not to provide such a place or a lack of hands to
>> create,maintain this ?
>
>> Of course I may publish my SVN (it is not currently interesting but let imagine
>> it is), how a new user may find ready-to-use-components ? I can't even find a
>> link to the huge work DFKI has done from the Orocos web site (and I know what I
>> am searching) !
>>
>> Is it because Orocos is not mature enougth to wish to handle all this stuff ?
>
> It definitely was not, until quite recently. But currently, as proven by
> the activity on this mailing list and its developers' companion
> "orocos-dev", the project has reached a much more mature status, with a
> surprisingly broad group of dedicated people. So, I think that time might
> have come to try to resurrect the original OCL idea again...
>
> Accepting a design into that "best practices" repository should be the
> result of a more or less structured and 'standardized' evaluation process,
> with extensive possibility for community inputs.
See [1] below re structuring the contribution process. Some ideas under "improvements" in Section 3.
> I see one particular "best practice" design as being almost mature enough
> to become the first OCL entry: the "motion control stack" that many of us
> are already using in one way or another on their robots, consisting of a
> HAL, a joint space control, a Cartesian control, and a iTaSC task
> specification coordinator on top.
Is there an example of this system, or any part of its layers, currently available to the public?
In a similar vein, I created Roadmap and Contributing pages for the Orocos Toolchain. I felt that these were two critical missing resources, along with "system examples" (still working that, continuing to fight with v2). These are available on the toolchain wiki page [8], but not the top-level Toolchain page [9]. Once reviewed, they can be added at the top.
I think good examples of Roadmaps from other projects are [3] (though it doesn't need the dev process bit at top - that belongs elsewhere), and [4] (though awfully brief). Both give an idea of where things are going. We didn't have that, and still don't for the other elements of the toolchain (others have to fill this in ... hint hint ...).
Contributing is about helping users become contributors (see Recommendations, Section 1, [1]). A decent example is [5], or one with too much detail [6]. I pulled details from previous discussions [10] and [11]. This page needs review. I took a best guess - things are bound to be wrong.
Nice example for describing how to submit patches [7]. This definitely needs work on our site.
I think the Rock project [12] has done a good job of showing us up re system examples and help, and being more user-centric. I'd actually consider using that, if it wasn't using Ruby ... sorry Sylvain, nothing but bad experiences with it. :-(
Thoughts anyone ....?
S
[1] http://www.cyber-anthro.com/beta-an-exploration-of-fedora’s-online-open-source-development-community/
[2] http://blogs.gnome.org/bolsh/2011/02/07/drawing-up-a-roadmap/
[3] http://trac.wxwidgets.org/wiki/Roadmap
[4] http://www.openscenegraph.org/projects/osg/wiki/Support/Plans
[5] http://www.cmake.org/cmake/project/getinvolved.html
[6] http://wiki.laptop.org/go/Developers
[7] http://trac.wxwidgets.org/wiki/HowToSubmitPatches
[8] http://www.orocos.org/wiki/orocos/toolchain/
[9] http://www.orocos.org/toolchain
[10] http://www.orocos.org/forum/rtt/rtt-dev/version-management-and-branches-...
[11] http://www.orocos.org/forum/rtt/rtt-dev/branch-names-updates
[12] http://rock-robotics.org/
The place for sharing users component
On Wed, 23 Feb 2011, S Roderick wrote:
> On Feb 22, 2011, at 15:29 , Herman Bruyninckx wrote:
>
>> On Tue, 22 Feb 2011, Willy Lambert wrote:
>>
>>> Hi all,
>>>
>>> I create a new thread because I think it is not good to continue in an other
>>> thread
>>>
>>> As I am beginning to interface my hardware on my robot (especially my CAN bus),
>>> I wondered about where I could find others components or publish my code to help
>>> others, I asked :
>>>> [...]where is the place for such a
>>>> component ? is it the job of OCL v2 ?
>>>
>>> Peter's answer :
>>>> No. Create a package repository similar to how a ROS package tree works (ie
>>>> identical :-) , and point people to that repository. You can use git or svn,
>>>> or whatever you feel most comfortable with.
>>
>> I do not agree with Peter completely: the original idea of OCL (6-7 years
>> ago) was for it to become the place to collect "best practice" solutions,
>> and only those. Because of a lack of insight in what "best practice" really
>> means, OCL ended up in becoming the "wast basket" of the Orocos project,
>> that is, the branch were everything got dumped that did not nicely fit in
>> the core parts of the project's source tree :-(
>>
>> I think it is high time to resurrect OCL as "the" place for users to go an
>> look for proven, documented, best practice systems. I think this is to some
>> extent what you are also hinting at, isn't it?
>
> I'm with Herman on this one. Orocos' biggest fault is that it is developer-centric, not user-centric. IMHO trimming down OCL was an example of this. The project is wonderful for developers. It is tough to be a user in this ecosystem.
>
>> In addition to that, Peter's suggestion for the "ROS like" approach of
>> various, unreviewed code repositories also makes sense. But the practice
>> proves that this becomes a chaotic bunch of bits and pieces without any
>> quality control or guarantee. I think we should do better with Orocos,
>> since there is a major difference between ROS and Orocos: we want to be the
>> best possible solution in a small niche of robotics.
>
> I agree that there is, and should be, a distinction between best practice examples, and user-contributed code. But we also need examples of both.
>
>>> First of all, I am not complaining about a miss, but trying to understand what's
>>> the Orocos roadmap about "community integration". I think there is a lack and as
>>> I love Orocos I can't accept it can't conquer the world :p
>>
>> It should conquer only a small piece of the world, but conquer that niche
>> without leaving any room for competition :-)
>>
>>> I totally agree on the fact it is not the job of Orocos developpers to provide
>>> such "users components".
>>
>> It _is_, but then only for a small set of proven, best practice components!
>
> It absolutely is the developer's responsibility - if you want the project
> to last. Developers need to provide a framework within which new users
> can rapidly get used to a system. Without fostering your user base,
> projects die. New users need solid system examples of how to use Orocos
> in a system. No such example exists. This leaves new users foundering
> without direction, leading them to seek alternatives. I know groups
> who've already done this.
At Leuven, we have been playing (but not much more, unfortunately) with the
idea of providing the "motion stack" packaged with a Blender Python script
that makes a Blender simulation work as a simple "RTT component". In this
way, we could provide an "Hello robot!" example that runs out of the box on
all major platforms, without users needing to have a real robot. I know it
is time to stop playing and become serious...
>>> But what about a common place where users provide their
>>> components ? For exemple eclipse market place, your favorite web browser plugin
>>> download page, the ROS wiki ... ?
>>> Is it a clear will not to provide such a place or a lack of hands to
>>> create,maintain this ?
>>
>>> Of course I may publish my SVN (it is not currently interesting but let imagine
>>> it is), how a new user may find ready-to-use-components ? I can't even find a
>>> link to the huge work DFKI has done from the Orocos web site (and I know what I
>>> am searching) !
>>>
>>> Is it because Orocos is not mature enougth to wish to handle all this stuff ?
>>
>> It definitely was not, until quite recently. But currently, as proven by
>> the activity on this mailing list and its developers' companion
>> "orocos-dev", the project has reached a much more mature status, with a
>> surprisingly broad group of dedicated people. So, I think that time might
>> have come to try to resurrect the original OCL idea again...
>>
>> Accepting a design into that "best practices" repository should be the
>> result of a more or less structured and 'standardized' evaluation process,
>> with extensive possibility for community inputs.
>
> See [1] below re structuring the contribution process. Some ideas under "improvements" in Section 3.
>
>> I see one particular "best practice" design as being almost mature enough
>> to become the first OCL entry: the "motion control stack" that many of us
>> are already using in one way or another on their robots, consisting of a
>> HAL, a joint space control, a Cartesian control, and a iTaSC task
>> specification coordinator on top.
>
> Is there an example of this system, or any part of its layers, currently available to the public?
>
>
> In a similar vein, I created Roadmap and Contributing pages for the Orocos Toolchain. I felt that these were two critical missing resources, along with "system examples" (still working that, continuing to fight with v2). These are available on the toolchain wiki page [8], but not the top-level Toolchain page [9]. Once reviewed, they can be added at the top.
>
> I think good examples of Roadmaps from other projects are [3] (though it doesn't need the dev process bit at top - that belongs elsewhere), and [4] (though awfully brief). Both give an idea of where things are going. We didn't have that, and still don't for the other elements of the toolchain (others have to fill this in ... hint hint ...).
>
> Contributing is about helping users become contributors (see Recommendations, Section 1, [1]). A decent example is [5], or one with too much detail [6]. I pulled details from previous discussions [10] and [11]. This page needs review. I took a best guess - things are bound to be wrong.
>
> Nice example for describing how to submit patches [7]. This definitely needs work on our site.
>
Thanks for this useful set of links!!
> I think the Rock project [12] has done a good job of showing us up re system examples and help, and being more user-centric. I'd actually consider using that, if it wasn't using Ruby ... sorry Sylvain, nothing but bad experiences with it. :-(
>
> Thoughts anyone ....?
> S
>
> [1] http://www.cyber-anthro.com/beta-an-exploration-of-fedora?s-online-open-...
> [2] http://blogs.gnome.org/bolsh/2011/02/07/drawing-up-a-roadmap/
> [3] http://trac.wxwidgets.org/wiki/Roadmap
> [4] http://www.openscenegraph.org/projects/osg/wiki/Support/Plans
> [5] http://www.cmake.org/cmake/project/getinvolved.html
> [6] http://wiki.laptop.org/go/Developers
> [7] http://trac.wxwidgets.org/wiki/HowToSubmitPatches
> [8] http://www.orocos.org/wiki/orocos/toolchain/
> [9] http://www.orocos.org/toolchain
> [10] http://www.orocos.org/forum/rtt/rtt-dev/version-management-and-branches-...
> [11] http://www.orocos.org/forum/rtt/rtt-dev/branch-names-updates
> [12] http://rock-robotics.org/
Herman
The place for sharing users component
2011/2/23 Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...>
> On Wed, 23 Feb 2011, S Roderick wrote:
>
> On Feb 22, 2011, at 15:29 , Herman Bruyninckx wrote:
>>
>> On Tue, 22 Feb 2011, Willy Lambert wrote:
>>>
>>> Hi all,
>>>>
>>>> I create a new thread because I think it is not good to continue in an
>>>> other
>>>> thread
>>>>
>>>> As I am beginning to interface my hardware on my robot (especially my
>>>> CAN bus),
>>>> I wondered about where I could find others components or publish my code
>>>> to help
>>>> others, I asked :
>>>>
>>>>> [...]where is the place for such a
>>>>> component ? is it the job of OCL v2 ?
>>>>>
>>>>
>>>> Peter's answer :
>>>>
>>>>> No. Create a package repository similar to how a ROS package tree works
>>>>> (ie
>>>>> identical :-) , and point people to that repository. You can use git or
>>>>> svn,
>>>>> or whatever you feel most comfortable with.
>>>>>
>>>>
>>> I do not agree with Peter completely: the original idea of OCL (6-7 years
>>> ago) was for it to become the place to collect "best practice" solutions,
>>> and only those. Because of a lack of insight in what "best practice"
>>> really
>>> means, OCL ended up in becoming the "wast basket" of the Orocos project,
>>> that is, the branch were everything got dumped that did not nicely fit in
>>> the core parts of the project's source tree :-(
>>>
>>> I think it is high time to resurrect OCL as "the" place for users to go
>>> an
>>> look for proven, documented, best practice systems. I think this is to
>>> some
>>> extent what you are also hinting at, isn't it?
>>>
>>
>> I'm with Herman on this one. Orocos' biggest fault is that it is
>> developer-centric, not user-centric. IMHO trimming down OCL was an example
>> of this. The project is wonderful for developers. It is tough to be a user
>> in this ecosystem.
>>
>> In addition to that, Peter's suggestion for the "ROS like" approach of
>>> various, unreviewed code repositories also makes sense. But the practice
>>> proves that this becomes a chaotic bunch of bits and pieces without any
>>> quality control or guarantee. I think we should do better with Orocos,
>>> since there is a major difference between ROS and Orocos: we want to be
>>> the
>>> best possible solution in a small niche of robotics.
>>>
>>
>> I agree that there is, and should be, a distinction between best practice
>> examples, and user-contributed code. But we also need examples of both.
>>
>> First of all, I am not complaining about a miss, but trying to understand
>>>> what's
>>>> the Orocos roadmap about "community integration". I think there is a
>>>> lack and as
>>>> I love Orocos I can't accept it can't conquer the world :p
>>>>
>>>
>>> It should conquer only a small piece of the world, but conquer that niche
>>> without leaving any room for competition :-)
>>>
>>> I totally agree on the fact it is not the job of Orocos developpers to
>>>> provide
>>>> such "users components".
>>>>
>>>
>>> It _is_, but then only for a small set of proven, best practice
>>> components!
>>>
>>
>> It absolutely is the developer's responsibility - if you want the project
>> to last. Developers need to provide a framework within which new users
>> can rapidly get used to a system. Without fostering your user base,
>> projects die. New users need solid system examples of how to use Orocos
>> in a system. No such example exists. This leaves new users foundering
>> without direction, leading them to seek alternatives. I know groups
>> who've already done this.
>>
>
> At Leuven, we have been playing (but not much more, unfortunately) with the
> idea of providing the "motion stack" packaged with a Blender Python script
> that makes a Blender simulation work as a simple "RTT component". In this
> way, we could provide an "Hello robot!" example that runs out of the box on
> all major platforms, without users needing to have a real robot. I know it
> is time to stop playing and become serious...
It was not my aim to provoque a 1.x versus 2.x discussion, so let's me
recall the first subject of this thread :
"What is the place for user contributions"
When I say "user contribution" I am not speaking about code report or
documentation improvment, I am speaking about sharing what you do __with__
orocos. I quote Klaas's point of view :
"Suppose (purely hypothetical) I (not referring to myself, but rather to
some a industrial company using orocos) am an orocos 1.x user, that invested
(quite?) some effort in getting the 1.x series where they are now and
learning some new tools. I am not being paid to work _on_ orocos, but to do
something useful _with_ orocos."
I am beginning a robot project that will maybe live during 5 years (crossed
fingers). I will do or redo what's all roboticians have to do in a first
step (with no hudge interest for me) : interfacing harware. I am keen to
share my stuff. But there is no way I set up I full project for becoming an
Orocos distributor (yet ?! ^^ ).
Herman, for you motion stack you should have exactly the same question as I
: "Where on the hell may I share this very user-usefull stuff as it can be
seen on the Orocos community easily ?"
It is that kind of user contributions that'll provoque user gathering to
create distributions. But there is no "how to become a distributor" page on
Orocos, neither than "what could be a distribution of Orocos". IMO (to my
very young use of linux 2.6 Herman :p), a distribution in linux is a pick
and choose of existing applications. That does mean it exists users before
distributors.
At the end I bumped into : "Components built by users of Orocos are hosted
in their own repositories." on the http://www.orocos.org/toolchain page. So
here is my answer. OCL has turned into the tools you need to monitor your
application (taskbrowser, logs , ...) and I may understand this. And if I
want to share my stuff it's my problem (so I won't because I am keen to
share not to set up a sharing system). In practice I will go with the ROS
sharing system http://www.ros.org/wiki/ because I don't have anything to
do. I think it's a pity for Orocos not to have an equivalent but anyway.
Maybe I should reformulate like "Does anyone in the Orocos community is keen
on setting up a component sharing system or to create an 'Ocoros Hardware
Library' ?" I hope there is some pleople in the Orocos core that wish to do
so or to help in this, because if not I don't think Orocos will live long.
To finish with, there is a difference between : "we don't have time to
integrate the Orocos Component Builder community and we 'recruit' people to
do so" and "we don't care of Orocos Component Builder community it is not
our job". Separating concepts between the core (rtt,ocl, ...) and the
satellites (DFKI, Orocos Hardware Library, ...) is natural. Waiting for
other to wake up a morning saying "Okay I'll become an Orocos distributor"
is utopic. Before doing this you have to be a user, a Component Builder, a
passionate and then more. To my point of view, and it's very personnal, it
is the job of Orocos and all project that wants to spread to give a chance
to people to make this transition.
P.S. : related to the subjets evoked in this thread :
http://www.orocos.org/wiki/orocos/toolchain/contributing
http://www.orocos.org/wiki/orocos/toolchain/roadmap
are really really nice to have and you should spend time into populating
them.
Please add the commands we have to type to generate a patch. I sent patches
to ROS because they gave me a ligth and clear process I just have to copy
without loosing any of my time. It would be a pity people don't send their
patches becauses they would have to read the git and patch documentation and
don't want to spend time in this (personnaly it is my case).
The place for sharing users component
On Sat, 26 Feb 2011, Willy Lambert wrote:
>
>
> 2011/2/23 Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...>
> On Wed, 23 Feb 2011, S Roderick wrote:
>
> On Feb 22, 2011, at 15:29 , Herman Bruyninckx wrote:
>
> On Tue, 22 Feb 2011, Willy Lambert wrote:
>
> Hi all,
>
> I create a new thread because I think
> it is not good to continue in an other
> thread
>
> As I am beginning to interface my
> hardware on my robot (especially my
> CAN bus),
> I wondered about where I could find
> others components or publish my code
> to help
> others, I asked :
> [...]where is the place
> for such a
> component ? is it the job
> of OCL v2 ?
>
>
> Peter's answer :
> No. Create a package
> repository similar to how
> a ROS package tree works
> (ie
> identical :-) , and point
> people to that repository.
> You can use git or svn,
> or whatever you feel most
> comfortable with.
>
>
> I do not agree with Peter completely: the original
> idea of OCL (6-7 years
> ago) was for it to become the place to collect
> "best practice" solutions,
> and only those. Because of a lack of insight in
> what "best practice" really
> means, OCL ended up in becoming the "wast basket"
> of the Orocos project,
> that is, the branch were everything got dumped
> that did not nicely fit in
> the core parts of the project's source tree :-(
>
> I think it is high time to resurrect OCL as "the"
> place for users to go an
> look for proven, documented, best practice
> systems. I think this is to some
> extent what you are also hinting at, isn't it?
>
>
> I'm with Herman on this one. Orocos' biggest fault is that it
> is developer-centric, not user-centric. IMHO trimming down OCL
> was an example of this. The project is wonderful for
> developers. It is tough to be a user in this ecosystem.
>
> In addition to that, Peter's suggestion for the
> "ROS like" approach of
> various, unreviewed code repositories also makes
> sense. But the practice
> proves that this becomes a chaotic bunch of bits
> and pieces without any
> quality control or guarantee. I think we should do
> better with Orocos,
> since there is a major difference between ROS and
> Orocos: we want to be the
> best possible solution in a small niche of
> robotics.
>
>
> I agree that there is, and should be, a distinction between
> best practice examples, and user-contributed code. But we also
> need examples of both.
>
> First of all, I am not complaining
> about a miss, but trying to understand
> what's
> the Orocos roadmap about "community
> integration". I think there is a lack
> and as
> I love Orocos I can't accept it can't
> conquer the world :p
>
>
> It should conquer only a small piece of the world,
> but conquer that niche
> without leaving any room for competition :-)
>
> I totally agree on the fact it is not
> the job of Orocos developpers to
> provide
> such "users components".
>
>
> It _is_, but then only for a small set of proven,
> best practice components!
>
>
> It absolutely is the developer's responsibility - if you want
> the project
> to last. Developers need to provide a framework within which
> new users
> can rapidly get used to a system. Without fostering your user
> base,
> projects die. New users need solid system examples of how to
> use Orocos
> in a system. No such example exists. This leaves new users
> foundering
> without direction, leading them to seek alternatives. I know
> groups
> who've already done this.
>
>
> At Leuven, we have been playing (but not much more, unfortunately) with
> the
> idea of providing the "motion stack" packaged with a Blender Python script
> that makes a Blender simulation work as a simple "RTT component". In this
> way, we could provide an "Hello robot!" example that runs out of the box
> on
> all major platforms, without users needing to have a real robot. I know it
> is time to stop playing and become serious...
>
>
>
> It was not my aim to provoque a 1.x versus 2.x discussion, so let's me recall
> the first subject of this thread :
> "What is the place for user contributions"
>
> When I say "user contribution" I am not speaking about code report or
> documentation improvment, I am speaking about sharing what you do __with__
> orocos. I quote Klaas's point of view :
> "Suppose (purely hypothetical) I (not referring to myself, but rather to some a
> industrial company using orocos) am an orocos 1.x user, that invested (quite?)
> some effort in getting the 1.x series where they are now and learning some new
> tools. I am not being paid to work _on_ orocos, but to do something useful
> _with_ orocos."
>
> I am beginning a robot project that will maybe live during 5 years (crossed
> fingers). I will do or redo what's all roboticians have to do in a first step
> (with no hudge interest for me) : interfacing harware. I am keen to share my
> stuff. But there is no way I set up I full project for becoming an Orocos
> distributor (yet ?! ^^ ).
>
> Herman, for you motion stack you should have exactly the same question as I :
> "Where on the hell may I share this very user-usefull stuff as it can be seen on
> the Orocos community easily ?"
> It is that kind of user contributions that'll provoque user gathering to create
> distributions. But there is no "how to become a distributor" page on Orocos,
> neither than "what could be a distribution of Orocos". IMO (to my very young use
> of linux 2.6 Herman :p), a distribution in linux is a pick and choose of
> existing applications. That does mean it exists users before distributors.
>
> At the end I bumped into : "Components built by users of Orocos are hosted in
> their own repositories." on the http://www.orocos.org/toolchain page. So here is
> my answer. OCL has turned into the tools you need to monitor your application
> (taskbrowser, logs , ...) and I may understand this. And if I want to share my
> stuff it's my problem (so I won't because I am keen to share not to set up a
> sharing system). In practice I will go with the ROS sharing system
> http://www.ros.org/wiki/ because I don't have anything to do. I think it's a
> pity for Orocos not to have an equivalent but anyway.
Of course it is a pity. But it is all a matter of resources. People can
(rightfully) keep on asking for a user distribution, and I will support
them in this claim, but the pragmatic reality of open source projects is
that the required efforts should come somewhere from the community. The
current developers do not have the means to take up yet another
responsibility, however useful and needed that might.
Hence, to all Orocos _users_ I can only say this: "It's time to ask what you
can do for the community, and not what the community can do for you!"
> Maybe I should reformulate like "Does anyone in the Orocos community is keen on
> setting up a component sharing system or to create an 'Ocoros Hardware Library'
> ?" I hope there is some pleople in the Orocos core that wish to do so or to help
> in this, because if not I don't think Orocos will live long.
Don't worry about the 'developers part' of the project! :-)
> To finish with, there is a difference between : "we don't have time to integrate
> the Orocos Component Builder community and we 'recruit' people to do so" and "we
> don't care of Orocos Component Builder community it is not our job". Separating
> concepts between the core (rtt,ocl, ...) and the satellites (DFKI, Orocos
> Hardware Library, ...) is natural. Waiting for other to wake up a morning saying
> "Okay I'll become an Orocos distributor" is utopic.
Why? It has been done dozens of times before. Red Hat, Canonical, Debian,
... where not started by developers, but by (power) users, with the same
concern as the ones that have been raised on this thread.
> Before doing this you have
> to be a user, a Component Builder, a passionate and then more. To my point of
> view, and it's very personnal, it is the job of Orocos and all project that
> wants to spread to give a chance to people to make this transition.
>
>
> P.S. : related to the subjets evoked in this thread :
> http://www.orocos.org/wiki/orocos/toolchain/contributing
> http://www.orocos.org/wiki/orocos/toolchain/roadmap
> are really really nice to have and you should spend time into populating them.
> Please add the commands we have to type to generate a patch. I sent patches to
> ROS because they gave me a ligth and clear process I just have to copy without
> loosing any of my time.
The ROS path is probably the easiest to go, as far as a "Orocos
distribution" goes. And we _have_ already started going that path, so isn't
that what you are asking for?
> It would be a pity people don't send their patches
> becauses they would have to read the git and patch documentation and don't want
> to spend time in this (personnaly it is my case).
Herman
The place for sharing users component
2011/2/27 Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...>
> On Sat, 26 Feb 2011, Willy Lambert wrote:
>
>
>>
>> 2011/2/23 Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...>
>> On Wed, 23 Feb 2011, S Roderick wrote:
>>
>> On Feb 22, 2011, at 15:29 , Herman Bruyninckx wrote:
>>
>> On Tue, 22 Feb 2011, Willy Lambert wrote:
>>
>> Hi all,
>>
>> I create a new thread because I think
>> it is not good to continue in an other
>> thread
>>
>> As I am beginning to interface my
>> hardware on my robot (especially my
>> CAN bus),
>> I wondered about where I could find
>> others components or publish my code
>> to help
>> others, I asked :
>> [...]where is the place
>> for such a
>> component ? is it the job
>> of OCL v2 ?
>>
>>
>> Peter's answer :
>> No. Create a package
>> repository similar to how
>> a ROS package tree works
>> (ie
>> identical :-) , and point
>> people to that repository.
>> You can use git or svn,
>> or whatever you feel most
>> comfortable with.
>>
>>
>> I do not agree with Peter completely: the original
>> idea of OCL (6-7 years
>> ago) was for it to become the place to collect
>> "best practice" solutions,
>> and only those. Because of a lack of insight in
>> what "best practice" really
>> means, OCL ended up in becoming the "wast basket"
>> of the Orocos project,
>> that is, the branch were everything got dumped
>> that did not nicely fit in
>> the core parts of the project's source tree :-(
>>
>> I think it is high time to resurrect OCL as "the"
>> place for users to go an
>> look for proven, documented, best practice
>> systems. I think this is to some
>> extent what you are also hinting at, isn't it?
>>
>>
>> I'm with Herman on this one. Orocos' biggest fault is that it
>> is developer-centric, not user-centric. IMHO trimming down OCL
>> was an example of this. The project is wonderful for
>> developers. It is tough to be a user in this ecosystem.
>>
>> In addition to that, Peter's suggestion for the
>> "ROS like" approach of
>> various, unreviewed code repositories also makes
>> sense. But the practice
>> proves that this becomes a chaotic bunch of bits
>> and pieces without any
>> quality control or guarantee. I think we should do
>> better with Orocos,
>> since there is a major difference between ROS and
>> Orocos: we want to be the
>> best possible solution in a small niche of
>> robotics.
>>
>>
>> I agree that there is, and should be, a distinction between
>> best practice examples, and user-contributed code. But we also
>> need examples of both.
>>
>> First of all, I am not complaining
>> about a miss, but trying to understand
>> what's
>> the Orocos roadmap about "community
>> integration". I think there is a lack
>> and as
>> I love Orocos I can't accept it can't
>> conquer the world :p
>>
>>
>> It should conquer only a small piece of the world,
>> but conquer that niche
>> without leaving any room for competition :-)
>>
>> I totally agree on the fact it is not
>> the job of Orocos developpers to
>> provide
>> such "users components".
>>
>>
>> It _is_, but then only for a small set of proven,
>> best practice components!
>>
>>
>> It absolutely is the developer's responsibility - if you want
>> the project
>> to last. Developers need to provide a framework within which
>> new users
>> can rapidly get used to a system. Without fostering your user
>> base,
>> projects die. New users need solid system examples of how to
>> use Orocos
>> in a system. No such example exists. This leaves new users
>> foundering
>> without direction, leading them to seek alternatives. I know
>> groups
>> who've already done this.
>>
>>
>> At Leuven, we have been playing (but not much more, unfortunately) with
>> the
>> idea of providing the "motion stack" packaged with a Blender Python script
>> that makes a Blender simulation work as a simple "RTT component". In this
>> way, we could provide an "Hello robot!" example that runs out of the box
>> on
>> all major platforms, without users needing to have a real robot. I know it
>> is time to stop playing and become serious...
>>
>>
>>
>> It was not my aim to provoque a 1.x versus 2.x discussion, so let's me
>> recall
>> the first subject of this thread :
>> "What is the place for user contributions"
>>
>> When I say "user contribution" I am not speaking about code report or
>> documentation improvment, I am speaking about sharing what you do __with__
>> orocos. I quote Klaas's point of view :
>> "Suppose (purely hypothetical) I (not referring to myself, but rather to
>> some a
>> industrial company using orocos) am an orocos 1.x user, that invested
>> (quite?)
>> some effort in getting the 1.x series where they are now and learning some
>> new
>> tools. I am not being paid to work _on_ orocos, but to do something
>> useful
>> _with_ orocos."
>>
>> I am beginning a robot project that will maybe live during 5 years
>> (crossed
>> fingers). I will do or redo what's all roboticians have to do in a first
>> step
>> (with no hudge interest for me) : interfacing harware. I am keen to share
>> my
>> stuff. But there is no way I set up I full project for becoming an Orocos
>> distributor (yet ?! ^^ ).
>>
>> Herman, for you motion stack you should have exactly the same question as
>> I :
>> "Where on the hell may I share this very user-usefull stuff as it can be
>> seen on
>> the Orocos community easily ?"
>> It is that kind of user contributions that'll provoque user gathering to
>> create
>> distributions. But there is no "how to become a distributor" page on
>> Orocos,
>> neither than "what could be a distribution of Orocos". IMO (to my very
>> young use
>> of linux 2.6 Herman :p), a distribution in linux is a pick and choose of
>> existing applications. That does mean it exists users before distributors.
>>
>> At the end I bumped into : "Components built by users of Orocos are hosted
>> in
>> their own repositories." on the http://www.orocos.org/toolchain page. So
>> here is
>> my answer. OCL has turned into the tools you need to monitor your
>> application
>> (taskbrowser, logs , ...) and I may understand this. And if I want to
>> share my
>> stuff it's my problem (so I won't because I am keen to share not to set up
>> a
>> sharing system). In practice I will go with the ROS sharing system
>> http://www.ros.org/wiki/ because I don't have anything to do. I think
>> it's a
>> pity for Orocos not to have an equivalent but anyway.
>>
>
> Of course it is a pity. But it is all a matter of resources.
>
Not only, it is also a problem of communication, there is nowhere I can
found "Help us in doing this, whe don't have the time and would be pleased
to integrate new ".
> People can
> (rightfully) keep on asking for a user distribution, and I will support
> them in this claim, but the pragmatic reality of open source projects is
> that the required efforts should come somewhere from the community. The
> current developers do not have the means to take up yet another
> responsibility, however useful and needed that might.
>
> Hence, to all Orocos _users_ I can only say this: "It's time to ask what
> you
> can do for the community, and not what the community can do for you!"
I already asked me this question (that's why I am spending time in this
thread). Once again and related to what Stephen refered to, the "Contribute"
web page on the website is a must have to help this transistion.
But as a "Component Builder" my first logical answer is ok, I may be a
"Component Sharer" in a distribution.
There is still something missing in the chain as you expect more than this.
You expect them to become "Distributors"
>
>
> Maybe I should reformulate like "Does anyone in the Orocos community is
>> keen on
>> setting up a component sharing system or to create an 'Ocoros Hardware
>> Library'
>> ?" I hope there is some pleople in the Orocos core that wish to do so or
>> to help
>> in this, because if not I don't think Orocos will live long.
>>
>
> Don't worry about the 'developers part' of the project! :-)
>
>
> To finish with, there is a difference between : "we don't have time to
>> integrate
>> the Orocos Component Builder community and we 'recruit' people to do so"
>> and "we
>> don't care of Orocos Component Builder community it is not our job".
>> Separating
>> concepts between the core (rtt,ocl, ...) and the satellites (DFKI, Orocos
>> Hardware Library, ...) is natural. Waiting for other to wake up a morning
>> saying
>> "Okay I'll become an Orocos distributor" is utopic.
>>
>
> Why? It has been done dozens of times before. Red Hat, Canonical, Debian,
> ... where not started by developers, but by (power) users, with the same
> concern as the ones that have been raised on this thread.
Because it is very hard to be a power user in Orocos since it's hard to
become a user and somehow (but I am sure it is not the real current case)
you are not interested in user but distributors.
Herman, you did not answer to my question (that I did not formulate as a
question :p) :
What is the official position in the Orocos project between :
_ "We have no more ressources and would love to have new developpers to help
into bringing up a distribution into the Orocos project"
_ "We think doing a distribution is not a part of the Orocos project and
would love that a new independant project hold this"
?
>
>
> Before doing this you have
>> to be a user, a Component Builder, a passionate and then more. To my point
>> of
>> view, and it's very personnal, it is the job of Orocos and all project
>> that
>> wants to spread to give a chance to people to make this transition.
>>
>>
>> P.S. : related to the subjets evoked in this thread :
>> http://www.orocos.org/wiki/orocos/toolchain/contributing
>> http://www.orocos.org/wiki/orocos/toolchain/roadmap
>> are really really nice to have and you should spend time into populating
>> them.
>> Please add the commands we have to type to generate a patch. I sent
>> patches to
>> ROS because they gave me a ligth and clear process I just have to copy
>> without
>> loosing any of my time.
>>
>
> The ROS path is probably the easiest to go, as far as a "Orocos
> distribution" goes. And we _have_ already started going that path, so isn't
> that what you are asking for?
I was asking for the "orocos" position in front of user code and why. All
the helpfull answer you gave me in this thread went in this way. Whatever I
scratch around this position, I understand it clearly.
I would be pleased to also have Peter's view around all this thread.
>
>
> It would be a pity people don't send their patches
>> becauses they would have to read the git and patch documentation and don't
>> want
>> to spend time in this (personnaly it is my case).
>>
>
> Herman
The place for sharing users component
On Sun, 27 Feb 2011, Willy Lambert wrote:
>
>
> 2011/2/27 Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...>
> On Sat, 26 Feb 2011, Willy Lambert wrote:
>
>
>
> 2011/2/23 Herman Bruyninckx
> <Herman [dot] Bruyninckx [..] ...>
> On Wed, 23 Feb 2011, S Roderick wrote:
>
> On Feb 22, 2011, at 15:29 , Herman Bruyninckx wrote:
>
> On Tue, 22 Feb 2011, Willy Lambert wrote:
>
> Hi all,
>
> I create a new thread because I think
> it is not good to continue in an other
> thread
>
> As I am beginning to interface my
> hardware on my robot (especially my
> CAN bus),
> I wondered about where I could find
> others components or publish my code
> to help
> others, I asked :
> [...]where is the place
> for such a
> component ? is it the job
> of OCL v2 ?
>
>
> Peter's answer :
> No. Create a package
> repository similar to how
> a ROS package tree works
> (ie
> identical :-) , and point
> people to that repository.
> You can use git or svn,
> or whatever you feel most
> comfortable with.
>
>
> I do not agree with Peter completely: the original
> idea of OCL (6-7 years
> ago) was for it to become the place to collect
> "best practice" solutions,
> and only those. Because of a lack of insight in
> what "best practice" really
> means, OCL ended up in becoming the "wast basket"
> of the Orocos project,
> that is, the branch were everything got dumped
> that did not nicely fit in
> the core parts of the project's source tree :-(
>
> I think it is high time to resurrect OCL as "the"
> place for users to go an
> look for proven, documented, best practice
> systems. I think this is to some
> extent what you are also hinting at, isn't it?
>
>
> I'm with Herman on this one. Orocos' biggest fault is
> that it
> is developer-centric, not user-centric. IMHO trimming
> down OCL
> was an example of this. The project is wonderful for
> developers. It is tough to be a user in this ecosystem.
>
> In addition to that, Peter's suggestion for the
> "ROS like" approach of
> various, unreviewed code repositories also makes
> sense. But the practice
> proves that this becomes a chaotic bunch of bits
> and pieces without any
> quality control or guarantee. I think we should do
> better with Orocos,
> since there is a major difference between ROS and
> Orocos: we want to be the
> best possible solution in a small niche of
> robotics.
>
>
> I agree that there is, and should be, a distinction
> between
> best practice examples, and user-contributed code. But we
> also
> need examples of both.
>
> First of all, I am not complaining
> about a miss, but trying to understand
> what's
> the Orocos roadmap about "community
> integration". I think there is a lack
> and as
> I love Orocos I can't accept it can't
> conquer the world :p
>
>
> It should conquer only a small piece of the world,
> but conquer that niche
> without leaving any room for competition :-)
>
> I totally agree on the fact it is not
> the job of Orocos developpers to
> provide
> such "users components".
>
>
> It _is_, but then only for a small set of proven,
> best practice components!
>
>
> It absolutely is the developer's responsibility - if you
> want
> the project
> to last. Developers need to provide a framework within
> which
> new users
> can rapidly get used to a system. Without fostering your
> user
> base,
> projects die. New users need solid system examples of how
> to
> use Orocos
> in a system. No such example exists. This leaves new
> users
> foundering
> without direction, leading them to seek alternatives. I
> know
> groups
> who've already done this.
>
>
> At Leuven, we have been playing (but not much more,
> unfortunately) with
> the
> idea of providing the "motion stack" packaged with a Blender
> Python script
> that makes a Blender simulation work as a simple "RTT
> component". In this
> way, we could provide an "Hello robot!" example that runs out
> of the box
> on
> all major platforms, without users needing to have a real
> robot. I know it
> is time to stop playing and become serious...
>
>
>
> It was not my aim to provoque a 1.x versus 2.x discussion, so
> let's me recall
> the first subject of this thread :
> "What is the place for user contributions"
>
> When I say "user contribution" I am not speaking about code
> report or
> documentation improvment, I am speaking about sharing what you
> do __with__
> orocos. I quote Klaas's point of view :
> "Suppose (purely hypothetical) I (not referring to myself, but
> rather to some a
> industrial company using orocos) am an orocos 1.x user, that
> invested (quite?)
> some effort in getting the 1.x series where they are now and
> learning some new
> tools. I am not being paid to work _on_ orocos, but to do
> something useful
> _with_ orocos."
>
> I am beginning a robot project that will maybe live during 5
> years (crossed
> fingers). I will do or redo what's all roboticians have to do
> in a first step
> (with no hudge interest for me) : interfacing harware. I am
> keen to share my
> stuff. But there is no way I set up I full project for
> becoming an Orocos
> distributor (yet ?! ^^ ).
>
> Herman, for you motion stack you should have exactly the same
> question as I :
> "Where on the hell may I share this very user-usefull stuff as
> it can be seen on
> the Orocos community easily ?"
> It is that kind of user contributions that'll provoque user
> gathering to create
> distributions. But there is no "how to become a distributor"
> page on Orocos,
> neither than "what could be a distribution of Orocos". IMO (to
> my very young use
> of linux 2.6 Herman :p), a distribution in linux is a pick and
> choose of
> existing applications. That does mean it exists users before
> distributors.
>
> At the end I bumped into : "Components built by users of
> Orocos are hosted in
> their own repositories." on the
> http://www.orocos.org/toolchain page. So here is
> my answer. OCL has turned into the tools you need to monitor
> your application
> (taskbrowser, logs , ...) and I may understand this. And if I
> want to share my
> stuff it's my problem (so I won't because I am keen to share
> not to set up a
> sharing system). In practice I will go with the ROS sharing
> system
> http://www.ros.org/wiki/ because I don't have anything to do.
> I think it's a
> pity for Orocos not to have an equivalent but anyway.
>
>
> Of course it is a pity. But it is all a matter of resources.
>
>
> Not only, it is also a problem of communication, there is nowhere I can found
> "Help us in doing this, whe don't have the time and would be pleased to
> integrate new ".
>
> People can
> (rightfully) keep on asking for a user distribution, and I will
> support
> them in this claim, but the pragmatic reality of open source
> projects is
> that the required efforts should come somewhere from the community.
> The
> current developers do not have the means to take up yet another
> responsibility, however useful and needed that might.
>
> Hence, to all Orocos _users_ I can only say this: "It's time to ask
> what you
> can do for the community, and not what the community can do for
> you!"
>
>
> I already asked me this question (that's why I am spending time in this thread).
> Once again and related to what Stephen refered to, the "Contribute" web page on
> the website is a must have to help this transistion.
> But as a "Component Builder" my first logical answer is ok, I may be a
> "Component Sharer" in a distribution.
>
> There is still something missing in the chain as you expect more than this. You
> expect them to become "Distributors"
>
>
>
>
> Maybe I should reformulate like "Does anyone in the
> Orocos community is keen on
> setting up a component sharing system or to create an
> 'Ocoros Hardware Library'
> ?" I hope there is some pleople in the Orocos core that
> wish to do so or to help
> in this, because if not I don't think Orocos will live
> long.
>
>
> Don't worry about the 'developers part' of the project! :-)
>
>
>
> To finish with, there is a difference between : "we
> don't have time to integrate
> the Orocos Component Builder community and we 'recruit'
> people to do so" and "we
> don't care of Orocos Component Builder community it is
> not our job". Separating
> concepts between the core (rtt,ocl, ...) and the
> satellites (DFKI, Orocos
> Hardware Library, ...) is natural. Waiting for other to
> wake up a morning saying
> "Okay I'll become an Orocos distributor" is utopic.
>
>
> Why? It has been done dozens of times before. Red Hat, Canonical, Debian,
> ... where not started by developers, but by (power) users, with the same
> concern as the ones that have been raised on this thread.
>
> Because it is very hard to be a power user in Orocos since it's hard to become a
> user and somehow (but I am sure it is not the real current case) you are not
> interested in user but distributors.
Orocos users are, by definition at this moment, _power users_. Or they have
to have a high level of power userness in them :-) I do not think that that
is going to change a lot (in RTT at least, and to a somewhat lesser extent
in BFL and KDl), since Orocos has been focusing on the very difficult
stuff, and not without success. I repeat that I am not at all against
adding layers on top of the Orocos project, but maybe, just maybe, that is
better done in separate, integrated projects. Like what is already
happening with the Orocos-ROS integration.
But although ROS is the closest thing we have in robotics as far as
"distributions" go, you also notice the huge difficulties the ROS community
has in "doing it right", especially in keeping evolving versions of
sub-projects in sync. (For example, the state of KDL in ROS.) I am not at
all blaming the ROS community, since I very well understand the huge
efforts involved. And I do not think that Orocos should start its own
"ROS"-like effort: I have always been in favour of reusing existing
efforts! Even when they are not perfect, since who are we to do that
distributor effort better than the (much larger) ROS community...? Many
Orocos developers have already contributed to ROS in that way, providing
packages, sending patches for the ROS toolchain, etc.
> Herman, you did not answer to my question (that I did not formulate as a
> question :p) :
> What is the official position in the Orocos project between :
> _ "We have no more ressources and would love to have new developpers to help
> into bringing up a distribution into the Orocos project"
> _ "We think doing a distribution is not a part of the Orocos project and would
> love that a new independant project hold this"
> ?
I am very surprised to see you formulate things using a wording like "what
is the official position"...? Orocos is an open source project, so there
_is_ no official position! I give my ideas, others give theirs, and then
some common dynamics is maybe set into action to change things. None of
this is following an official, top-down decision process. If there are some
concrete actions to reinstate "OCL" as a user-centric part of the project,
I am sure that Peter Soetens (and the other Orocos sub-project maintainers)
will consider and discuss these suggestions very carefully, critically and
respectfully.
>
> Before doing this you have
> to be a user, a Component Builder, a passionate and then
> more. To my point of
> view, and it's very personnal, it is the job of Orocos
> and all project that
> wants to spread to give a chance to people to make this
> transition.
>
> P.S. : related to the subjets evoked in this thread :
> http://www.orocos.org/wiki/orocos/toolchain/contributing
> http://www.orocos.org/wiki/orocos/toolchain/roadmap
> are really really nice to have and you should spend time
> into populating them.
> Please add the commands we have to type to generate a
> patch. I sent patches to
> ROS because they gave me a ligth and clear process I
> just have to copy without
> loosing any of my time.
>
> The ROS path is probably the easiest to go, as far as a "Orocos
> distribution" goes. And we _have_ already started going that path, so
> isn't that what you are asking for?
>
> I was asking for the "orocos" position in front of user code and why. All the
> helpfull answer you gave me in this thread went in this way. Whatever I scratch
> around this position, I understand it clearly.
Fine. To me, all this is obvious open source dynamics :-)
> I would be pleased to also have Peter's view around all this thread.
>
> It would be a pity people don't send their patches
> becauses they would have to read the git and patch
> documentation and don't want
> to spend time in this (personnaly it is my case).
If I can teach you one open source skill that everyone definitely needs to
sharpen: you have to closely follow at least a dozen or so open source
projects, in order to be able to make the decision with two or three of
them to use in a successfully integrated way :-) Multi-project
_integration_ being the key to success, not single-project featuritis...
Herman
The place for sharing users component
On Feb 27, 2011, at 06:50 , Herman Bruyninckx wrote:
> On Sun, 27 Feb 2011, Willy Lambert wrote:
>
>> 2011/2/27 Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...>
>> On Sat, 26 Feb 2011, Willy Lambert wrote:
>>
>> 2011/2/23 Herman Bruyninckx
>> <Herman [dot] Bruyninckx [..] ...>
>> On Wed, 23 Feb 2011, S Roderick wrote:
>>
>> On Feb 22, 2011, at 15:29 , Herman Bruyninckx wrote:
>>
>> On Tue, 22 Feb 2011, Willy Lambert wrote:
>>
>> Hi all,
>>
>> I create a new thread because I think
>> it is not good to continue in an other
>> thread
>>
>> As I am beginning to interface my
>> hardware on my robot (especially my
>> CAN bus),
>> I wondered about where I could find
>> others components or publish my code
>> to help
>> others, I asked :
>> [...]where is the place
>> for such a
>> component ? is it the job
>> of OCL v2 ?
>>
>> Peter's answer :
>> No. Create a package
>> repository similar to how
>> a ROS package tree works
>> (ie
>> identical :-) , and point
>> people to that repository.
>> You can use git or svn,
>> or whatever you feel most
>> comfortable with.
>>
>> I do not agree with Peter completely: the original
>> idea of OCL (6-7 years
>> ago) was for it to become the place to collect
>> "best practice" solutions,
>> and only those. Because of a lack of insight in
>> what "best practice" really
>> means, OCL ended up in becoming the "wast basket"
>> of the Orocos project,
>> that is, the branch were everything got dumped
>> that did not nicely fit in
>> the core parts of the project's source tree :-(
>>
>> I think it is high time to resurrect OCL as "the"
>> place for users to go an
>> look for proven, documented, best practice
>> systems. I think this is to some
>> extent what you are also hinting at, isn't it?
>>
>> I'm with Herman on this one. Orocos' biggest fault is
>> that it
>> is developer-centric, not user-centric. IMHO trimming
>> down OCL
>> was an example of this. The project is wonderful for
>> developers. It is tough to be a user in this ecosystem.
>>
>> In addition to that, Peter's suggestion for the
>> "ROS like" approach of
>> various, unreviewed code repositories also makes
>> sense. But the practice
>> proves that this becomes a chaotic bunch of bits
>> and pieces without any
>> quality control or guarantee. I think we should do
>> better with Orocos,
>> since there is a major difference between ROS and
>> Orocos: we want to be the
>> best possible solution in a small niche of
>> robotics.
>>
>> I agree that there is, and should be, a distinction
>> between
>> best practice examples, and user-contributed code. But we
>> also
>> need examples of both.
>>
>> First of all, I am not complaining
>> about a miss, but trying to understand
>> what's
>> the Orocos roadmap about "community
>> integration". I think there is a lack
>> and as
>> I love Orocos I can't accept it can't
>> conquer the world :p
>>
>> It should conquer only a small piece of the world,
>> but conquer that niche
>> without leaving any room for competition :-)
>>
>> I totally agree on the fact it is not
>> the job of Orocos developpers to
>> provide
>> such "users components".
>>
>> It _is_, but then only for a small set of proven,
>> best practice components!
>>
>> It absolutely is the developer's responsibility - if you
>> want
>> the project
>> to last. Developers need to provide a framework within
>> which
>> new users
>> can rapidly get used to a system. Without fostering your
>> user
>> base,
>> projects die. New users need solid system examples of how
>> to
>> use Orocos
>> in a system. No such example exists. This leaves new
>> users
>> foundering
>> without direction, leading them to seek alternatives. I
>> know
>> groups
>> who've already done this.
>>
>> At Leuven, we have been playing (but not much more,
>> unfortunately) with
>> the
>> idea of providing the "motion stack" packaged with a Blender
>> Python script
>> that makes a Blender simulation work as a simple "RTT
>> component". In this
>> way, we could provide an "Hello robot!" example that runs out
>> of the box
>> on
>> all major platforms, without users needing to have a real
>> robot. I know it
>> is time to stop playing and become serious...
>>
>> It was not my aim to provoque a 1.x versus 2.x discussion, so
>> let's me recall
>> the first subject of this thread :
>> "What is the place for user contributions"
>>
>> When I say "user contribution" I am not speaking about code
>> report or
>> documentation improvment, I am speaking about sharing what you
>> do __with__
>> orocos. I quote Klaas's point of view :
>> "Suppose (purely hypothetical) I (not referring to myself, but
>> rather to some a
>> industrial company using orocos) am an orocos 1.x user, that
>> invested (quite?)
>> some effort in getting the 1.x series where they are now and
>> learning some new
>> tools. I am not being paid to work _on_ orocos, but to do
>> something useful
>> _with_ orocos."
>>
>> I am beginning a robot project that will maybe live during 5
>> years (crossed
>> fingers). I will do or redo what's all roboticians have to do
>> in a first step
>> (with no hudge interest for me) : interfacing harware. I am
>> keen to share my
>> stuff. But there is no way I set up I full project for
>> becoming an Orocos
>> distributor (yet ?! ^^ ).
>>
>> Herman, for you motion stack you should have exactly the same
>> question as I :
>> "Where on the hell may I share this very user-usefull stuff as
>> it can be seen on
>> the Orocos community easily ?"
>> It is that kind of user contributions that'll provoque user
>> gathering to create
>> distributions. But there is no "how to become a distributor"
>> page on Orocos,
>> neither than "what could be a distribution of Orocos". IMO (to
>> my very young use
>> of linux 2.6 Herman :p), a distribution in linux is a pick and
>> choose of
>> existing applications. That does mean it exists users before
>> distributors.
>>
>> At the end I bumped into : "Components built by users of
>> Orocos are hosted in
>> their own repositories." on the
>> http://www.orocos.org/toolchain page. So here is
>> my answer. OCL has turned into the tools you need to monitor
>> your application
>> (taskbrowser, logs , ...) and I may understand this. And if I
>> want to share my
>> stuff it's my problem (so I won't because I am keen to share
>> not to set up a
>> sharing system). In practice I will go with the ROS sharing
>> system
>> http://www.ros.org/wiki/ because I don't have anything to do.
>> I think it's a
>> pity for Orocos not to have an equivalent but anyway.
>> Of course it is a pity. But it is all a matter of resources.
>> Not only, it is also a problem of communication, there is nowhere I can found
>> "Help us in doing this, whe don't have the time and would be pleased to
>> integrate new ".
>>
>> People can
>> (rightfully) keep on asking for a user distribution, and I will
>> support
>> them in this claim, but the pragmatic reality of open source
>> projects is
>> that the required efforts should come somewhere from the community.
>> The
>> current developers do not have the means to take up yet another
>> responsibility, however useful and needed that might.
>>
>> Hence, to all Orocos _users_ I can only say this: "It's time to ask
>> what you
>> can do for the community, and not what the community can do for
>> you!"
>> I already asked me this question (that's why I am spending time in this thread).
>> Once again and related to what Stephen refered to, the "Contribute" web page on
>> the website is a must have to help this transistion.
>> But as a "Component Builder" my first logical answer is ok, I may be a
>> "Component Sharer" in a distribution.
>> There is still something missing in the chain as you expect more than this. You
>> expect them to become "Distributors"
>>
>>
>> Maybe I should reformulate like "Does anyone in the
>> Orocos community is keen on
>> setting up a component sharing system or to create an
>> 'Ocoros Hardware Library'
>> ?" I hope there is some pleople in the Orocos core that
>> wish to do so or to help
>> in this, because if not I don't think Orocos will live
>> long.
>> Don't worry about the 'developers part' of the project! :-)
>>
>> To finish with, there is a difference between : "we
>> don't have time to integrate
>> the Orocos Component Builder community and we 'recruit'
>> people to do so" and "we
>> don't care of Orocos Component Builder community it is
>> not our job". Separating
>> concepts between the core (rtt,ocl, ...) and the
>> satellites (DFKI, Orocos
>> Hardware Library, ...) is natural. Waiting for other to
>> wake up a morning saying
>> "Okay I'll become an Orocos distributor" is utopic.
>> Why? It has been done dozens of times before. Red Hat, Canonical, Debian,
>> ... where not started by developers, but by (power) users, with the same
>> concern as the ones that have been raised on this thread.
>> Because it is very hard to be a power user in Orocos since it's hard to become a
>> user and somehow (but I am sure it is not the real current case) you are not
>> interested in user but distributors.
>
> Orocos users are, by definition at this moment, _power users_. Or they have
> to have a high level of power userness in them :-) I do not think that that
> is going to change a lot (in RTT at least, and to a somewhat lesser extent
> in BFL and KDl), since Orocos has been focusing on the very difficult
> stuff, and not without success. I repeat that I am not at all against
> adding layers on top of the Orocos project, but maybe, just maybe, that is
> better done in separate, integrated projects. Like what is already
> happening with the Orocos-ROS integration.
>
> But although ROS is the closest thing we have in robotics as far as
> "distributions" go, you also notice the huge difficulties the ROS community
> has in "doing it right", especially in keeping evolving versions of
> sub-projects in sync. (For example, the state of KDL in ROS.) I am not at
> all blaming the ROS community, since I very well understand the huge
> efforts involved. And I do not think that Orocos should start its own
> "ROS"-like effort: I have always been in favour of reusing existing
> efforts! Even when they are not perfect, since who are we to do that
> distributor effort better than the (much larger) ROS community...? Many
> Orocos developers have already contributed to ROS in that way, providing
> packages, sending patches for the ROS toolchain, etc.
That sounds like something for the roadmap then.
>> Herman, you did not answer to my question (that I did not formulate as a
>> question :p) :
>> What is the official position in the Orocos project between :
>> _ "We have no more ressources and would love to have new developpers to help
>> into bringing up a distribution into the Orocos project"
>> _ "We think doing a distribution is not a part of the Orocos project and would
>> love that a new independant project hold this"
>> ?
>
> I am very surprised to see you formulate things using a wording like "what
> is the official position"...? Orocos is an open source project, so there
> _is_ no official position! I give my ideas, others give theirs, and then
> some common dynamics is maybe set into action to change things. None of
> this is following an official, top-down decision process. If there are some
> concrete actions to reinstate "OCL" as a user-centric part of the project,
> I am sure that Peter Soetens (and the other Orocos sub-project maintainers)
> will consider and discuss these suggestions very carefully, critically and
> respectfully.
LOL ... you _are_ the defacto voice of the official position, Herman. I understand that you don't want to be, but because you are the most vocal, and nearly the only, voice coming from Kuleuven, you are speaking as the most official user out there. If you don't like it, get others involved in the discussion. And like Willy said, you are at the top of the Authors file.
It also seems, Herman, that you brush off much of the discussion by saying "that is just open source, deal with it". Ok, fine. Put your money where your mouth is. If _you_ want this project to blossom, to grow, then put _your_ words on paper (so to speak). You make large claims about where you think Orocos should go, how it should be, how users and distributors should work. Go put it on the Roadmap page. Don't hide behind a "lack of resources" argument, or that you "aren't the official voice". You have some wonderful vision about where this project should go. Share it with the community (present and future). It doesn't have to be concrete. Hell, it doesn't even have to be the "official position" (after all, my words are on the Roadmap page, and I most certainly are not "official"). This is a wiki, this is open source, and it can and will change later.
I have noted three (3) general topics that you have recently commented on, w.r.t the future of Orocos
- separation of transports into a sub-project
- use of ROS as a "distribution"
- user-contributed code
You ask what the community can do. I ask, what can you do for the community. You have great ideas. Share them. Write them down. Update the wiki.
http://www.orocos.org/wiki/orocos/toolchain/contributing
http://www.orocos.org/wiki/orocos/toolchain/roadmap
Cheers
Stephen
The place for sharing users component
On Sun, 27 Feb 2011, S Roderick wrote:
[...]
>>> Herman, you did not answer to my question (that I did not formulate as a
>>> question :p) :
>>> What is the official position in the Orocos project between :
>>> _ "We have no more ressources and would love to have new developpers to help
>>> into bringing up a distribution into the Orocos project"
>>> _ "We think doing a distribution is not a part of the Orocos project and would
>>> love that a new independant project hold this"
>>> ?
>>
>> I am very surprised to see you formulate things using a wording like "what
>> is the official position"...? Orocos is an open source project, so there
>> _is_ no official position! I give my ideas, others give theirs, and then
>> some common dynamics is maybe set into action to change things. None of
>> this is following an official, top-down decision process. If there are some
>> concrete actions to reinstate "OCL" as a user-centric part of the project,
>> I am sure that Peter Soetens (and the other Orocos sub-project maintainers)
>> will consider and discuss these suggestions very carefully, critically and
>> respectfully.
>
> LOL ... you _are_ the defacto voice of the official position, Herman.
If that is true, I want to resign immediately from that position! :-)
> I
> understand that you don't want to be, but because you are the most vocal,
> and nearly the only, voice coming from Kuleuven, you are speaking as the
> most official user out there. If you don't like it, get others involved
> in the discussion. And like Willy said, you are at the top of the Authors
> file.
Fine, but that's a reflection of the _past_. This (useful) discussion is
about the _future_. And one nice property of open source projects is that
they (should) not have much respect for the past, as soon as that past is a
hinderance for the future... I still have the ambition to be useful for
Orocos' future, but (I think) I am still lucid enough to see when the
community is moving faster and better than me, and to retire :-)
> It also seems, Herman, that you brush off much of the discussion by
> saying "that is just open source, deal with it". Ok, fine. Put your money
> where your mouth is. If _you_ want this project to blossom, to grow, then
> put _your_ words on paper (so to speak). You make large claims about
> where you think Orocos should go, how it should be, how users and
> distributors should work. Go put it on the Roadmap page. Don't hide
> behind a "lack of resources" argument, or that you "aren't the official
> voice". You have some wonderful vision about where this project should
> go. Share it with the community (present and future). It doesn't have to
> be concrete. Hell, it doesn't even have to be the "official position"
> (after all, my words are on the Roadmap page, and I most certainly are
> not "official"). This is a wiki, this is open source, and it can and will
> change later.
> I have noted three (3) general topics that you have recently commented
> on, w.r.t the future of Orocos
> - separation of transports into a sub-project
> - use of ROS as a "distribution"
> - user-contributed code
>
> You ask what the community can do. I ask, what can you do for the
> community. You have great ideas. Share them. Write them down. Update the
> wiki.
>
> http://www.orocos.org/wiki/orocos/toolchain/contributing
> http://www.orocos.org/wiki/orocos/toolchain/roadmap
>
> Cheers
> Stephen
Good! Done! <http://www.orocos.org/wiki/orocos/roadmap-ideas-3x>
Thanks for pushing me! I needed that... :-)
Now, part of the ball is in the "users" camp again :-)
Herman
The place for sharing users component
2011/2/27 Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...>
> On Sun, 27 Feb 2011, S Roderick wrote:
>
> [...]
>
> Herman, you did not answer to my question (that I did not formulate as a
>>>> question :p) :
>>>> What is the official position in the Orocos project between :
>>>> _ "We have no more ressources and would love to have new developpers to
>>>> help
>>>> into bringing up a distribution into the Orocos project"
>>>> _ "We think doing a distribution is not a part of the Orocos project and
>>>> would
>>>> love that a new independant project hold this"
>>>> ?
>>>>
>>>
>>> I am very surprised to see you formulate things using a wording like
>>> "what
>>> is the official position"...? Orocos is an open source project, so there
>>> _is_ no official position! I give my ideas, others give theirs, and then
>>> some common dynamics is maybe set into action to change things. None of
>>> this is following an official, top-down decision process. If there are
>>> some
>>> concrete actions to reinstate "OCL" as a user-centric part of the
>>> project,
>>> I am sure that Peter Soetens (and the other Orocos sub-project
>>> maintainers)
>>> will consider and discuss these suggestions very carefully, critically
>>> and
>>> respectfully.
>>>
>>
>> LOL ... you _are_ the defacto voice of the official position, Herman.
>>
>
> If that is true, I want to resign immediately from that position! :-)
>
>
> I
>> understand that you don't want to be, but because you are the most vocal,
>> and nearly the only, voice coming from Kuleuven, you are speaking as the
>> most official user out there. If you don't like it, get others involved
>> in the discussion. And like Willy said, you are at the top of the Authors
>> file.
>>
>
> Fine, but that's a reflection of the _past_. This (useful) discussion is
> about the _future_. And one nice property of open source projects is that
> they (should) not have much respect for the past, as soon as that past is a
> hinderance for the future... I still have the ambition to be useful for
> Orocos' future, but (I think) I am still lucid enough to see when the
> community is moving faster and better than me, and to retire :-)
>
>
> It also seems, Herman, that you brush off much of the discussion by
>> saying "that is just open source, deal with it". Ok, fine. Put your money
>> where your mouth is. If _you_ want this project to blossom, to grow, then
>> put _your_ words on paper (so to speak). You make large claims about
>> where you think Orocos should go, how it should be, how users and
>> distributors should work. Go put it on the Roadmap page. Don't hide
>> behind a "lack of resources" argument, or that you "aren't the official
>> voice". You have some wonderful vision about where this project should
>> go. Share it with the community (present and future). It doesn't have to
>> be concrete. Hell, it doesn't even have to be the "official position"
>> (after all, my words are on the Roadmap page, and I most certainly are
>> not "official"). This is a wiki, this is open source, and it can and will
>> change later.
>> I have noted three (3) general topics that you have recently commented
>> on, w.r.t the future of Orocos
>> - separation of transports into a sub-project
>> - use of ROS as a "distribution"
>> - user-contributed code
>>
>> You ask what the community can do. I ask, what can you do for the
>> community. You have great ideas. Share them. Write them down. Update the
>> wiki.
>>
>> http://www.orocos.org/wiki/orocos/toolchain/contributing
>> http://www.orocos.org/wiki/orocos/toolchain/roadmap
>>
>> Cheers
>> Stephen
>>
>
> Good! Done! <http://www.orocos.org/wiki/orocos/roadmap-ideas-3x>
> Thanks for pushing me! I needed that... :-)
>
this is great espacially the little "who may contribute here" statement at
the end of each section.
There is no place for hardware in this roadmap ideas. Relatively to the
publication we can found at http://gearbox.sourceforge.net/ , I refer to the
"glue" you make to interface a driver (as high level as possible,
CanFestival is a nice exemple for CANOpen communication I think), not to
write drivers in Orocos. It would be the same for "massively" used stuff
like Hokuyos, Kinects, etc, ... I think Orocos is good at interfacing
Hardware in a real time way and this should not be forgotten. I don't Have
anything to propose concretely, but I may expose what I think to be a miss.
>
> Now, part of the ball is in the "users" camp again :-)
>
> Herman
>
The place for sharing users component
2011/2/27 Willy Lambert <lambert [dot] willy [..] ...>
>
>
> 2011/2/27 Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...>
>
>> On Sun, 27 Feb 2011, S Roderick wrote:
>>
>>
>> [...]
>>
>> Herman, you did not answer to my question (that I did not formulate as a
>>>>> question :p) :
>>>>> What is the official position in the Orocos project between :
>>>>> _ "We have no more ressources and would love to have new developpers to
>>>>> help
>>>>> into bringing up a distribution into the Orocos project"
>>>>> _ "We think doing a distribution is not a part of the Orocos project
>>>>> and would
>>>>> love that a new independant project hold this"
>>>>> ?
>>>>>
>>>>
>>>> I am very surprised to see you formulate things using a wording like
>>>> "what
>>>> is the official position"...? Orocos is an open source project, so there
>>>> _is_ no official position! I give my ideas, others give theirs, and then
>>>> some common dynamics is maybe set into action to change things. None of
>>>> this is following an official, top-down decision process. If there are
>>>> some
>>>> concrete actions to reinstate "OCL" as a user-centric part of the
>>>> project,
>>>> I am sure that Peter Soetens (and the other Orocos sub-project
>>>> maintainers)
>>>> will consider and discuss these suggestions very carefully, critically
>>>> and
>>>> respectfully.
>>>>
>>>
>>> LOL ... you _are_ the defacto voice of the official position, Herman.
>>>
>>
>> If that is true, I want to resign immediately from that position! :-)
>>
>>
>> I
>>> understand that you don't want to be, but because you are the most vocal,
>>> and nearly the only, voice coming from Kuleuven, you are speaking as the
>>> most official user out there. If you don't like it, get others involved
>>> in the discussion. And like Willy said, you are at the top of the Authors
>>> file.
>>>
>>
>> Fine, but that's a reflection of the _past_. This (useful) discussion is
>> about the _future_. And one nice property of open source projects is that
>> they (should) not have much respect for the past, as soon as that past is
>> a
>> hinderance for the future... I still have the ambition to be useful for
>> Orocos' future, but (I think) I am still lucid enough to see when the
>> community is moving faster and better than me, and to retire :-)
>>
>>
>> It also seems, Herman, that you brush off much of the discussion by
>>> saying "that is just open source, deal with it". Ok, fine. Put your money
>>> where your mouth is. If _you_ want this project to blossom, to grow, then
>>> put _your_ words on paper (so to speak). You make large claims about
>>> where you think Orocos should go, how it should be, how users and
>>> distributors should work. Go put it on the Roadmap page. Don't hide
>>> behind a "lack of resources" argument, or that you "aren't the official
>>> voice". You have some wonderful vision about where this project should
>>> go. Share it with the community (present and future). It doesn't have to
>>> be concrete. Hell, it doesn't even have to be the "official position"
>>> (after all, my words are on the Roadmap page, and I most certainly are
>>> not "official"). This is a wiki, this is open source, and it can and will
>>> change later.
>>> I have noted three (3) general topics that you have recently commented
>>> on, w.r.t the future of Orocos
>>> - separation of transports into a sub-project
>>> - use of ROS as a "distribution"
>>> - user-contributed code
>>>
>>> You ask what the community can do. I ask, what can you do for the
>>> community. You have great ideas. Share them. Write them down. Update the
>>> wiki.
>>>
>>> http://www.orocos.org/wiki/orocos/toolchain/contributing
>>> http://www.orocos.org/wiki/orocos/toolchain/roadmap
>>>
>>> Cheers
>>> Stephen
>>>
>>
>> Good! Done! <http://www.orocos.org/wiki/orocos/roadmap-ideas-3x>
>> Thanks for pushing me! I needed that... :-)
>>
>
> this is great espacially the little "who may contribute here" statement at
> the end of each section.
>
> There is no place for hardware in this roadmap ideas. Relatively to the
> publication we can found at http://gearbox.sourceforge.net/ , I refer to
> the "glue" you make to interface a driver (as high level as possible,
> CanFestival is a nice exemple for CANOpen communication I think), not to
> write drivers in Orocos. It would be the same for "massively" used stuff
> like Hokuyos, Kinects, etc, ... I think Orocos is good at interfacing
> Hardware in a real time way and this should not be forgotten. I don't Have
> anything to propose concretely, but I may expose what I think to be a miss.
>
>
To push up a bit, In the launch details of Orocos (
http://cordis.europa.eu/fetch?ACTION=D&CALLER=PROJ_IST&QM_EP_RCN_A=58069) I
read :
The specific modules that will make up the presented bottom-up
implementation approach are:
- Real-time servo control: To detect, classify, design and implement the
software patterns needed in the hard real-time motion control kernel of a
robot controller.
- Sensor device drivers: To design generic templates for robot sensor device
drivers, and to implement drivers for the most commonly used sensors.
- Sensor processing libraries: To design and implement libraries with
advanced sensor processing functionality for the most commonly used sensors.
- Robot kinematics and dynamics: To design and implement libraries for robot
kinematics and dynamics, with an eye on extensions to general-purpose
multi-body dynamics simulators.
- Component brokers: To design and implement the robotics-oriented component
services that are not yet available in existing open source CORBA
implementations; in particular, light-weight, small-scale and real-time
brokerage services are needed, for use in tightly coupled distributed robot
systems.
Has the driver part disappeared ?
(as a disclaimer Herman, I know an open source project aim to evolve and its
beginnings may be out of date, but maybe not ...)
>
>> Now, part of the ball is in the "users" camp again :-)
>>
>> Herman
>>
>
>
The place for sharing users component
On Mon, 28 Feb 2011, Willy Lambert wrote:
>lambert [dot] willy [..] ...>>Herman [dot] Bruyninckx [..] ...>>
>
> 2011/2/27 Willy Lambert <lambert [dot] willy [..] ...
>
>
> 2011/2/27 Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...
> On Sun, 27 Feb 2011, S Roderick wrote:
>
>
> [...]
>
> Herman, you did not answer to my question (that I did not formulate as a
> question :p) :
> What is the official position in the Orocos project between :
> _ "We have no more ressources and would love to have new developpers to help
> into bringing up a distribution into the Orocos project"
> _ "We think doing a distribution is not a part of the Orocos project and would
> love that a new independant project hold this"
> ?
>
> I am very surprised to see you formulate things using a wording like "what
> is the official position"...? Orocos is an open source project, so there
> _is_ no official position! I give my ideas, others give theirs, and then
> some common dynamics is maybe set into action to change things. None of
> this is following an official, top-down decision process. If there are some
> concrete actions to reinstate "OCL" as a user-centric part of the project,
> I am sure that Peter Soetens (and the other Orocos sub-project maintainers)
> will consider and discuss these suggestions very carefully, critically and
> respectfully.
>
> LOL ... you _are_ the defacto voice of the official position, Herman.
>
> If that is true, I want to resign immediately from that position! :-)
>
>
> I
> understand that you don't want to be, but because you are the most vocal,
> and nearly the only, voice coming from Kuleuven, you are speaking as the
> most official user out there. If you don't like it, get others involved
> in the discussion. And like Willy said, you are at the top of the Authors
> file.
>
> Fine, but that's a reflection of the _past_. This (useful) discussion is
> about the _future_. And one nice property of open source projects is that
> they (should) not have much respect for the past, as soon as that past is a
> hinderance for the future... I still have the ambition to be useful for
> Orocos' future, but (I think) I am still lucid enough to see when the
> community is moving faster and better than me, and to retire :-)
>
>
> It also seems, Herman, that you brush off much of the discussion by
> saying "that is just open source, deal with it". Ok, fine. Put your money
> where your mouth is. If _you_ want this project to blossom, to grow, then
> put _your_ words on paper (so to speak). You make large claims about
> where you think Orocos should go, how it should be, how users and
> distributors should work. Go put it on the Roadmap page. Don't hide
> behind a "lack of resources" argument, or that you "aren't the official
> voice". You have some wonderful vision about where this project should
> go. Share it with the community (present and future). It doesn't have to
> be concrete. Hell, it doesn't even have to be the "official position"
> (after all, my words are on the Roadmap page, and I most certainly are
> not "official"). This is a wiki, this is open source, and it can and will
> change later.
> I have noted three (3) general topics that you have recently commented
> on, w.r.t the future of Orocos
> - separation of transports into a sub-project
> - use of ROS as a "distribution"
> - user-contributed code
>
> You ask what the community can do. I ask, what can you do for the
> community. You have great ideas. Share them. Write them down. Update the
> wiki.
>
> http://www.orocos.org/wiki/orocos/toolchain/contributing
> http://www.orocos.org/wiki/orocos/toolchain/roadmap
>
> Cheers
> Stephen
>
> Good! Done! <http://www.orocos.org/wiki/orocos/roadmap-ideas-3x>
> Thanks for pushing me! I needed that... :-)
>
> this is great espacially the little "who may contribute here" statement at the end of each section.
>
> There is no place for hardware in this roadmap ideas. Relatively to the publication we can found at http://gearbox.sourceforge.net/ , I refer to the "glue" you make to interface a driver (as high level as possible, CanFestival is a nice exemple for CANOpen communication I think), not to write drivers in Orocos. It would be the same for "massively" used stuff like Hokuyos, Kinects, etc, ... I think Orocos is good at interfacing Hardware in a real time way and this should not be forgotten. I don't Have anything to propose concretely, but I may expose what I think to be a miss.
>
>
> To push up a bit, In the launch details of Orocos (http://cordis.europa.eu/fetch?ACTION=D&CALLER=PROJ_IST&QM_EP_RCN_A=58069) I read :
> The specific modules that will make up the presented bottom-up implementation approach are:
> - Real-time servo control: To detect, classify, design and implement the software patterns needed in the hard real-time motion control kernel of a robot controller.
> - Sensor device drivers: To design generic templates for robot sensor device drivers, and to implement drivers for the most commonly used sensors.
> - Sensor processing libraries: To design and implement libraries with advanced sensor processing functionality for the most commonly used sensors.
> - Robot kinematics and dynamics: To design and implement libraries for robot kinematics and dynamics, with an eye on extensions to general-purpose multi-body dynamics simulators.
> - Component brokers: To design and implement the robotics-oriented component services that are not yet available in existing open source CORBA implementations; in particular, light-weight, small-scale and real-time brokerage services are needed, for use in tightly coupled distributed robot systems.
>
> Has the driver part disappeared ?
Of course, since other projects (Linux kernel, Comedi, SOEM EtherCat
master,...) are doing a much better job than what orocos could do on its
own. The real next step, to be taken by the _whole_ robotics community, is
to come up with abstract interfaces to all the relevant hardware.
> (as a disclaimer Herman, I know an open source project aim to evolve and
> its beginnings may be out of date, but maybe not ...)
>
>
> Now, part of the ball is in the "users" camp again :-)
Herman
The place for sharing users component
2011/2/28 Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...>
> On Mon, 28 Feb 2011, Willy Lambert wrote:
>
>
>>
>> 2011/2/27 Willy Lambert <lambert [dot] willy [..] ...
>>
>>
>> 2011/2/27 Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...
>>
>> On Sun, 27 Feb 2011, S Roderick wrote:
>>
>>
>> [...]
>>
>> Herman, you did not answer to my question (that I did not formulate as a
>> question :p) :
>> What is the official position in the Orocos project between :
>> _ "We have no more ressources and would love to have new developpers to
>> help
>> into bringing up a distribution into the Orocos project"
>> _ "We think doing a distribution is not a part of the Orocos project and
>> would
>> love that a new independant project hold this"
>> ?
>>
>> I am very surprised to see you formulate things using a wording like "what
>> is the official position"...? Orocos is an open source project, so there
>> _is_ no official position! I give my ideas, others give theirs, and then
>> some common dynamics is maybe set into action to change things. None of
>> this is following an official, top-down decision process. If there are
>> some
>> concrete actions to reinstate "OCL" as a user-centric part of the project,
>> I am sure that Peter Soetens (and the other Orocos sub-project
>> maintainers)
>> will consider and discuss these suggestions very carefully, critically and
>> respectfully.
>>
>> LOL ... you _are_ the defacto voice of the official position, Herman.
>>
>> If that is true, I want to resign immediately from that position! :-)
>>
>>
>> I
>> understand that you don't want to be, but because you are the most vocal,
>> and nearly the only, voice coming from Kuleuven, you are speaking as the
>> most official user out there. If you don't like it, get others involved
>> in the discussion. And like Willy said, you are at the top of the Authors
>> file.
>>
>> Fine, but that's a reflection of the _past_. This (useful) discussion is
>> about the _future_. And one nice property of open source projects is that
>> they (should) not have much respect for the past, as soon as that past is
>> a
>> hinderance for the future... I still have the ambition to be useful for
>> Orocos' future, but (I think) I am still lucid enough to see when the
>> community is moving faster and better than me, and to retire :-)
>>
>>
>> It also seems, Herman, that you brush off much of the discussion by
>> saying "that is just open source, deal with it". Ok, fine. Put your money
>> where your mouth is. If _you_ want this project to blossom, to grow, then
>> put _your_ words on paper (so to speak). You make large claims about
>> where you think Orocos should go, how it should be, how users and
>> distributors should work. Go put it on the Roadmap page. Don't hide
>> behind a "lack of resources" argument, or that you "aren't the official
>> voice". You have some wonderful vision about where this project should
>> go. Share it with the community (present and future). It doesn't have to
>> be concrete. Hell, it doesn't even have to be the "official position"
>> (after all, my words are on the Roadmap page, and I most certainly are
>> not "official"). This is a wiki, this is open source, and it can and will
>> change later.
>> I have noted three (3) general topics that you have recently commented
>> on, w.r.t the future of Orocos
>> - separation of transports into a sub-project
>> - use of ROS as a "distribution"
>> - user-contributed code
>>
>> You ask what the community can do. I ask, what can you do for the
>> community. You have great ideas. Share them. Write them down. Update the
>> wiki.
>>
>> http://www.orocos.org/wiki/orocos/toolchain/contributing
>> http://www.orocos.org/wiki/orocos/toolchain/roadmap
>>
>> Cheers
>> Stephen
>>
>> Good! Done! <http://www.orocos.org/wiki/orocos/roadmap-ideas-3x>
>> Thanks for pushing me! I needed that... :-)
>>
>> this is great espacially the little "who may contribute here" statement at
>> the end of each section.
>>
>> There is no place for hardware in this roadmap ideas. Relatively to the
>> publication we can found at http://gearbox.sourceforge.net/ , I refer to
>> the "glue" you make to interface a driver (as high level as possible,
>> CanFestival is a nice exemple for CANOpen communication I think), not to
>> write drivers in Orocos. It would be the same for "massively" used stuff
>> like Hokuyos, Kinects, etc, ... I think Orocos is good at interfacing
>> Hardware in a real time way and this should not be forgotten. I don't Have
>> anything to propose concretely, but I may expose what I think to be a miss.
>>
>>
>> To push up a bit, In the launch details of Orocos (
>> http://cordis.europa.eu/fetch?ACTION=D&CALLER=PROJ_IST&QM_EP_RCN_A=58069)
>> I read :
>> The specific modules that will make up the presented bottom-up
>> implementation approach are:
>> - Real-time servo control: To detect, classify, design and implement the
>> software patterns needed in the hard real-time motion control kernel of a
>> robot controller.
>> - Sensor device drivers: To design generic templates for robot sensor
>> device drivers, and to implement drivers for the most commonly used sensors.
>> - Sensor processing libraries: To design and implement libraries with
>> advanced sensor processing functionality for the most commonly used sensors.
>> - Robot kinematics and dynamics: To design and implement libraries for
>> robot kinematics and dynamics, with an eye on extensions to general-purpose
>> multi-body dynamics simulators.
>> - Component brokers: To design and implement the robotics-oriented
>> component services that are not yet available in existing open source CORBA
>> implementations; in particular, light-weight, small-scale and real-time
>> brokerage services are needed, for use in tightly coupled distributed robot
>> systems.
>>
>> Has the driver part disappeared ?
>>
>
> Of course, since other projects (Linux kernel, Comedi, SOEM EtherCat
> master,...) are doing a much better job than what orocos could do on its
> own. The real next step, to be taken by the _whole_ robotics community, is
> to come up with abstract interfaces to all the relevant hardware.
>
>
I agree on that Orocos don't have to write __driver__ code, but the glue
code to interface this other project into Orocos (it's a wrapper work) is
the Orocos job no ? For Comedi it was done in OCL v1 and as we saw on the
list, it is has been usefull to some users.
The decision has been made to put this kind of interfacing work out of ocl,
ok, but shoudn't this code come back in another library ?
The whole robotics community is maybe not ready for abstracting hardware,
but it is not a reason for not providing harware interface in Orocos.
Isn't Orocos focused on realtime and performance ? The first client of this
are Hardware interfaces. For all non hardware stuff, there always exists
orocos-concurrent options.
IMO, it doesn't worth Orocos developer spend time into doing this
interfaces, but if you provide a place to do it i am sure user will populate
it.
The first example is DFKI stuff were hardware driver _and_ glue code to
Orocos already exists,but in a independant way.
Please don't answer thinking about ressources, and we'll see what we can
provide on the roadmaps about this.
>
> (as a disclaimer Herman, I know an open source project aim to evolve and
>> its beginnings may be out of date, but maybe not ...)
>>
>>
>> Now, part of the ball is in the "users" camp again :-)
>>
>
> Herman
>
The place for sharing users component
On Mon, 28 Feb 2011, Willy Lambert wrote:
[...]
> There is no place for hardware in this roadmap ideas. Relatively to the
> publication we can found at http://gearbox.sourceforge.net/ , I refer to
> the "glue" you make to interface a driver (as high level as possible,
> CanFestival is a nice exemple for CANOpen communication I think), not to
> write drivers in Orocos. It would be the same for "massively" used stuff
> like Hokuyos, Kinects, etc, ... I think Orocos is good at interfacing
> Hardware in a real time way and this should not be forgotten. I don't
> Have anything to propose concretely, but I may expose what I think to be
> a miss.
>
>
> To push up a bit, In the launch details of Orocos
> (http://cordis.europa.eu/fetch?ACTION=D&CALLER=PROJ_IST&QM_EP_RCN_A=58069)
> I read :
> The specific modules that will make up the presented bottom-up
> implementation approach are:
> - Real-time servo control: To detect, classify, design and implement the
> software patterns needed in the hard real-time motion control kernel of
> a robot controller.
> - Sensor device drivers: To design generic templates for robot sensor
> device drivers, and to implement drivers for the most commonly used
> sensors.
> - Sensor processing libraries: To design and implement libraries with
> advanced sensor processing functionality for the most commonly used
> sensors.
> - Robot kinematics and dynamics: To design and implement libraries for
> robot kinematics and dynamics, with an eye on extensions to
> general-purpose multi-body dynamics simulators.
> - Component brokers: To design and implement the robotics-oriented
> component services that are not yet available in existing open source
> CORBA implementations; in particular, light-weight, small-scale and
> real-time brokerage services are needed, for use in tightly coupled
> distributed robot systems.
>
> Has the driver part disappeared ?
>
>
> Of course, since other projects (Linux kernel, Comedi, SOEM EtherCat
> master,...) are doing a much better job than what orocos could do on its
> own. The real next step, to be taken by the _whole_ robotics community, is
> to come up with abstract interfaces to all the relevant hardware.
>
>
> I agree on that Orocos don't have to write __driver__ code, but the glue code to
> interface this other project into Orocos (it's a wrapper work) is the Orocos job no
> ? For Comedi it was done in OCL v1 and as we saw on the list, it is has been usefull
> to some users.
>
> The decision has been made to put this kind of interfacing work out of ocl, ok, but
> shoudn't this code come back in another library ?
If enough users need this, and want to put effort in keeping the thing
maintained, it would indeed be a useful thing to have. The decision to
remove it was hopefully temporary, and in the hope of provoking enough
"itches to scratch" in the community in order that some motivated people
pick this task up again.
> The whole robotics community is maybe not ready for abstracting hardware,
> but it is not a reason for not providing harware interface in Orocos.
>
> Isn't Orocos focused on realtime and performance ? The first client of this are
> Hardware interfaces. For all non hardware stuff, there always exists
> orocos-concurrent options.
>
> IMO, it doesn't worth Orocos developer spend time into doing this
> interfaces, but if you provide a place to do it i am sure user will
> populate it.
The Orocos git is there to be used.
Contributions should however be preceded by a good discussion on the
mailing list in order to decide what functionality exactly is required to
be kept in Orocos, and what functionality is too general for Orocos and
should be put into another project.
> The first example is DFKI stuff were hardware driver _and_ glue code to Orocos
> already exists,but in a independant way.
> Please don't answer thinking about ressources, and we'll see what we can provide on
> the roadmaps about this.
Herman
The place for sharing users component
2011/2/28 Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...>
> On Mon, 28 Feb 2011, Willy Lambert wrote:
>
> [...]
>
> There is no place for hardware in this roadmap ideas. Relatively to the
>> publication we can found at http://gearbox.sourceforge.net/ , I refer to
>> the "glue" you make to interface a driver (as high level as possible,
>> CanFestival is a nice exemple for CANOpen communication I think), not to
>> write drivers in Orocos. It would be the same for "massively" used stuff
>> like Hokuyos, Kinects, etc, ... I think Orocos is good at interfacing
>> Hardware in a real time way and this should not be forgotten. I don't
>> Have anything to propose concretely, but I may expose what I think to be
>> a miss.
>>
>>
>> To push up a bit, In the launch details of Orocos
>> (http://cordis.europa.eu/fetch?ACTION=D&CALLER=PROJ_IST&QM_EP_RCN_A=58069
>> )
>> I read :
>> The specific modules that will make up the presented bottom-up
>> implementation approach are:
>> - Real-time servo control: To detect, classify, design and implement the
>> software patterns needed in the hard real-time motion control kernel of
>> a robot controller.
>> - Sensor device drivers: To design generic templates for robot sensor
>> device drivers, and to implement drivers for the most commonly used
>> sensors.
>> - Sensor processing libraries: To design and implement libraries with
>> advanced sensor processing functionality for the most commonly used
>> sensors.
>> - Robot kinematics and dynamics: To design and implement libraries for
>> robot kinematics and dynamics, with an eye on extensions to
>> general-purpose multi-body dynamics simulators.
>> - Component brokers: To design and implement the robotics-oriented
>> component services that are not yet available in existing open source
>> CORBA implementations; in particular, light-weight, small-scale and
>> real-time brokerage services are needed, for use in tightly coupled
>> distributed robot systems.
>>
>> Has the driver part disappeared ?
>>
>>
>> Of course, since other projects (Linux kernel, Comedi, SOEM EtherCat
>> master,...) are doing a much better job than what orocos could do on its
>> own. The real next step, to be taken by the _whole_ robotics community, is
>> to come up with abstract interfaces to all the relevant hardware.
>>
>>
>> I agree on that Orocos don't have to write __driver__ code, but the glue
>> code to
>> interface this other project into Orocos (it's a wrapper work) is the
>> Orocos job no
>> ? For Comedi it was done in OCL v1 and as we saw on the list, it is has
>> been usefull
>> to some users.
>>
>> The decision has been made to put this kind of interfacing work out of
>> ocl, ok, but
>> shoudn't this code come back in another library ?
>>
>
> If enough users need this, and want to put effort in keeping the thing
> maintained, it would indeed be a useful thing to have. The decision to
> remove it was hopefully temporary, and in the hope of provoking enough
> "itches to scratch" in the community in order that some motivated people
> pick this task up again.
Please to see you agree on the need. I'll think about this and provoke at
least more concrete discussion about this.
>
>
> The whole robotics community is maybe not ready for abstracting hardware,
>> but it is not a reason for not providing harware interface in Orocos.
>>
>> Isn't Orocos focused on realtime and performance ? The first client of
>> this are
>> Hardware interfaces. For all non hardware stuff, there always exists
>> orocos-concurrent options.
>>
>> IMO, it doesn't worth Orocos developer spend time into doing this
>> interfaces, but if you provide a place to do it i am sure user will
>> populate it.
>>
>
> The Orocos git is there to be used.
> Contributions should however be preceded by a good discussion on the
> mailing list in order to decide what functionality exactly is required to
> be kept in Orocos, and what functionality is too general for Orocos and
> should be put into another project.
yes git exists, since a place exists to hold the code user want to share.
>
>
> The first example is DFKI stuff were hardware driver _and_ glue code to
>> Orocos
>> already exists,but in a independant way.
>>
>
> Please don't answer thinking about ressources, and we'll see what we can
>> provide on
>> the roadmaps about this.
>>
>
> Herman
The place for sharing users component
On Feb 27, 2011, at 09:49 , Herman Bruyninckx wrote:
> On Sun, 27 Feb 2011, S Roderick wrote:
>
> [...]
>>>> Herman, you did not answer to my question (that I did not formulate as a
>>>> question :p) :
>>>> What is the official position in the Orocos project between :
>>>> _ "We have no more ressources and would love to have new developpers to help
>>>> into bringing up a distribution into the Orocos project"
>>>> _ "We think doing a distribution is not a part of the Orocos project and would
>>>> love that a new independant project hold this"
>>>> ?
>>>
>>> I am very surprised to see you formulate things using a wording like "what
>>> is the official position"...? Orocos is an open source project, so there
>>> _is_ no official position! I give my ideas, others give theirs, and then
>>> some common dynamics is maybe set into action to change things. None of
>>> this is following an official, top-down decision process. If there are some
>>> concrete actions to reinstate "OCL" as a user-centric part of the project,
>>> I am sure that Peter Soetens (and the other Orocos sub-project maintainers)
>>> will consider and discuss these suggestions very carefully, critically and
>>> respectfully.
>>
>> LOL ... you _are_ the defacto voice of the official position, Herman.
>
> If that is true, I want to resign immediately from that position! :-)
>
>> I
>> understand that you don't want to be, but because you are the most vocal,
>> and nearly the only, voice coming from Kuleuven, you are speaking as the
>> most official user out there. If you don't like it, get others involved
>> in the discussion. And like Willy said, you are at the top of the Authors
>> file.
>
> Fine, but that's a reflection of the _past_. This (useful) discussion is
> about the _future_. And one nice property of open source projects is that
> they (should) not have much respect for the past, as soon as that past is a
> hinderance for the future... I still have the ambition to be useful for
> Orocos' future, but (I think) I am still lucid enough to see when the
> community is moving faster and better than me, and to retire :-)
You don't get off that easy ... and you're not an old befuddled man yet ... ;-)
>> It also seems, Herman, that you brush off much of the discussion by
>> saying "that is just open source, deal with it". Ok, fine. Put your money
>> where your mouth is. If _you_ want this project to blossom, to grow, then
>> put _your_ words on paper (so to speak). You make large claims about
>> where you think Orocos should go, how it should be, how users and
>> distributors should work. Go put it on the Roadmap page. Don't hide
>> behind a "lack of resources" argument, or that you "aren't the official
>> voice". You have some wonderful vision about where this project should
>> go. Share it with the community (present and future). It doesn't have to
>> be concrete. Hell, it doesn't even have to be the "official position"
>> (after all, my words are on the Roadmap page, and I most certainly are
>> not "official"). This is a wiki, this is open source, and it can and will
>> change later.
>> I have noted three (3) general topics that you have recently commented
>> on, w.r.t the future of Orocos
>> - separation of transports into a sub-project
>> - use of ROS as a "distribution"
>> - user-contributed code
>>
>> You ask what the community can do. I ask, what can you do for the
>> community. You have great ideas. Share them. Write them down. Update the
>> wiki.
>>
>> http://www.orocos.org/wiki/orocos/toolchain/contributing
>> http://www.orocos.org/wiki/orocos/toolchain/roadmap
>>
>> Cheers
>> Stephen
>
> Good! Done! <http://www.orocos.org/wiki/orocos/roadmap-ideas-3x>
> Thanks for pushing me! I needed that... :-)
Fantastic!!! Thank you for addressing that so promptly. I updated the Roadmap page to link to your v3 page also.
> Now, part of the ball is in the "users" camp again :-)
Oh dear ... look what we started ... ;-)
S
The place for sharing users component
On Sun, 27 Feb 2011, Stephen Roderick wrote:
> On Feb 27, 2011, at 09:49 , Herman Bruyninckx wrote:
>
>> On Sun, 27 Feb 2011, S Roderick wrote:
>>
>> [...]
>>>>> Herman, you did not answer to my question (that I did not formulate as a
>>>>> question :p) :
>>>>> What is the official position in the Orocos project between :
>>>>> _ "We have no more ressources and would love to have new developpers to help
>>>>> into bringing up a distribution into the Orocos project"
>>>>> _ "We think doing a distribution is not a part of the Orocos project and would
>>>>> love that a new independant project hold this"
>>>>> ?
>>>>
>>>> I am very surprised to see you formulate things using a wording like "what
>>>> is the official position"...? Orocos is an open source project, so there
>>>> _is_ no official position! I give my ideas, others give theirs, and then
>>>> some common dynamics is maybe set into action to change things. None of
>>>> this is following an official, top-down decision process. If there are some
>>>> concrete actions to reinstate "OCL" as a user-centric part of the project,
>>>> I am sure that Peter Soetens (and the other Orocos sub-project maintainers)
>>>> will consider and discuss these suggestions very carefully, critically and
>>>> respectfully.
>>>
>>> LOL ... you _are_ the defacto voice of the official position, Herman.
>>
>> If that is true, I want to resign immediately from that position! :-)
>>
>>> I
>>> understand that you don't want to be, but because you are the most vocal,
>>> and nearly the only, voice coming from Kuleuven, you are speaking as the
>>> most official user out there. If you don't like it, get others involved
>>> in the discussion. And like Willy said, you are at the top of the Authors
>>> file.
>>
>> Fine, but that's a reflection of the _past_. This (useful) discussion is
>> about the _future_. And one nice property of open source projects is that
>> they (should) not have much respect for the past, as soon as that past is a
>> hinderance for the future... I still have the ambition to be useful for
>> Orocos' future, but (I think) I am still lucid enough to see when the
>> community is moving faster and better than me, and to retire :-)
>
> You don't get off that easy ... and you're not an old befuddled man yet ... ;-)
>
>>> It also seems, Herman, that you brush off much of the discussion by
>>> saying "that is just open source, deal with it". Ok, fine. Put your money
>>> where your mouth is. If _you_ want this project to blossom, to grow, then
>>> put _your_ words on paper (so to speak). You make large claims about
>>> where you think Orocos should go, how it should be, how users and
>>> distributors should work. Go put it on the Roadmap page. Don't hide
>>> behind a "lack of resources" argument, or that you "aren't the official
>>> voice". You have some wonderful vision about where this project should
>>> go. Share it with the community (present and future). It doesn't have to
>>> be concrete. Hell, it doesn't even have to be the "official position"
>>> (after all, my words are on the Roadmap page, and I most certainly are
>>> not "official"). This is a wiki, this is open source, and it can and will
>>> change later.
>>> I have noted three (3) general topics that you have recently commented
>>> on, w.r.t the future of Orocos
>>> - separation of transports into a sub-project
>>> - use of ROS as a "distribution"
>>> - user-contributed code
>>>
>>> You ask what the community can do. I ask, what can you do for the
>>> community. You have great ideas. Share them. Write them down. Update the
>>> wiki.
>>>
>>> http://www.orocos.org/wiki/orocos/toolchain/contributing
>>> http://www.orocos.org/wiki/orocos/toolchain/roadmap
>>>
>>> Cheers
>>> Stephen
>>
>> Good! Done! <http://www.orocos.org/wiki/orocos/roadmap-ideas-3x>
>> Thanks for pushing me! I needed that... :-)
>
> Fantastic!!! Thank you for addressing that so promptly. I updated the Roadmap page to link to your v3 page also.
>
>> Now, part of the ball is in the "users" camp again :-)
>
> Oh dear ... look what we started ... ;-)
Let me quote an old befuddled guy I met quite some decades ago for the first
time: "This is normal open source project dynamics!" :-)
> S
Herman
The place for sharing users component
2011/2/27 Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...>
> On Sun, 27 Feb 2011, Willy Lambert wrote:
>
>
>>
>> 2011/2/27 Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...>
>> On Sat, 26 Feb 2011, Willy Lambert wrote:
>>
>>
>>
>> 2011/2/23 Herman Bruyninckx
>> <Herman [dot] Bruyninckx [..] ...>
>> On Wed, 23 Feb 2011, S Roderick wrote:
>>
>> On Feb 22, 2011, at 15:29 , Herman Bruyninckx wrote:
>>
>> On Tue, 22 Feb 2011, Willy Lambert wrote:
>>
>> Hi all,
>>
>> I create a new thread because I think
>> it is not good to continue in an other
>> thread
>>
>> As I am beginning to interface my
>> hardware on my robot (especially my
>> CAN bus),
>> I wondered about where I could find
>> others components or publish my code
>> to help
>> others, I asked :
>> [...]where is the place
>> for such a
>> component ? is it the job
>> of OCL v2 ?
>>
>>
>> Peter's answer :
>> No. Create a package
>> repository similar to how
>> a ROS package tree works
>> (ie
>> identical :-) , and point
>> people to that repository.
>> You can use git or svn,
>> or whatever you feel most
>> comfortable with.
>>
>>
>> I do not agree with Peter completely: the original
>> idea of OCL (6-7 years
>> ago) was for it to become the place to collect
>> "best practice" solutions,
>> and only those. Because of a lack of insight in
>> what "best practice" really
>> means, OCL ended up in becoming the "wast basket"
>> of the Orocos project,
>> that is, the branch were everything got dumped
>> that did not nicely fit in
>> the core parts of the project's source tree :-(
>>
>> I think it is high time to resurrect OCL as "the"
>> place for users to go an
>> look for proven, documented, best practice
>> systems. I think this is to some
>> extent what you are also hinting at, isn't it?
>>
>>
>> I'm with Herman on this one. Orocos' biggest fault is
>> that it
>> is developer-centric, not user-centric. IMHO trimming
>> down OCL
>> was an example of this. The project is wonderful for
>> developers. It is tough to be a user in this ecosystem.
>>
>> In addition to that, Peter's suggestion for the
>> "ROS like" approach of
>> various, unreviewed code repositories also makes
>> sense. But the practice
>> proves that this becomes a chaotic bunch of bits
>> and pieces without any
>> quality control or guarantee. I think we should do
>> better with Orocos,
>> since there is a major difference between ROS and
>> Orocos: we want to be the
>> best possible solution in a small niche of
>> robotics.
>>
>>
>> I agree that there is, and should be, a distinction
>> between
>> best practice examples, and user-contributed code. But we
>> also
>> need examples of both.
>>
>> First of all, I am not complaining
>> about a miss, but trying to understand
>> what's
>> the Orocos roadmap about "community
>> integration". I think there is a lack
>> and as
>> I love Orocos I can't accept it can't
>> conquer the world :p
>>
>>
>> It should conquer only a small piece of the world,
>> but conquer that niche
>> without leaving any room for competition :-)
>>
>> I totally agree on the fact it is not
>> the job of Orocos developpers to
>> provide
>> such "users components".
>>
>>
>> It _is_, but then only for a small set of proven,
>> best practice components!
>>
>>
>> It absolutely is the developer's responsibility - if you
>> want
>> the project
>> to last. Developers need to provide a framework within
>> which
>> new users
>> can rapidly get used to a system. Without fostering your
>> user
>> base,
>> projects die. New users need solid system examples of how
>> to
>> use Orocos
>> in a system. No such example exists. This leaves new
>> users
>> foundering
>> without direction, leading them to seek alternatives. I
>> know
>> groups
>> who've already done this.
>>
>>
>> At Leuven, we have been playing (but not much more,
>> unfortunately) with
>> the
>> idea of providing the "motion stack" packaged with a Blender
>> Python script
>> that makes a Blender simulation work as a simple "RTT
>> component". In this
>> way, we could provide an "Hello robot!" example that runs out
>> of the box
>> on
>> all major platforms, without users needing to have a real
>> robot. I know it
>> is time to stop playing and become serious...
>>
>>
>>
>> It was not my aim to provoque a 1.x versus 2.x discussion, so
>> let's me recall
>> the first subject of this thread :
>> "What is the place for user contributions"
>>
>> When I say "user contribution" I am not speaking about code
>> report or
>> documentation improvment, I am speaking about sharing what you
>> do __with__
>> orocos. I quote Klaas's point of view :
>> "Suppose (purely hypothetical) I (not referring to myself, but
>> rather to some a
>> industrial company using orocos) am an orocos 1.x user, that
>> invested (quite?)
>> some effort in getting the 1.x series where they are now and
>> learning some new
>> tools. I am not being paid to work _on_ orocos, but to do
>> something useful
>> _with_ orocos."
>>
>> I am beginning a robot project that will maybe live during 5
>> years (crossed
>> fingers). I will do or redo what's all roboticians have to do
>> in a first step
>> (with no hudge interest for me) : interfacing harware. I am
>> keen to share my
>> stuff. But there is no way I set up I full project for
>> becoming an Orocos
>> distributor (yet ?! ^^ ).
>>
>> Herman, for you motion stack you should have exactly the same
>> question as I :
>> "Where on the hell may I share this very user-usefull stuff as
>> it can be seen on
>> the Orocos community easily ?"
>> It is that kind of user contributions that'll provoque user
>> gathering to create
>> distributions. But there is no "how to become a distributor"
>> page on Orocos,
>> neither than "what could be a distribution of Orocos". IMO (to
>> my very young use
>> of linux 2.6 Herman :p), a distribution in linux is a pick and
>> choose of
>> existing applications. That does mean it exists users before
>> distributors.
>>
>> At the end I bumped into : "Components built by users of
>> Orocos are hosted in
>> their own repositories." on the
>> http://www.orocos.org/toolchain page. So here is
>> my answer. OCL has turned into the tools you need to monitor
>> your application
>> (taskbrowser, logs , ...) and I may understand this. And if I
>> want to share my
>> stuff it's my problem (so I won't because I am keen to share
>> not to set up a
>> sharing system). In practice I will go with the ROS sharing
>> system
>> http://www.ros.org/wiki/ because I don't have anything to do.
>> I think it's a
>> pity for Orocos not to have an equivalent but anyway.
>>
>>
>> Of course it is a pity. But it is all a matter of resources.
>>
>>
>> Not only, it is also a problem of communication, there is nowhere I can
>> found
>> "Help us in doing this, whe don't have the time and would be pleased to
>> integrate new ".
>>
>> People can
>> (rightfully) keep on asking for a user distribution, and I will
>> support
>> them in this claim, but the pragmatic reality of open source
>> projects is
>> that the required efforts should come somewhere from the community.
>> The
>> current developers do not have the means to take up yet another
>> responsibility, however useful and needed that might.
>>
>> Hence, to all Orocos _users_ I can only say this: "It's time to ask
>> what you
>> can do for the community, and not what the community can do for
>> you!"
>>
>>
>> I already asked me this question (that's why I am spending time in this
>> thread).
>> Once again and related to what Stephen refered to, the "Contribute" web
>> page on
>> the website is a must have to help this transistion.
>> But as a "Component Builder" my first logical answer is ok, I may be a
>> "Component Sharer" in a distribution.
>>
>> There is still something missing in the chain as you expect more than
>> this. You
>> expect them to become "Distributors"
>>
>>
>>
>>
>> Maybe I should reformulate like "Does anyone in the
>> Orocos community is keen on
>> setting up a component sharing system or to create an
>> 'Ocoros Hardware Library'
>> ?" I hope there is some pleople in the Orocos core that
>> wish to do so or to help
>> in this, because if not I don't think Orocos will live
>> long.
>>
>>
>> Don't worry about the 'developers part' of the project! :-)
>>
>>
>>
>> To finish with, there is a difference between : "we
>> don't have time to integrate
>> the Orocos Component Builder community and we 'recruit'
>> people to do so" and "we
>> don't care of Orocos Component Builder community it is
>> not our job". Separating
>> concepts between the core (rtt,ocl, ...) and the
>> satellites (DFKI, Orocos
>> Hardware Library, ...) is natural. Waiting for other to
>> wake up a morning saying
>> "Okay I'll become an Orocos distributor" is utopic.
>>
>>
>> Why? It has been done dozens of times before. Red Hat, Canonical, Debian,
>> ... where not started by developers, but by (power) users, with the same
>> concern as the ones that have been raised on this thread.
>>
>> Because it is very hard to be a power user in Orocos since it's hard to
>> become a
>> user and somehow (but I am sure it is not the real current case) you are
>> not
>> interested in user but distributors.
>>
>
> Orocos users are, by definition at this moment, _power users_. Or they have
> to have a high level of power userness in them :-) I do not think that that
> is going to change a lot (in RTT at least, and to a somewhat lesser extent
> in BFL and KDl), since Orocos has been focusing on the very difficult
> stuff, and not without success. I repeat that I am not at all against
> adding layers on top of the Orocos project, but maybe, just maybe, that is
> better done in separate, integrated projects. Like what is already
> happening with the Orocos-ROS integration.
>
> But although ROS is the closest thing we have in robotics as far as
> "distributions" go,
but there is also a "core" into it like rtt is. It is a distribution because
they have given the tools to do it to their community.
> you also notice the huge difficulties the ROS community
> has in "doing it right", especially in keeping evolving versions of
> sub-projects in sync. (For example, the state of KDL in ROS.) I am not at
> all blaming the ROS community, since I very well understand the huge
> efforts involved. And I do not think that Orocos should start its own
> "ROS"-like effort: I have always been in favour of reusing existing
> efforts! Even when they are not perfect, since who are we to do that
> distributor effort better than the (much larger) ROS community...? Many
> Orocos developers have already contributed to ROS in that way, providing
> packages, sending patches for the ROS toolchain, etc.
>
>
> Herman, you did not answer to my question (that I did not formulate as a
>> question :p) :
>> What is the official position in the Orocos project between :
>> _ "We have no more ressources and would love to have new developpers to
>> help
>> into bringing up a distribution into the Orocos project"
>> _ "We think doing a distribution is not a part of the Orocos project and
>> would
>> love that a new independant project hold this"
>> ?
>>
>
> I am very surprised to see you formulate things using a wording like "what
> is the official position"...? Orocos is an open source project, so there
> _is_ no official position!
I give my ideas, others give theirs, and then
> some common dynamics is maybe set into action to change things. None of
> this is following an official, top-down decision process. If there are some
> concrete actions to reinstate "OCL" as a user-centric part of the project,
> I am sure that Peter Soetens (and the other Orocos sub-project maintainers)
> will consider and discuss these suggestions very carefully, critically and
> respectfully.
Yes I know, sorry for this formulation it was not my aim, but you are a
group, working together for some times, so there is some idea about where
you are going ? no ?
It is the aim of my thread to discuss this. I am not __only__ interested by
your answers, I am sorry for others if they have felt excluded. But the fact
is that you answered quicker than the other :p
I asked you and Peter in particular because you are at the top of the AUTHOR
file in rtt !
My position is this : if there is a place for user code I will be glad to
share my stuff, if there is no, I will wait until it comes or an independant
project makes it possible because it is not my figth to create this.
>
>
>
>> Before doing this you have
>> to be a user, a Component Builder, a passionate and then
>> more. To my point of
>> view, and it's very personnal, it is the job of Orocos
>> and all project that
>> wants to spread to give a chance to people to make this
>> transition.
>>
>> P.S. : related to the subjets evoked in this thread :
>> http://www.orocos.org/wiki/orocos/toolchain/contributing
>> http://www.orocos.org/wiki/orocos/toolchain/roadmap
>> are really really nice to have and you should spend time
>> into populating them.
>> Please add the commands we have to type to generate a
>> patch. I sent patches to
>> ROS because they gave me a ligth and clear process I
>> just have to copy without
>> loosing any of my time.
>>
>> The ROS path is probably the easiest to go, as far as a "Orocos
>> distribution" goes. And we _have_ already started going that path, so
>> isn't that what you are asking for?
>>
>> I was asking for the "orocos" position in front of user code and why. All
>> the
>> helpfull answer you gave me in this thread went in this way. Whatever I
>> scratch
>> around this position, I understand it clearly.
>>
>
> Fine. To me, all this is obvious open source dynamics :-)
>
>
> I would be pleased to also have Peter's view around all this thread.
>>
>> It would be a pity people don't send their patches
>> becauses they would have to read the git and patch
>> documentation and don't want
>> to spend time in this (personnaly it is my case).
>>
>
> If I can teach you one open source skill that everyone definitely needs to
> sharpen: you have to closely follow at least a dozen or so open source
> projects, in order to be able to make the decision with two or three of
> them to use in a successfully integrated way :-) Multi-project
> _integration_ being the key to success, not single-project featuritis...
>
> Herman
The place for sharing users component
Am 27.02.11 12:50, schrieb Herman Bruyninckx:
> On Sun, 27 Feb 2011, Willy Lambert wrote:
>
>>
>>
>> 2011/2/27 Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...>
>> On Sat, 26 Feb 2011, Willy Lambert wrote:
>>
>>
>>
>> 2011/2/23 Herman Bruyninckx
>> <Herman [dot] Bruyninckx [..] ...>
>> On Wed, 23 Feb 2011, S Roderick wrote:
>>
>> On Feb 22, 2011, at 15:29 , Herman Bruyninckx wrote:
>>
>> On Tue, 22 Feb 2011, Willy Lambert wrote:
>>
>> Hi all,
>>
>> I create a new thread because I think
>> it is not good to continue in an other
>> thread
>>
>> As I am beginning to interface my
>> hardware on my robot (especially my
>> CAN bus),
>> I wondered about where I could find
>> others components or publish my code
>> to help
>> others, I asked :
>> [...]where is the place
>> for such a
>> component ? is it the job
>> of OCL v2 ?
>>
>>
>> Peter's answer :
>> No. Create a package
>> repository similar to how
>> a ROS package tree works
>> (ie
>> identical :-) , and point
>> people to that repository.
>> You can use git or svn,
>> or whatever you feel most
>> comfortable with.
>>
>>
>> I do not agree with Peter completely: the original
>> idea of OCL (6-7 years
>> ago) was for it to become the place to collect
>> "best practice" solutions,
>> and only those. Because of a lack of insight in
>> what "best practice" really
>> means, OCL ended up in becoming the "wast basket"
>> of the Orocos project,
>> that is, the branch were everything got dumped
>> that did not nicely fit in
>> the core parts of the project's source tree :-(
>>
>> I think it is high time to resurrect OCL as "the"
>> place for users to go an
>> look for proven, documented, best practice
>> systems. I think this is to some
>> extent what you are also hinting at, isn't it?
>>
>>
>> I'm with Herman on this one. Orocos' biggest fault is
>> that it
>> is developer-centric, not user-centric. IMHO trimming
>> down OCL
>> was an example of this. The project is wonderful for
>> developers. It is tough to be a user in this ecosystem.
>>
>> In addition to that, Peter's suggestion for the
>> "ROS like" approach of
>> various, unreviewed code repositories also makes
>> sense. But the practice
>> proves that this becomes a chaotic bunch of bits
>> and pieces without any
>> quality control or guarantee. I think we should do
>> better with Orocos,
>> since there is a major difference between ROS and
>> Orocos: we want to be the
>> best possible solution in a small niche of
>> robotics.
>>
>>
>> I agree that there is, and should be, a distinction
>> between
>> best practice examples, and user-contributed code. But we
>> also
>> need examples of both.
>>
>> First of all, I am not complaining
>> about a miss, but trying to understand
>> what's
>> the Orocos roadmap about "community
>> integration". I think there is a lack
>> and as
>> I love Orocos I can't accept it can't
>> conquer the world :p
>>
>>
>> It should conquer only a small piece of the world,
>> but conquer that niche
>> without leaving any room for competition :-)
>>
>> I totally agree on the fact it is not
>> the job of Orocos developpers to
>> provide
>> such "users components".
>>
>>
>> It _is_, but then only for a small set of proven,
>> best practice components!
>>
>>
>> It absolutely is the developer's responsibility - if you
>> want
>> the project
>> to last. Developers need to provide a framework within
>> which
>> new users
>> can rapidly get used to a system. Without fostering your
>> user
>> base,
>> projects die. New users need solid system examples of how
>> to
>> use Orocos
>> in a system. No such example exists. This leaves new
>> users
>> foundering
>> without direction, leading them to seek alternatives. I
>> know
>> groups
>> who've already done this.
>>
>>
>> At Leuven, we have been playing (but not much more,
>> unfortunately) with
>> the
>> idea of providing the "motion stack" packaged with a Blender
>> Python script
>> that makes a Blender simulation work as a simple "RTT
>> component". In this
>> way, we could provide an "Hello robot!" example that runs out
>> of the box
>> on
>> all major platforms, without users needing to have a real
>> robot. I know it
>> is time to stop playing and become serious...
>>
>>
>>
>> It was not my aim to provoque a 1.x versus 2.x discussion, so
>> let's me recall
>> the first subject of this thread :
>> "What is the place for user contributions"
>>
>> When I say "user contribution" I am not speaking about code
>> report or
>> documentation improvment, I am speaking about sharing what you
>> do __with__
>> orocos. I quote Klaas's point of view :
>> "Suppose (purely hypothetical) I (not referring to myself, but
>> rather to some a
>> industrial company using orocos) am an orocos 1.x user, that
>> invested (quite?)
>> some effort in getting the 1.x series where they are now and
>> learning some new
>> tools. I am not being paid to work _on_ orocos, but to do
>> something useful
>> _with_ orocos."
>>
>> I am beginning a robot project that will maybe live during 5
>> years (crossed
>> fingers). I will do or redo what's all roboticians have to do
>> in a first step
>> (with no hudge interest for me) : interfacing harware. I am
>> keen to share my
>> stuff. But there is no way I set up I full project for
>> becoming an Orocos
>> distributor (yet ?! ^^ ).
>>
>> Herman, for you motion stack you should have exactly the same
>> question as I :
>> "Where on the hell may I share this very user-usefull stuff as
>> it can be seen on
>> the Orocos community easily ?"
>> It is that kind of user contributions that'll provoque user
>> gathering to create
>> distributions. But there is no "how to become a distributor"
>> page on Orocos,
>> neither than "what could be a distribution of Orocos". IMO (to
>> my very young use
>> of linux 2.6 Herman :p), a distribution in linux is a pick and
>> choose of
>> existing applications. That does mean it exists users before
>> distributors.
>>
>> At the end I bumped into : "Components built by users of
>> Orocos are hosted in
>> their own repositories." on the
>> http://www.orocos.org/toolchain page. So here is
>> my answer. OCL has turned into the tools you need to monitor
>> your application
>> (taskbrowser, logs , ...) and I may understand this. And if I
>> want to share my
>> stuff it's my problem (so I won't because I am keen to share
>> not to set up a
>> sharing system). In practice I will go with the ROS sharing
>> system
>> http://www.ros.org/wiki/ because I don't have anything to do.
>> I think it's a
>> pity for Orocos not to have an equivalent but anyway.
>>
>>
>> Of course it is a pity. But it is all a matter of resources.
>>
>>
>> Not only, it is also a problem of communication, there is nowhere I
>> can found
>> "Help us in doing this, whe don't have the time and would be pleased to
>> integrate new ".
>>
>> People can
>> (rightfully) keep on asking for a user distribution, and I will
>> support
>> them in this claim, but the pragmatic reality of open source
>> projects is
>> that the required efforts should come somewhere from the community.
>> The
>> current developers do not have the means to take up yet another
>> responsibility, however useful and needed that might.
>>
>> Hence, to all Orocos _users_ I can only say this: "It's time to ask
>> what you
>> can do for the community, and not what the community can do for
>> you!"
>>
>>
>> I already asked me this question (that's why I am spending time in
>> this thread).
>> Once again and related to what Stephen refered to, the "Contribute"
>> web page on
>> the website is a must have to help this transistion.
>> But as a "Component Builder" my first logical answer is ok, I may be a
>> "Component Sharer" in a distribution.
>>
>> There is still something missing in the chain as you expect more than
>> this. You
>> expect them to become "Distributors"
>>
>>
>>
>>
>> Maybe I should reformulate like "Does anyone in the
>> Orocos community is keen on
>> setting up a component sharing system or to create an
>> 'Ocoros Hardware Library'
>> ?" I hope there is some pleople in the Orocos core that
>> wish to do so or to help
>> in this, because if not I don't think Orocos will live
>> long.
>>
>>
>> Don't worry about the 'developers part' of the project! :-)
>>
>>
>>
>> To finish with, there is a difference between : "we
>> don't have time to integrate
>> the Orocos Component Builder community and we 'recruit'
>> people to do so" and "we
>> don't care of Orocos Component Builder community it is
>> not our job". Separating
>> concepts between the core (rtt,ocl, ...) and the
>> satellites (DFKI, Orocos
>> Hardware Library, ...) is natural. Waiting for other to
>> wake up a morning saying
>> "Okay I'll become an Orocos distributor" is utopic.
>>
>>
>> Why? It has been done dozens of times before. Red Hat, Canonical, Debian,
>> ... where not started by developers, but by (power) users, with the same
>> concern as the ones that have been raised on this thread.
>>
>> Because it is very hard to be a power user in Orocos since it's hard
>> to become a
>> user and somehow (but I am sure it is not the real current case) you
>> are not
>> interested in user but distributors.
>
> Orocos users are, by definition at this moment, _power users_. Or they have
> to have a high level of power userness in them :-) I do not think that that
> is going to change a lot (in RTT at least, and to a somewhat lesser extent
> in BFL and KDl), since Orocos has been focusing on the very difficult
> stuff, and not without success. I repeat that I am not at all against
> adding layers on top of the Orocos project, but maybe, just maybe, that is
> better done in separate, integrated projects. Like what is already
> happening with the Orocos-ROS integration.
>
> But although ROS is the closest thing we have in robotics as far as
> "distributions" go, you also notice the huge difficulties the ROS community
> has in "doing it right", especially in keeping evolving versions of
> sub-projects in sync. (For example, the state of KDL in ROS.) I am not at
> all blaming the ROS community, since I very well understand the huge
> efforts involved. And I do not think that Orocos should start its own
> "ROS"-like effort: I have always been in favour of reusing existing
> efforts! Even when they are not perfect, since who are we to do that
> distributor effort better than the (much larger) ROS community...? Many
> Orocos developers have already contributed to ROS in that way, providing
> packages, sending patches for the ROS toolchain, etc.
>
>> Herman, you did not answer to my question (that I did not formulate as a
>> question :p) :
>> What is the official position in the Orocos project between :
>> _ "We have no more ressources and would love to have new developpers
>> to help
>> into bringing up a distribution into the Orocos project"
>> _ "We think doing a distribution is not a part of the Orocos project
>> and would
>> love that a new independant project hold this"
>> ?
>
> I am very surprised to see you formulate things using a wording like "what
> is the official position"...? Orocos is an open source project, so there
> _is_ no official position! I give my ideas, others give theirs, and then
> some common dynamics is maybe set into action to change things. None of
> this is following an official, top-down decision process. If there are some
> concrete actions to reinstate "OCL" as a user-centric part of the project,
> I am sure that Peter Soetens (and the other Orocos sub-project maintainers)
> will consider and discuss these suggestions very carefully, critically and
> respectfully.
Even so I am not a Orocos developer more an occasional user I could
imagine that OCL becomes the place where users submit their "ready to
use" components following a peer-reviewed process like gearbox [1].
Has this been already discussed?
[1] http://gearbox.sourceforge.net/
>
>>
>> Before doing this you have
>> to be a user, a Component Builder, a passionate and then
>> more. To my point of
>> view, and it's very personnal, it is the job of Orocos
>> and all project that
>> wants to spread to give a chance to people to make this
>> transition.
>>
>> P.S. : related to the subjets evoked in this thread :
>> http://www.orocos.org/wiki/orocos/toolchain/contributing
>> http://www.orocos.org/wiki/orocos/toolchain/roadmap
>> are really really nice to have and you should spend time
>> into populating them.
>> Please add the commands we have to type to generate a
>> patch. I sent patches to
>> ROS because they gave me a ligth and clear process I
>> just have to copy without
>> loosing any of my time.
>>
>> The ROS path is probably the easiest to go, as far as a "Orocos
>> distribution" goes. And we _have_ already started going that path, so
>> isn't that what you are asking for?
>>
>> I was asking for the "orocos" position in front of user code and why.
>> All the
>> helpfull answer you gave me in this thread went in this way. Whatever
>> I scratch
>> around this position, I understand it clearly.
>
> Fine. To me, all this is obvious open source dynamics :-)
>
>> I would be pleased to also have Peter's view around all this thread.
>>
>> It would be a pity people don't send their patches
>> becauses they would have to read the git and patch
>> documentation and don't want
>> to spend time in this (personnaly it is my case).
>
> If I can teach you one open source skill that everyone definitely needs to
> sharpen: you have to closely follow at least a dozen or so open source
> projects, in order to be able to make the decision with two or three of
> them to use in a successfully integrated way :-) Multi-project
> _integration_ being the key to success, not single-project featuritis...
>
> Herman
>
The place for sharing users component
On Sun, 27 Feb 2011, Nico Hochgeschwender wrote:
[...]
> Even so I am not a Orocos developer more an occasional user I could
> imagine that OCL becomes the place where users submit their "ready to
> use" components following a peer-reviewed process like gearbox [1].
>
> Has this been already discussed?
>
> [1] http://gearbox.sourceforge.net/
>
It's been _mentioned_ a couple of times, but not really discussed. The
difference between a mention and a discussion basically means that, in the
latter case, some motivated, dedicated person has already presented
him/herself, with a concrete suggestion about how to do it, and who will do
it, such that only some "details" have to be sorted out.
Herman
The place for sharing users component
[...]
> I'm with Herman on this one. Orocos' biggest fault is that it is developer-centric, not user-centric. IMHO
> trimming down OCL was an example of this. The project is wonderful for developers. It is tough to be a user
> in this ecosystem.
This is "spot-on". I thought it deserved a more prominent view on the
www, so I decided to isolate it from its context :-)
Considering myself an "advanced (1.x) user", even at the point where
2.3 (2.0, 2.1, 2.2, 2.3) is going to be released soon, I have
_absolutely no clear view_ of what would be the implications (benefits
_and_ disadvantages) of moving to the 2.x series. 1.x had a high
getting-started-threshold, I'm afraid it just got worse...
YMMV,
Klaas
The place for sharing users component
On Feb 23, 2011, at 03:15 , Klaas Gadeyne wrote:
> [...]
>> I'm with Herman on this one. Orocos' biggest fault is that it is developer-centric, not user-centric. IMHO
>> trimming down OCL was an example of this. The project is wonderful for developers. It is tough to be a user
>> in this ecosystem.
>
> This is "spot-on". I thought it deserved a more prominent view on the
> www, so I decided to isolate it from its context :-)
>
> Considering myself an "advanced (1.x) user", even at the point where
> 2.3 (2.0, 2.1, 2.2, 2.3) is going to be released soon, I have
> _absolutely no clear view_ of what would be the implications (benefits
> _and_ disadvantages) of moving to the 2.x series. 1.x had a high
> getting-started-threshold, I'm afraid it just got worse...
I believe that I understand some of the advantages of moving to v2, but watching the churn on the mail list the past few months, I have no interest in upgrading from v1 any time soon either. v2 seems overrun with continual changes to the CMake macros, type system, and integration issues with Lua/ROS/typegen, seemingly without end. I'm seriously tempted to wait for v3 and see if the stability and maturity of v1 has returned by then.
It is _not_ that I think that v2 is a bad solution, nor that I think that the decoupling that v2 introduced is a bad thing (indeed, I think it is wonderful and was looking forward to using it), but it seems that with v2 Orocos has become even more developer-only (if only through complexity). My customers and I just don't want to deal with that ... despite so much wonderful work having been done on v2.
S
The place for sharing users component
2011/2/23 S Roderick <kiwi [dot] net [..] ...>
> On Feb 23, 2011, at 03:15 , Klaas Gadeyne wrote:
>
> > [...]
> >> I'm with Herman on this one. Orocos' biggest fault is that it is
> developer-centric, not user-centric. IMHO
> >> trimming down OCL was an example of this. The project is wonderful for
> developers. It is tough to be a user
> >> in this ecosystem.
> >
> > This is "spot-on". I thought it deserved a more prominent view on the
> > www, so I decided to isolate it from its context :-)
> >
> > Considering myself an "advanced (1.x) user", even at the point where
> > 2.3 (2.0, 2.1, 2.2, 2.3) is going to be released soon, I have
> > _absolutely no clear view_ of what would be the implications (benefits
> > _and_ disadvantages) of moving to the 2.x series. 1.x had a high
> > getting-started-threshold, I'm afraid it just got worse...
>
> I believe that I understand some of the advantages of moving to v2, but
> watching the churn on the mail list the past few months, I have no interest
> in upgrading from v1 any time soon either. v2 seems overrun with continual
> changes to the CMake macros, type system, and integration issues with
> Lua/ROS/typegen, seemingly without end. I'm seriously tempted to wait for v3
> and see if the stability and maturity of v1 has returned by then.
>
> It is _not_ that I think that v2 is a bad solution, nor that I think that
> the decoupling that v2 introduced is a bad thing (indeed, I think it is
> wonderful and was looking forward to using it), but it seems that with v2
> Orocos has become even more developer-only (if only through complexity). My
> customers and I just don't want to deal with that ... despite so much
> wonderful work having been done on v2.
>
>
I must approve this (the thread subject is explode but anyway, worth to
say).
I have 2 profil using Orocos :
_ at work in my company : 1.10 user
_ at home on my robot : 2.x user
as a 1.10 user, I would like to push my compagny to use 2.x but I can't for
the same reasons and they'll for sure wait v3 either to switch 1->3 if it is
stable or switch to v2.
as a 2.x user I must say the build system has been really improved to be
more user friendly (just sh boostrap.sh and it's installed) and the
orocreate-pkg help a lot to reduce the learning curve.
> S
> --
> Orocos-Users mailing list
> Orocos-Users [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>
The place for sharing users component
On Wed, 23 Feb 2011, S Roderick wrote:
> On Feb 23, 2011, at 03:15 , Klaas Gadeyne wrote:
>
>> [...]
>>> I'm with Herman on this one. Orocos' biggest fault is that it is developer-centric, not user-centric. IMHO
>>> trimming down OCL was an example of this. The project is wonderful for developers. It is tough to be a user
>>> in this ecosystem.
>>
>> This is "spot-on". I thought it deserved a more prominent view on the
>> www, so I decided to isolate it from its context :-)
>>
>> Considering myself an "advanced (1.x) user", even at the point where
>> 2.3 (2.0, 2.1, 2.2, 2.3) is going to be released soon, I have
>> _absolutely no clear view_ of what would be the implications (benefits
>> _and_ disadvantages) of moving to the 2.x series. 1.x had a high
>> getting-started-threshold, I'm afraid it just got worse...
>
> I believe that I understand some of the advantages of moving to v2, but watching the churn on the mail list the past few months, I have no interest in upgrading from v1 any time soon either. v2 seems overrun with continual changes to the CMake macros, type system, and integration issues with Lua/ROS/typegen, seemingly without end. I'm seriously tempted to wait for v3 and see if the stability and maturity of v1 has returned by then.
>
> It is _not_ that I think that v2 is a bad solution, nor that I think that the decoupling that v2 introduced is a bad thing (indeed, I think it is wonderful and was looking forward to using it), but it seems that with v2 Orocos has become even more developer-only (if only through complexity). My customers and I just don't want to deal with that ... despite so much wonderful work having been done on v2.
>
Well respected point of view :-) Here shows one of the real advantages of
open source projects: there is nobody forcing you to switch :-)
> S
Herman
The place for sharing users component
[...]
> Well respected point of view :-) Here shows one of the real advantages
> of open source projects: there is nobody forcing you to switch :-)
For commercial SW there's nobody forcing you to upgrade either. If the net result is that, as a user, you have to maintain everything yourself, I somehow fail to see the real advantage here...
The place for sharing users component
On Feb 23, 2011, at 06:30 , Herman Bruyninckx wrote:
> On Wed, 23 Feb 2011, S Roderick wrote:
>
>> On Feb 23, 2011, at 03:15 , Klaas Gadeyne wrote:
>>
>>> [...]
>>>> I'm with Herman on this one. Orocos' biggest fault is that it is developer-centric, not user-centric. IMHO
>>>> trimming down OCL was an example of this. The project is wonderful for developers. It is tough to be a user
>>>> in this ecosystem.
>>>
>>> This is "spot-on". I thought it deserved a more prominent view on the
>>> www, so I decided to isolate it from its context :-)
>>>
>>> Considering myself an "advanced (1.x) user", even at the point where
>>> 2.3 (2.0, 2.1, 2.2, 2.3) is going to be released soon, I have
>>> _absolutely no clear view_ of what would be the implications (benefits
>>> _and_ disadvantages) of moving to the 2.x series. 1.x had a high
>>> getting-started-threshold, I'm afraid it just got worse...
>>
>> I believe that I understand some of the advantages of moving to v2, but watching the churn on the mail list the past few months, I have no interest in upgrading from v1 any time soon either. v2 seems overrun with continual changes to the CMake macros, type system, and integration issues with Lua/ROS/typegen, seemingly without end. I'm seriously tempted to wait for v3 and see if the stability and maturity of v1 has returned by then.
>>
>> It is _not_ that I think that v2 is a bad solution, nor that I think that the decoupling that v2 introduced is a bad thing (indeed, I think it is wonderful and was looking forward to using it), but it seems that with v2 Orocos has become even more developer-only (if only through complexity). My customers and I just don't want to deal with that ... despite so much wonderful work having been done on v2.
>>
> Well respected point of view :-) Here shows one of the real advantages of
> open source projects: there is nobody forcing you to switch :-)
Correct. But community-driven changes may force members of the community to go elsewhere, and take their energy and inputs with them ... cfr Oracle.
S
The place for sharing users component
On Wednesday 23 February 2011 09:15:27 Klaas Gadeyne wrote:
> [...]
>
> > I'm with Herman on this one. Orocos' biggest fault is that it is
> > developer-centric, not user-centric. IMHO trimming down OCL was an
> > example of this. The project is wonderful for developers. It is tough
> > to be a user in this ecosystem.
>
> This is "spot-on". I thought it deserved a more prominent view on the
> www, so I decided to isolate it from its context :-)
>
> Considering myself an "advanced (1.x) user", even at the point where
> 2.3 (2.0, 2.1, 2.2, 2.3) is going to be released soon, I have
> _absolutely no clear view_ of what would be the implications (benefits
> _and_ disadvantages) of moving to the 2.x series. 1.x had a high
> getting-started-threshold, I'm afraid it just got worse...
On the toolchain page there is a link pointing to
http://www.orocos.org/wiki/rtt/rtt-20/upgrading-rtt-1x-20
If this page does not bring you to the information you need, than we/you ;)
need to add it.
One of the new tools in the 2.x series is the orocreate-pkg tool, which
creates for you an immediately buildable package containing templates for
components/services/plugins/typekits. This should already partly lower the
getting-started-threshold.
> YMMV,
>
> Klaas
-- Ruben
The place for sharing users component
On Feb 23, 2011, at 03:58 , Ruben Smits wrote:
> On Wednesday 23 February 2011 09:15:27 Klaas Gadeyne wrote:
>> [...]
>>
>>> I'm with Herman on this one. Orocos' biggest fault is that it is
>>> developer-centric, not user-centric. IMHO trimming down OCL was an
>>> example of this. The project is wonderful for developers. It is tough
>>> to be a user in this ecosystem.
>>
>> This is "spot-on". I thought it deserved a more prominent view on the
>> www, so I decided to isolate it from its context :-)
>>
>> Considering myself an "advanced (1.x) user", even at the point where
>> 2.3 (2.0, 2.1, 2.2, 2.3) is going to be released soon, I have
>> _absolutely no clear view_ of what would be the implications (benefits
>> _and_ disadvantages) of moving to the 2.x series. 1.x had a high
>> getting-started-threshold, I'm afraid it just got worse...
>
> On the toolchain page there is a link pointing to
> http://www.orocos.org/wiki/rtt/rtt-20/upgrading-rtt-1x-20
>
> If this page does not bring you to the information you need, than we/you ;)
> need to add it.
>
> One of the new tools in the 2.x series is the orocreate-pkg tool, which
> creates for you an immediately buildable package containing templates for
> components/services/plugins/typekits. This should already partly lower the
> getting-started-threshold.
Again, developer-centric. That page is great for upgrading code (ie from a programmatic point of view), but it's fundamentally nothing more than a bullet list of changes. It doesn't help much with upgrading entire systems. That is what many of us face, who come from v1. And for some of us that is tens of thousands of lines of code ....
What _would_ have helped would have been a best-practice system example in v1, and the corresponding example in v2. Along with explanations of what concepts changed and why that was best practice. I actually started down this path myself, and gave up in frustration with v2.
S
The place for sharing users component
Hi Ruben and Stephen
> On Feb 23, 2011, at 03:58 , Ruben Smits wrote:
> >> Considering myself an "advanced (1.x) user", even at the point where
> >> 2.3 (2.0, 2.1, 2.2, 2.3) is going to be released soon, I have
> >> _absolutely no clear view_ of what would be the implications
> (benefits
> >> _and_ disadvantages) of moving to the 2.x series. 1.x had a high
> >> getting-started-threshold, I'm afraid it just got worse...
> >
> > On the toolchain page there is a link pointing to
> > http://www.orocos.org/wiki/rtt/rtt-20/upgrading-rtt-1x-20
> >
> > If this page does not bring you to the information you need, than
> we/you ;)
> > need to add it.
> >
> > One of the new tools in the 2.x series is the orocreate-pkg tool,
> which
> > creates for you an immediately buildable package containing templates
> for
> > components/services/plugins/typekits. This should already partly
> lower the
> > getting-started-threshold.
>
> Again, developer-centric. That page is great for upgrading code (ie
> from a programmatic point of view), but it's fundamentally nothing more
> than a bullet list of changes. It doesn't help much with upgrading
> entire systems. That is what many of us face, who come from v1. And for
> some of us that is tens of thousands of lines of code ....
>
> What _would_ have helped would have been a best-practice system example
> in v1, and the corresponding example in v2. Along with explanations of
> what concepts changed and why that was best practice. I actually
> started down this path myself, and gave up in frustration with v2.
[Disclaimer: this reasoning is very _subjective_ and my information is mainly based on following up the Mailinglist, so I might be entirely wrong, and to some extent I even _hope I am_. Contrary to Ste
phen, I didn't even give v2 a chance.]
Suppose (purely hypothetical) I (not referring to myself, but rather to some a industrial company using orocos) am an orocos 1.x user, that invested (quite?) some effort in getting the 1.x series where they are now and learning some new tools. I am not being paid to work _on_ orocos, but to do something useful _with_ orocos.
I have, after these investments, a working orocos application using ao, scripting statemachines, hardware components from OCL and code generation from Simulink (in the end, I work in a company and I'm not a do-everything-yourself phd student (no offense meant, on the contrary ;-)). What orocos offers me is a logging system, a nice way to deal with configuration via the properties, and some means to introduce modularity in my code via components.
2.x comes out:
- It seems like I need to learn about ruby, git, typegen, ros, lua (and I probably forgot some).
- It seems like I'll have to completely redo the effort for using Simulink and my hardware components
- It seems like, even with v2.3 coming, it is not stable yet. I don't know whether the release scheme is still followed, but from the 2.1 release notes I would say that .uneven release are not considered unstable anymore. I do now, that, by the time rtt 1.6 was released, it was one "damned stable piece of SW" (compared with 2.x ;-)
- I cannot be convinced by upgrade notes speaking about "better decoupling", because I don't see what it will _concretely_ improve for me. I saw some of the messages the BFL maintainer posted about trying the new typekit system, and they really scared the hell out of me.
Again, YMMV, and I'm sure there will be some improvements that I currently fail to see, but this morning I was actually glad that I seemed not to be the only one thinking along these lines.
Klaas
Ps. At <http://www.orocos.org/wiki/rtt/rtt-20/upgrading-rtt-1x-20> the link pointing to orogen link is dead.
The place for sharing users component
On Wednesday 23 February 2011 14:22:56 Klaas Gadeyne wrote:
> Hi Ruben and Stephen
>
> > On Feb 23, 2011, at 03:58 , Ruben Smits wrote:
> > >> Considering myself an "advanced (1.x) user", even at the point
> > >> where
> > >> 2.3 (2.0, 2.1, 2.2, 2.3) is going to be released soon, I have
> > >> _absolutely no clear view_ of what would be the implications
> >
> > (benefits
> >
> > >> _and_ disadvantages) of moving to the 2.x series. 1.x had a high
> > >> getting-started-threshold, I'm afraid it just got worse...
> > >
> > > On the toolchain page there is a link pointing to
> > > http://www.orocos.org/wiki/rtt/rtt-20/upgrading-rtt-1x-20
> > >
> > > If this page does not bring you to the information you need, than
> >
> > we/you ;)
> >
> > > need to add it.
> > >
> > > One of the new tools in the 2.x series is the orocreate-pkg tool,
> >
> > which
> >
> > > creates for you an immediately buildable package containing
> > > templates
> >
> > for
> >
> > > components/services/plugins/typekits. This should already partly
> >
> > lower the
> >
> > > getting-started-threshold.
> >
> > Again, developer-centric. That page is great for upgrading code (ie
> > from a programmatic point of view), but it's fundamentally nothing more
> > than a bullet list of changes. It doesn't help much with upgrading
> > entire systems. That is what many of us face, who come from v1. And for
> > some of us that is tens of thousands of lines of code ....
> >
> > What _would_ have helped would have been a best-practice system example
> > in v1, and the corresponding example in v2. Along with explanations of
> > what concepts changed and why that was best practice. I actually
> > started down this path myself, and gave up in frustration with v2.
>
> [Disclaimer: this reasoning is very _subjective_ and my information is
> mainly based on following up the Mailinglist, so I might be entirely wrong,
> and to some extent I even _hope I am_. Contrary to Ste phen, I didn't even
> give v2 a chance.]
>
> Suppose (purely hypothetical) I (not referring to myself, but rather to some
> a industrial company using orocos) am an orocos 1.x user, that invested
> (quite?) some effort in getting the 1.x series where they are now and
> learning some new tools. I am not being paid to work _on_ orocos, but to
> do something useful _with_ orocos.
>
> I have, after these investments, a working orocos application using ao,
> scripting statemachines, hardware components from OCL and code generation
> from Simulink (in the end, I work in a company and I'm not a
>e do-everything-yourself phd student (no offense meant, on the contrary ;-)).
> What orocos offers me is a logging system, a nice way to deal with
> configuration via the properties, and some means to introduce modularity in
> my code via components.
>
> 2.x comes out:
> - It seems like I need to learn about ruby, git, typegen, ros, lua (and I
> probably forgot some).
Except for git (which is just a versioning system), all others are optional
additions. If you like the way of working with RTT in the v1.x series, and you
do not want to change your way of working with RTT, there is nothing new you
have to learn.
> - It seems like I'll have to completely redo the
> effort for using Simulink and my hardware components
> - It seems like, even
> with v2.3 coming, it is not stable yet.
This depends entirely on your definition of stable. Most of the changes between
2.2 and 2.3 are mainly about win32 support (which is highly demanded by
industrial users), and corba support which is optional and not rtt-core
bussiness.
> I don't know whether the release
> scheme is still followed, but from the 2.1 release notes I would say that
> .uneven release are not considered unstable anymore. I do now, that, by
> the time rtt 1.6 was released, it was one "damned stable piece of SW"
> (compared with 2.x ;-)
> - I cannot be convinced by upgrade notes speaking
> about "better decoupling", because I don't see what it will _concretely_
> improve for me. I saw some of the messages the BFL maintainer posted about
> trying the new typekit system, and they really scared the hell out of me.
>
> Again, YMMV, and I'm sure there will be some improvements that I currently
> fail to see, but this morning I was actually glad that I seemed not to be
> the only one thinking along these lines.
>
> Klaas
>
> Ps. At <http://www.orocos.org/wiki/rtt/rtt-20/upgrading-rtt-1x-20> the link
> pointing to orogen link is dead.
-- Ruben
The place for sharing users component
On Wed, 23 Feb 2011, Klaas Gadeyne wrote:
> Hi Ruben and Stephen
>> On Feb 23, 2011, at 03:58 , Ruben Smits wrote:
>>>> Considering myself an "advanced (1.x) user", even at the point where
>>>> 2.3 (2.0, 2.1, 2.2, 2.3) is going to be released soon, I have
>>>> _absolutely no clear view_ of what would be the implications
>> (benefits
>>>> _and_ disadvantages) of moving to the 2.x series. 1.x had a high
>>>> getting-started-threshold, I'm afraid it just got worse...
>>>
>>> On the toolchain page there is a link pointing to
>>> http://www.orocos.org/wiki/rtt/rtt-20/upgrading-rtt-1x-20
>>>
>>> If this page does not bring you to the information you need, than
>> we/you ;)
>>> need to add it.
>>>
>>> One of the new tools in the 2.x series is the orocreate-pkg tool,
>> which
>>> creates for you an immediately buildable package containing templates
>> for
>>> components/services/plugins/typekits. This should already partly
>> lower the
>>> getting-started-threshold.
>>
>> Again, developer-centric. That page is great for upgrading code (ie
>> from a programmatic point of view), but it's fundamentally nothing more
>> than a bullet list of changes. It doesn't help much with upgrading
>> entire systems. That is what many of us face, who come from v1. And for
>> some of us that is tens of thousands of lines of code ....
>>
>> What _would_ have helped would have been a best-practice system example
>> in v1, and the corresponding example in v2. Along with explanations of
>> what concepts changed and why that was best practice. I actually
>> started down this path myself, and gave up in frustration with v2.
>
> [Disclaimer: this reasoning is very _subjective_ and my information is mainly based on following up the Mailinglist, so I might be entirely wrong, and to some extent I even _hope I am_. Contrary to Ste
> phen, I didn't even give v2 a chance.]
>
> Suppose (purely hypothetical) I (not referring to myself, but rather to some a industrial company using orocos) am an orocos 1.x user, that invested (quite?) some effort in getting the 1.x series where they are now and learning some new tools. I am not being paid to work _on_ orocos, but to do something useful _with_ orocos.
>
> I have, after these investments, a working orocos application using ao, scripting statemachines, hardware components from OCL and code generation from Simulink (in the end, I work in a company and I'm not a do-everything-yourself phd student (no offense meant, on the contrary ;-)). What orocos offers me is a logging system, a nice way to deal with configuration via the properties, and some means to introduce modularity in my code via components.
>
> 2.x comes out:
> - It seems like I need to learn about ruby, git, typegen, ros, lua (and I probably forgot some).
> - It seems like I'll have to completely redo the effort for using Simulink and my hardware components
> - It seems like, even with v2.3 coming, it is not stable yet. I don't know whether the release scheme is still followed, but from the 2.1 release notes I would say that .uneven release are not considered unstable anymore. I do now, that, by the time rtt 1.6 was released, it was one "damned stable piece of SW" (compared with 2.x ;-)
> - I cannot be convinced by upgrade notes speaking about "better decoupling", because I don't see what it will _concretely_ improve for me. I saw some of the messages the BFL maintainer posted about trying the new typekit system, and they really scared the hell out of me.
>
> Again, YMMV, and I'm sure there will be some improvements that I currently fail to see, but this morning I was actually glad that I seemed not to be the only one thinking along these lines.
>
> Klaas
Your point of view is valid, and "right". But I am old enough to have been
there when the Linux kernel went from 1.x to 2.0, and the situation was
exactly the same. Similarly with going from 2.4 to 2.6. It took some years
to stabilize, some companies indeed were confused, but that's reality. None
of them were _forced_ to follow the transition, at least not in a timeframe
of 1-2 years. So, please give also Orocos this timeframe.
Herman
The place for sharing users component
On Feb 23, 2011, at 11:59 , Herman Bruyninckx wrote:
> On Wed, 23 Feb 2011, Klaas Gadeyne wrote:
>
>> Hi Ruben and Stephen
>>> On Feb 23, 2011, at 03:58 , Ruben Smits wrote:
>>>>> Considering myself an "advanced (1.x) user", even at the point where
>>>>> 2.3 (2.0, 2.1, 2.2, 2.3) is going to be released soon, I have
>>>>> _absolutely no clear view_ of what would be the implications
>>> (benefits
>>>>> _and_ disadvantages) of moving to the 2.x series. 1.x had a high
>>>>> getting-started-threshold, I'm afraid it just got worse...
>>>>
>>>> On the toolchain page there is a link pointing to
>>>> http://www.orocos.org/wiki/rtt/rtt-20/upgrading-rtt-1x-20
>>>>
>>>> If this page does not bring you to the information you need, than
>>> we/you ;)
>>>> need to add it.
>>>>
>>>> One of the new tools in the 2.x series is the orocreate-pkg tool,
>>> which
>>>> creates for you an immediately buildable package containing templates
>>> for
>>>> components/services/plugins/typekits. This should already partly
>>> lower the
>>>> getting-started-threshold.
>>>
>>> Again, developer-centric. That page is great for upgrading code (ie
>>> from a programmatic point of view), but it's fundamentally nothing more
>>> than a bullet list of changes. It doesn't help much with upgrading
>>> entire systems. That is what many of us face, who come from v1. And for
>>> some of us that is tens of thousands of lines of code ....
>>>
>>> What _would_ have helped would have been a best-practice system example
>>> in v1, and the corresponding example in v2. Along with explanations of
>>> what concepts changed and why that was best practice. I actually
>>> started down this path myself, and gave up in frustration with v2.
>>
>> [Disclaimer: this reasoning is very _subjective_ and my information is mainly based on following up the Mailinglist, so I might be entirely wrong, and to some extent I even _hope I am_. Contrary to Ste
>> phen, I didn't even give v2 a chance.]
>>
>> Suppose (purely hypothetical) I (not referring to myself, but rather to some a industrial company using orocos) am an orocos 1.x user, that invested (quite?) some effort in getting the 1.x series where they are now and learning some new tools. I am not being paid to work _on_ orocos, but to do something useful _with_ orocos.
>>
>> I have, after these investments, a working orocos application using ao, scripting statemachines, hardware components from OCL and code generation from Simulink (in the end, I work in a company and I'm not a do-everything-yourself phd student (no offense meant, on the contrary ;-)). What orocos offers me is a logging system, a nice way to deal with configuration via the properties, and some means to introduce modularity in my code via components.
>>
>> 2.x comes out:
>> - It seems like I need to learn about ruby, git, typegen, ros, lua (and I probably forgot some).
>> - It seems like I'll have to completely redo the effort for using Simulink and my hardware components
>> - It seems like, even with v2.3 coming, it is not stable yet. I don't know whether the release scheme is still followed, but from the 2.1 release notes I would say that .uneven release are not considered unstable anymore. I do now, that, by the time rtt 1.6 was released, it was one "damned stable piece of SW" (compared with 2.x ;-)
>> - I cannot be convinced by upgrade notes speaking about "better decoupling", because I don't see what it will _concretely_ improve for me. I saw some of the messages the BFL maintainer posted about trying the new typekit system, and they really scared the hell out of me.
>>
>> Again, YMMV, and I'm sure there will be some improvements that I currently fail to see, but this morning I was actually glad that I seemed not to be the only one thinking along these lines.
>>
>> Klaas
>
> Your point of view is valid, and "right". But I am old enough to have been
> there when the Linux kernel went from 1.x to 2.0, and the situation was
> exactly the same. Similarly with going from 2.4 to 2.6. It took some years
> to stabilize, some companies indeed were confused, but that's reality. None
> of them were _forced_ to follow the transition, at least not in a timeframe
> of 1-2 years. So, please give also Orocos this timeframe.
That is a specious and unrealistic comparision. Linux is at least 2 to 3 orders of magnitude larger in code size and user base.
That aside, you think it will take 1-2 years for Orocos v2 to stabilize? So potentially to September 2012.
I would agree with Klass, that v1.6 was probably the begining of stability for the v1 series. That was approximately 5 years after v1.0 (data below). Certainly hope we don't have to wait that long with v2 ... ;-)
Version Release Delta (months)
v1 v2
v1.0 Oct 2003 -
v1.2 May 2005 19
v1.4 Nov 2007 30
v1.6 Dec 2008 13
v1.8 Feb 2009 3
v1.10 Sep 2009 7
v2.0 Sep 2010 -
v1.12 Oct 2010 13
v2.1 Oct 2010 1
v2.2 Jan 2011 3
v2.3 Feb 2011 1
[data taken from git logs prior v1.6, otherwise http://people.mech.kuleuven.be/~orocos/pub/stable/rtt/]
The place for sharing users component
On Wed, 23 Feb 2011, Klaas Gadeyne wrote:
> [...]
>> I'm with Herman on this one. Orocos' biggest fault is that it is developer-centric, not user-centric. IMHO
>> trimming down OCL was an example of this. The project is wonderful for developers. It is tough to be a user
>> in this ecosystem.
>
> This is "spot-on". I thought it deserved a more prominent view on the
> www, so I decided to isolate it from its context :-)
>
> Considering myself an "advanced (1.x) user", even at the point where
> 2.3 (2.0, 2.1, 2.2, 2.3) is going to be released soon, I have
> _absolutely no clear view_ of what would be the implications (benefits
> _and_ disadvantages) of moving to the 2.x series. 1.x had a high
> getting-started-threshold, I'm afraid it just got worse...
No, it got better :-) At least for a newcomer without 1.x legacy...
>From a high-level point of view, the improvements are in a somewhat better
decoupling, mostly via giving "services" a first class position in the
framework. This concept is extremely similar to the concept of "web
services", but with very different performance features, of course.
The roadmap to 3.0, at the same high-level point of view, is going even
further in the decoupling road, plus an improvement of tooling.
Of course, this is basically only the KUL part of the roadmap. Since Orocos
is an international project, other developers should contribute to that
roadmap too.
> YMMV,
Indeed.
> Klaas
Herman
The place for sharing users component
On Feb 23, 2011, at 03:43 , Herman Bruyninckx wrote:
> On Wed, 23 Feb 2011, Klaas Gadeyne wrote:
>
>> [...]
>>> I'm with Herman on this one. Orocos' biggest fault is that it is developer-centric, not user-centric. IMHO
>>> trimming down OCL was an example of this. The project is wonderful for developers. It is tough to be a user
>>> in this ecosystem.
>>
>> This is "spot-on". I thought it deserved a more prominent view on the
>> www, so I decided to isolate it from its context :-)
>>
>> Considering myself an "advanced (1.x) user", even at the point where
>> 2.3 (2.0, 2.1, 2.2, 2.3) is going to be released soon, I have
>> _absolutely no clear view_ of what would be the implications (benefits
>> _and_ disadvantages) of moving to the 2.x series. 1.x had a high
>> getting-started-threshold, I'm afraid it just got worse...
>
> No, it got better :-) At least for a newcomer without 1.x legacy...
No, it didn't. Look a the churn and turmoil on the ML the past few months ...
>> From a high-level point of view, the improvements are in a somewhat better
> decoupling, mostly via giving "services" a first class position in the
> framework. This concept is extremely similar to the concept of "web
> services", but with very different performance features, of course.
And conceptually that has been a wonderful thing. Upgrading to v2 from a programmatic point of view is greatly simplified by Peter's scripts. It is all the other changes in v2 that have been causing issues. Perhaps we jumped too far, too fast ...?
> The roadmap to 3.0, at the same high-level point of view, is going even
> further in the decoupling road, plus an improvement of tooling.
>
> Of course, this is basically only the KUL part of the roadmap. Since Orocos
> is an international project, other developers should contribute to that
> roadmap too.
Can you add that to the wiki then please, and with any more detail that you can provide? While it may be KUL-only, you are still a massive driver behind this project. It is nice for the community to have some idea of your direction, if only so we can plan on helping and/or coping with the changes.
S