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 Wed, 23 Feb 2011, S Roderick wrote:
> 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 ...
Those are _transition dynamics_! Very natural, necessary and familiar to
anyone working with large-scale open source projects. Also the Linux kernel
and ecosystem are constantly in this kind or turmoil. Distributors are the
place to make user-centric versions, with more stable configurations and
tools.
I think the comparison above is the only fair one: this project is indeed
developer driven, and it welcomes cooperation with "distributors" that will
take care of the (new) users. _You_ are playing that role of "distributor"
for your customers, and it is not an easy role, I know. But if Orocos
misses something, than it is an ecosystem of such "distributors".
>>> 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 ...?
Maybe. But most of these jumps were, as you mentioned, developer-driven,
which means they are getting some level of support in getting them more
stable. All natural dynamics of a project, I think.
>> 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.
Currently, the roadmap is not clear enough to put on the wiki. What I
mentioned above is, I think, not very informative, unless it is expanded
into more concrete goals. We are working on that, on and off, and it will
be posted there, after discussion on the mailing lists .
What you ask for is fair and right, but also our resources are limited :-)
> S
Herman
The place for sharing users component
On Feb 23, 2011, at 06:44 , Herman Bruyninckx wrote:
> On Wed, 23 Feb 2011, S Roderick wrote:
>
>> 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 ...
>
> Those are _transition dynamics_! Very natural, necessary and familiar to
> anyone working with large-scale open source projects. Also the Linux kernel
> and ecosystem are constantly in this kind or turmoil. Distributors are the
> place to make user-centric versions, with more stable configurations and
> tools.
The dynamics are expected, I agree. I was expecting them to have begun to die down by now. Not increase.
> I think the comparison above is the only fair one: this project is indeed
> developer driven, and it welcomes cooperation with "distributors" that will
> take care of the (new) users. _You_ are playing that role of "distributor"
> for your customers, and it is not an easy role, I know. But if Orocos
> misses something, than it is an ecosystem of such "distributors".
That is an interesting idea. While I'm not sure I completely agree with the definition, there is certainly something to it. And I never considered some of us as "distributors". What role do you think that they play in the ecosystem?
But if you think that distributors are the only ones that need to help with new users, then I think that is dangerous territory for a project to wander into. As a community we need to foster new users. That was one of the conclusions of [1] - you need to foster users, _and_ you need to foster users becoming contributors (aka developers). Without this, the natural turnover of a project will kill the project.
[1] http://www.cyber-anthro.com/beta-an-exploration-of-fedora’s-online-open-source-development-community/
The place for sharing users component
On Thu, 24 Feb 2011, Stephen Roderick wrote:
> On Feb 23, 2011, at 06:44 , Herman Bruyninckx wrote:
>
>> On Wed, 23 Feb 2011, S Roderick wrote:
>>
>>> 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 ...
>>
>> Those are _transition dynamics_! Very natural, necessary and familiar to
>> anyone working with large-scale open source projects. Also the Linux kernel
>> and ecosystem are constantly in this kind or turmoil. Distributors are the
>> place to make user-centric versions, with more stable configurations and
>> tools.
>
> The dynamics are expected, I agree. I was expecting them to have begun to die down by now. Not increase.
>
My expectation is completely the opposite. I really hope I am wrong...
>> I think the comparison above is the only fair one: this project is indeed
>> developer driven, and it welcomes cooperation with "distributors" that will
>> take care of the (new) users. _You_ are playing that role of "distributor"
>> for your customers, and it is not an easy role, I know. But if Orocos
>> misses something, than it is an ecosystem of such "distributors".
>
> That is an interesting idea. While I'm not sure I completely agree with
> the definition, there is certainly something to it. And I never
> considered some of us as "distributors". What role do you think that they
> play in the ecosystem?
The very important role between the developers and the users. I do think
the comparison with the Linux ecosystem holds rather well. Of course, at a
much smaller scale.
> But if you think that distributors are the only ones that need to help
> with new users, then I think that is dangerous territory for a project to
> wander into. As a community we need to foster new users. That was one of
> the conclusions of [1] - you need to foster users, _and_ you need to
> foster users becoming contributors (aka developers). Without this, the
> natural turnover of a project will kill the project.
Right. But Orocos wants the _distributors_ to be our users, and not the end
users that use a robot. Again, 100% similar to the Linux case. (And the
Eclipse case, the MySQL case, the Qt case,...)
> [1] http://www.cyber-anthro.com/beta-an-exploration-of-fedora’s-online-open-source-development-community/
The definition of "user" in the Fedora case is at a different level!
"Fedora" is a "user" for Linux, "I" am a user for Fedora, not for "Linux".
Herman
The place for sharing users component
2011/2/24 Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...>
> On Thu, 24 Feb 2011, Stephen Roderick wrote:
>
> On Feb 23, 2011, at 06:44 , Herman Bruyninckx wrote:
>>
>> On Wed, 23 Feb 2011, S Roderick wrote:
>>>
>>> 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 ...
>>>>
>>>
>>> Those are _transition dynamics_! Very natural, necessary and familiar to
>>> anyone working with large-scale open source projects. Also the Linux
>>> kernel
>>> and ecosystem are constantly in this kind or turmoil. Distributors are
>>> the
>>> place to make user-centric versions, with more stable configurations and
>>> tools.
>>>
>>
>> The dynamics are expected, I agree. I was expecting them to have begun to
>> die down by now. Not increase.
>>
>> My expectation is completely the opposite. I really hope I am wrong...
>
>
> I think the comparison above is the only fair one: this project is indeed
>>> developer driven, and it welcomes cooperation with "distributors" that
>>> will
>>> take care of the (new) users. _You_ are playing that role of
>>> "distributor"
>>> for your customers, and it is not an easy role, I know. But if Orocos
>>> misses something, than it is an ecosystem of such "distributors".
>>>
>>
>> That is an interesting idea. While I'm not sure I completely agree with
>> the definition, there is certainly something to it. And I never
>> considered some of us as "distributors". What role do you think that they
>> play in the ecosystem?
>>
>
> The very important role between the developers and the users. I do think
> the comparison with the Linux ecosystem holds rather well. Of course, at a
> much smaller scale.
>
>
To my very unaccurate knowledge of Linux history, Linux exists because Linus
Torwalds was a Minix user and get pissed off the non developper wish to
reacts to its users, so he splits and Minix died... The current user of
Orocos are not distributors but users. It's a fact and I think it is the
responsability of Orocos to help the user community into transforming into a
distributor community. I am sure that at the beginning Linux where
interfacing with user and not with distributors.
>
> But if you think that distributors are the only ones that need to help
>> with new users, then I think that is dangerous territory for a project to
>> wander into. As a community we need to foster new users. That was one of
>> the conclusions of [1] - you need to foster users, _and_ you need to
>> foster users becoming contributors (aka developers). Without this, the
>> natural turnover of a project will kill the project.
>>
>
> Right. But Orocos wants the _distributors_ to be our users, and not the end
> users that use a robot. Again, 100% similar to the Linux case. (And the
> Eclipse case, the MySQL case, the Qt case,...)
>
>
> [1] http://www.cyber-anthro.com/beta-an-exploration-of-fedora
>> ’s-online-open-source-development-community/
>>
>
> The definition of "user" in the Fedora case is at a different level!
> "Fedora" is a "user" for Linux, "I" am a user for Fedora, not for "Linux".
>
> Herman
> --
> Orocos-Users mailing list
> Orocos-Users [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>
>
The place for sharing users component
On Thursday 24 February 2011 13:45:45 Stephen Roderick wrote:
> On Feb 23, 2011, at 06:44 , Herman Bruyninckx wrote:
> > On Wed, 23 Feb 2011, S Roderick wrote:
> >> 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 ...
> >
> > Those are _transition dynamics_! Very natural, necessary and familiar to
> > anyone working with large-scale open source projects. Also the Linux
> > kernel and ecosystem are constantly in this kind or turmoil.
> > Distributors are the place to make user-centric versions, with more
> > stable configurations and tools.
>
> The dynamics are expected, I agree. I was expecting them to have begun to
> die down by now. Not increase.
IMO the current increase of issues we see today is the increase of our
userbase, and these users also bring new use-cases of the Orocos Toolchain,
and new development processes which make them bump into issues we have not
foreseen because we (the current/past userbase) always use a limited set of
different development process ourselves.
-- Ruben
The place for sharing users component
On Feb 24, 2011, at 07:57 , Ruben Smits wrote:
> On Thursday 24 February 2011 13:45:45 Stephen Roderick wrote:
>> On Feb 23, 2011, at 06:44 , Herman Bruyninckx wrote:
>>> On Wed, 23 Feb 2011, S Roderick wrote:
>>>> 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 ...
>>>
>>> Those are _transition dynamics_! Very natural, necessary and familiar to
>>> anyone working with large-scale open source projects. Also the Linux
>>> kernel and ecosystem are constantly in this kind or turmoil.
>>> Distributors are the place to make user-centric versions, with more
>>> stable configurations and tools.
>>
>> The dynamics are expected, I agree. I was expecting them to have begun to
>> die down by now. Not increase.
>
> IMO the current increase of issues we see today is the increase of our
> userbase, and these users also bring new use-cases of the Orocos Toolchain,
> and new development processes which make them bump into issues we have not
> foreseen because we (the current/past userbase) always use a limited set of
> different development process ourselves.
Very true, I agree. I think the integration with both ROS and Rock are a huge piece of the recent ML churn. These integrations are definitely a good thing! Also, the win32 updates of v2.3 are a great thing also.
One of the things that I'm concerned about is the lower level churn within RTT. For example, it seems like the type system keeps getting monkeyed with, and issues with things like the filesystem structure of plugins vs libraries, etc., keep coming up. It doesn't appear (from the outside) that these have actually been solved.
S
The place for sharing users component
On Wed, Feb 23, 2011 at 09:15, Klaas Gadeyne <klaas [dot] 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...
>
> YMMV,
>
> Klaas
> --
Yeah... and this is reflected even in the documentation for example
there is no "How to set up an Eclipse Project from scratch". i am
working on one but I am at the moment learning CMake and how to have
CMake work with Eclipse in order to figure out the steps necessary to
run the RTT examples. Instead of just create a simple Hello and making
work with an IDE or editor (doesn't matter which one at this point as
long as it shows how to do it)
I think when writing examples and tutorials and eventually for all the
functionality that Orocos provides that we should refocus our effort
on the following users:
Engineer and Application Developer
NOT as we currently do on the:
Expert Component Developer
Component Framework Builder
Expert Application Developer
Robotic Software Builder
Which I define below in order to build the IDE:
We use a simplified version of Personas to describe our users. Our
users are categorized by expertize level which roughly corresponds to
educational attainment. At Katholieke Universiteit Leuven (KUL) we
focus on component based software. Component based software might or
not be used at other research facilities yet the following categories
can be translated to the context of those researchers that use other
software approaches.
KUL:
Engineer
Application Developer
Expert Component Developer
Component Framework Builder
Non KUL:
Engineer
Application Developer
Expert Application Developer
Robotic Software Builder
The Engineer is usually someone starting the Masters or Ph. D.
program. They might have a basic general knowledge of the robotic
field. Her knowledge of software development will be basic or nil. Due
to the nature of the robotic field, they might not necessarily have a
Mechanical Engineering background (eg Electrical Engineering,
Mathematics, Industrial Engineering) Some will be have a computer
science background yet even then might not be familiar with modern
software practices, principles, methodology or software development
tools. Goal: To quickly learn the necessary basics of component based
software within the focus of their immediate task. They need a simple
process for building software and an easy to use IDE. They would like
code generation to be available. Extensive help documents should be
available to them. Examples projects and/or templates for coding
should be available to them. It should be cool and fun.
The Application Developer is someone at the end of their Masters
program or midway in their Ph. D. program. They have knowledge of
software development albeit this knowledge is in the manner of “what
works”. They usually specialize in one aspect of robotic research and
might have knowledge of other researcher via their colleagues. They
have a basic understanding of real time software. They have mastered
enough of a computer language, C++ and or Python, in order to perform
“cut and paste” development. They have enough conceptual knowledge of
the component framework for understanding how it works and how to
build an application. The applications built are usually similar to
other applications built by more expert users. Application Developers
still depend on more expert user in order to perform their tasks. They
might use an IDE but not all its features. The knowledge of other
tools that might do the job better is not actively pursued unless
necessary. Goal: To build component software quickly in order to
perform iterative experimentation with an application(s) specific to
their research. Hot-plugging of components into a live system is a
nice thing to do. Monitoring the state of the application as part of
their experiment is necessary. Being able to easily simulate their
system is something that would help a lot. Advanced help should be
available. Reporting and logging tools are essential for data
gathering. Integration to other data and mathematical analysis
software is an advantage. They must feel empowered.
The Expert Application Developer will be an advanced Ph. D student or
post-doc. It is rare for a Master level student to achieve this level.
They have a very good grounded theoretical and practical knowledge of
their research field and are able to contribute to other fields in
robotic research. They have a home built robotic software development
process fully developed and might and will explore other best
practices in software development in order to improve their process.
They are highly proficient in their computer language of choice and
might have knowledge of other languages or the function of operating
systems. They are familiar with real time software development. They
might be able to modify the component framework and the source of
other software tools to suit their needs. They usually help and or
teach Engineers and Application Developer with their work. They are
familiar with an IDE and use it proficiently in order to perform their
work efficiently. They might research other software tools that can do
a particular task better than the current tools they are using. Goal:
To apply their coding and theoretical know-how beyond their initial
findings and find new ways of expanding upon their work withing the
framework of their research domain. They might need to create new
component and/or modify the base software packages they use such as
the component framework or algorithms used in their research. Their
motto: “I think therefore I code” They are samurai and their IDE is
their sword.
The Component Framework Builder. Is an an expert in developing new
software from scratch. She is also an expert in robotic software able
to write such arcane software as hardware drivers in C. They have a
very good knowledge of best practices in robotics. They have a very
good knowledge of current software development processes. They are
adept in using an IDE and command line tools. They can write their own
command line tools as needed. They have a high comprehension of the
operating systems used in the field. They think in real time. They are
active contributers in the robotic field. Goal: To expand the
component framework beyond the current limitations encountered by
users of the software. For them the IDE is something for lesser beings
but it is cool that it works. Their motto: “To Emacs or not to Emacs,
that is the question.”
-H
--
Orocos-Users mailing list
Orocos-Users [..] ...
http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
The place for sharing users component
On Feb 23, 2011, at 03:38 , Hugo Garcia wrote:
> On Wed, Feb 23, 2011 at 09:15, Klaas Gadeyne <klaas [dot] 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...
>>
>> YMMV,
>>
>> Klaas
>> --
>
> Yeah... and this is reflected even in the documentation for example
> there is no "How to set up an Eclipse Project from scratch". i am
> working on one but I am at the moment learning CMake and how to have
> CMake work with Eclipse in order to figure out the steps necessary to
> run the RTT examples. Instead of just create a simple Hello and making
> work with an IDE or editor (doesn't matter which one at this point as
> long as it shows how to do it)
>
> I think when writing examples and tutorials and eventually for all the
> functionality that Orocos provides that we should refocus our effort
> on the following users:
>
> Engineer and Application Developer
Interesting role definitions. I would argue that Orocos to date has aimed at Expert Application Developer and above. This can not be sustained long term. It provides such a massive step up for new users to reach this level, before than can do anything useful and fun. They leave early instead.
I agree that given your role definitions, we should aim at no higher than Application Developer
S
>
> NOT as we currently do on the:
>
> Expert Component Developer
> Component Framework Builder
> Expert Application Developer
> Robotic Software Builder
>
> Which I define below in order to build the IDE:
>
> We use a simplified version of Personas to describe our users. Our
> users are categorized by expertize level which roughly corresponds to
> educational attainment. At Katholieke Universiteit Leuven (KUL) we
> focus on component based software. Component based software might or
> not be used at other research facilities yet the following categories
> can be translated to the context of those researchers that use other
> software approaches.
>
> KUL:
> Engineer
> Application Developer
> Expert Component Developer
> Component Framework Builder
>
> Non KUL:
> Engineer
> Application Developer
> Expert Application Developer
> Robotic Software Builder
>
> The Engineer is usually someone starting the Masters or Ph. D.
> program. They might have a basic general knowledge of the robotic
> field. Her knowledge of software development will be basic or nil. Due
> to the nature of the robotic field, they might not necessarily have a
> Mechanical Engineering background (eg Electrical Engineering,
> Mathematics, Industrial Engineering) Some will be have a computer
> science background yet even then might not be familiar with modern
> software practices, principles, methodology or software development
> tools. Goal: To quickly learn the necessary basics of component based
> software within the focus of their immediate task. They need a simple
> process for building software and an easy to use IDE. They would like
> code generation to be available. Extensive help documents should be
> available to them. Examples projects and/or templates for coding
> should be available to them. It should be cool and fun.
>
> The Application Developer is someone at the end of their Masters
> program or midway in their Ph. D. program. They have knowledge of
> software development albeit this knowledge is in the manner of “what
> works”. They usually specialize in one aspect of robotic research and
> might have knowledge of other researcher via their colleagues. They
> have a basic understanding of real time software. They have mastered
> enough of a computer language, C++ and or Python, in order to perform
> “cut and paste” development. They have enough conceptual knowledge of
> the component framework for understanding how it works and how to
> build an application. The applications built are usually similar to
> other applications built by more expert users. Application Developers
> still depend on more expert user in order to perform their tasks. They
> might use an IDE but not all its features. The knowledge of other
> tools that might do the job better is not actively pursued unless
> necessary. Goal: To build component software quickly in order to
> perform iterative experimentation with an application(s) specific to
> their research. Hot-plugging of components into a live system is a
> nice thing to do. Monitoring the state of the application as part of
> their experiment is necessary. Being able to easily simulate their
> system is something that would help a lot. Advanced help should be
> available. Reporting and logging tools are essential for data
> gathering. Integration to other data and mathematical analysis
> software is an advantage. They must feel empowered.
>
> The Expert Application Developer will be an advanced Ph. D student or
> post-doc. It is rare for a Master level student to achieve this level.
> They have a very good grounded theoretical and practical knowledge of
> their research field and are able to contribute to other fields in
> robotic research. They have a home built robotic software development
> process fully developed and might and will explore other best
> practices in software development in order to improve their process.
> They are highly proficient in their computer language of choice and
> might have knowledge of other languages or the function of operating
> systems. They are familiar with real time software development. They
> might be able to modify the component framework and the source of
> other software tools to suit their needs. They usually help and or
> teach Engineers and Application Developer with their work. They are
> familiar with an IDE and use it proficiently in order to perform their
> work efficiently. They might research other software tools that can do
> a particular task better than the current tools they are using. Goal:
> To apply their coding and theoretical know-how beyond their initial
> findings and find new ways of expanding upon their work withing the
> framework of their research domain. They might need to create new
> component and/or modify the base software packages they use such as
> the component framework or algorithms used in their research. Their
> motto: “I think therefore I code” They are samurai and their IDE is
> their sword.
>
> The Component Framework Builder. Is an an expert in developing new
> software from scratch. She is also an expert in robotic software able
> to write such arcane software as hardware drivers in C. They have a
> very good knowledge of best practices in robotics. They have a very
> good knowledge of current software development processes. They are
> adept in using an IDE and command line tools. They can write their own
> command line tools as needed. They have a high comprehension of the
> operating systems used in the field. They think in real time. They are
> active contributers in the robotic field. Goal: To expand the
> component framework beyond the current limitations encountered by
> users of the software. For them the IDE is something for lesser beings
> but it is cool that it works. Their motto: “To Emacs or not to Emacs,
> that is the question.”
>
>
> -H
The place for sharing users component
On Wednesday 23 February 2011 09:38:58 Hugo Garcia wrote:
> On Wed, Feb 23, 2011 at 09:15, Klaas Gadeyne <klaas [dot] 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...
> >
> > YMMV,
> >
> > Klaas
> > --
>
> Yeah... and this is reflected even in the documentation for example
> there is no "How to set up an Eclipse Project from scratch". i am
> working on one but I am at the moment learning CMake and how to have
> CMake work with Eclipse in order to figure out the steps necessary to
> run the RTT examples. Instead of just create a simple Hello and making
> work with an IDE or editor (doesn't matter which one at this point as
> long as it shows how to do it)
This is fairly simple, the exercises already have a CMakeLists.txt, so you
just have to run:
cmake . -G Eclipse\ CDT4\ -\ Unix\ Makefiles
This will create the eclipse project files for you. After that you just include
the project in your Eclipse workspace.
-- Ruben
> I think when writing examples and tutorials and eventually for all the
> functionality that Orocos provides that we should refocus our effort
> on the following users:
>
> Engineer and Application Developer
>
> NOT as we currently do on the:
>
> Expert Component Developer
> Component Framework Builder
> Expert Application Developer
> Robotic Software Builder
>
> Which I define below in order to build the IDE:
>
> We use a simplified version of Personas to describe our users. Our
> users are categorized by expertize level which roughly corresponds to
> educational attainment. At Katholieke Universiteit Leuven (KUL) we
> focus on component based software. Component based software might or
> not be used at other research facilities yet the following categories
> can be translated to the context of those researchers that use other
> software approaches.
>
> KUL:
> Engineer
> Application Developer
> Expert Component Developer
> Component Framework Builder
>
> Non KUL:
> Engineer
> Application Developer
> Expert Application Developer
> Robotic Software Builder
>
> The Engineer is usually someone starting the Masters or Ph. D.
> program. They might have a basic general knowledge of the robotic
> field. Her knowledge of software development will be basic or nil. Due
> to the nature of the robotic field, they might not necessarily have a
> Mechanical Engineering background (eg Electrical Engineering,
> Mathematics, Industrial Engineering) Some will be have a computer
> science background yet even then might not be familiar with modern
> software practices, principles, methodology or software development
> tools. Goal: To quickly learn the necessary basics of component based
> software within the focus of their immediate task. They need a simple
> process for building software and an easy to use IDE. They would like
> code generation to be available. Extensive help documents should be
> available to them. Examples projects and/or templates for coding
> should be available to them. It should be cool and fun.
>
> The Application Developer is someone at the end of their Masters
> program or midway in their Ph. D. program. They have knowledge of
> software development albeit this knowledge is in the manner of “what
> works”. They usually specialize in one aspect of robotic research and
> might have knowledge of other researcher via their colleagues. They
> have a basic understanding of real time software. They have mastered
> enough of a computer language, C++ and or Python, in order to perform
> “cut and paste” development. They have enough conceptual knowledge of
> the component framework for understanding how it works and how to
> build an application. The applications built are usually similar to
> other applications built by more expert users. Application Developers
> still depend on more expert user in order to perform their tasks. They
> might use an IDE but not all its features. The knowledge of other
> tools that might do the job better is not actively pursued unless
> necessary. Goal: To build component software quickly in order to
> perform iterative experimentation with an application(s) specific to
> their research. Hot-plugging of components into a live system is a
> nice thing to do. Monitoring the state of the application as part of
> their experiment is necessary. Being able to easily simulate their
> system is something that would help a lot. Advanced help should be
> available. Reporting and logging tools are essential for data
> gathering. Integration to other data and mathematical analysis
> software is an advantage. They must feel empowered.
>
> The Expert Application Developer will be an advanced Ph. D student or
> post-doc. It is rare for a Master level student to achieve this level.
> They have a very good grounded theoretical and practical knowledge of
> their research field and are able to contribute to other fields in
> robotic research. They have a home built robotic software development
> process fully developed and might and will explore other best
> practices in software development in order to improve their process.
> They are highly proficient in their computer language of choice and
> might have knowledge of other languages or the function of operating
> systems. They are familiar with real time software development. They
> might be able to modify the component framework and the source of
> other software tools to suit their needs. They usually help and or
> teach Engineers and Application Developer with their work. They are
> familiar with an IDE and use it proficiently in order to perform their
> work efficiently. They might research other software tools that can do
> a particular task better than the current tools they are using. Goal:
> To apply their coding and theoretical know-how beyond their initial
> findings and find new ways of expanding upon their work withing the
> framework of their research domain. They might need to create new
> component and/or modify the base software packages they use such as
> the component framework or algorithms used in their research. Their
> motto: “I think therefore I code” They are samurai and their IDE is
> their sword.
>
> The Component Framework Builder. Is an an expert in developing new
> software from scratch. She is also an expert in robotic software able
> to write such arcane software as hardware drivers in C. They have a
> very good knowledge of best practices in robotics. They have a very
> good knowledge of current software development processes. They are
> adept in using an IDE and command line tools. They can write their own
> command line tools as needed. They have a high comprehension of the
> operating systems used in the field. They think in real time. They are
> active contributers in the robotic field. Goal: To expand the
> component framework beyond the current limitations encountered by
> users of the software. For them the IDE is something for lesser beings
> but it is cool that it works. Their motto: “To Emacs or not to Emacs,
> that is the question.”
>
>
> -H
--
Orocos-Users mailing list
Orocos-Users [..] ...
http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users