reworking OCL / best practice examples

Dear List,

OCL (the OROCOS Component Library) was mentioned in the ongoing
discussions several times for documenting good ways to solve problems,
i.e. best practices.

As this is one of my course assignments, I'd like to start some
discussion on how this should be done.

What we want is some good examples which are well documented and show
how to solve some common problems. They should run without specific
hardware and involve the cartesian and naxes components.

The question is, should these example reside within OCL or be a new
higher-level subproject, e.g. BPL (best practices library?)

Suggestions are welcome

Markus

reworking OCL / best practice examples

On Thu, 25 Jun 2009, Markus Klotzbuecher wrote:

> On Wed, Jun 24, 2009 at 09:14:41AM +0200, Herman Bruyninckx wrote:
>> On Wed, 24 Jun 2009, Markus Klotzbuecher wrote:
>>
>>> On Wed, Jun 24, 2009 at 08:39:35AM +0200, Herman Bruyninckx wrote:
>>>> On Wed, 24 Jun 2009, Markus Klotzbuecher wrote:
> ...
>
>>> 1) The library of ready to run components: the current OCL (without
>>> hello_world)
>>>
>>> 2) the examples: the hello-worlds, the application templates, maybe
>>> Peters exercises?
>>>
>>> Questions are:
>>>
>>> Shall 1) stay be with the name OCL or be renamed to OCR or
>>> "component-library" ?
>>
>> "OCL" can go! It has not been able to create significantly positive
>> "legacy" anyway. 1) should become the "demos" subproject.
>
> But it's actually not demos in there, its, huh, a library of
> (ready-to-run) components... The acronym may be confusing but I do
> think "component-library" or "component-repository" would be more
> appropriate!

I don't think so! It _should_ become demos, that is, full-fledged
applications for which even binaries could be provided for a small set of
platforms. "library" or "repository" stuff (that is, things that you have
to work on yourself still before they "do something") should be separted
from the "demos", in another directory. We _need_ demos, even one with a
"GUI" such as a connection with Blender. I will have a summer intern doing
some work in Blender to visualise a report coming from an Orocos
application; connection these things together and provide them as "demo"
would make an impact (and is feasible for all common platform, as far as
Blender is concerned). And Blender is a _very small_ download compared to
what it offers :-)

>>> How shall 2) be called?
>>
>> "application (architecture) templates" or something similar.
>
> That would be fine for me!

Herman

reworking OCL / best practice examples

On Thu, Jun 25, 2009 at 08:46:44AM +0200, Herman Bruyninckx wrote:
> On Thu, 25 Jun 2009, Markus Klotzbuecher wrote:
>
> > On Wed, Jun 24, 2009 at 09:14:41AM +0200, Herman Bruyninckx wrote:
> >> On Wed, 24 Jun 2009, Markus Klotzbuecher wrote:
> >>
> >>> On Wed, Jun 24, 2009 at 08:39:35AM +0200, Herman Bruyninckx wrote:
> >>>> On Wed, 24 Jun 2009, Markus Klotzbuecher wrote:
> > ...
> >
> >>> 1) The library of ready to run components: the current OCL (without
> >>> hello_world)
> >>>
> >>> 2) the examples: the hello-worlds, the application templates, maybe
> >>> Peters exercises?
> >>>
> >>> Questions are:
> >>>
> >>> Shall 1) stay be with the name OCL or be renamed to OCR or
> >>> "component-library" ?
> >>
> >> "OCL" can go! It has not been able to create significantly positive
> >> "legacy" anyway. 1) should become the "demos" subproject.
> >
> > But it's actually not demos in there, its, huh, a library of
> > (ready-to-run) components... The acronym may be confusing but I do
> > think "component-library" or "component-repository" would be more
> > appropriate!
>
> I don't think so! It _should_ become demos, that is, full-fledged
> applications for which even binaries could be provided for a small set of
> platforms. "library" or "repository" stuff (that is, things that you have
> to work on yourself still before they "do something") should be separted
> from the "demos", in another directory. We _need_ demos, even one with a
> "GUI" such as a connection with Blender. I will have a summer intern doing
> some work in Blender to visualise a report coming from an Orocos
> application; connection these things together and provide them as "demo"
> would make an impact (and is feasible for all common platform, as far as
> Blender is concerned). And Blender is a _very small_ download compared to
> what it offers :-)

Ok, so then we have three items:

1) orocos-components (former OCL, the library, the ready to run
building blocks for system builders.

2) demos: ready to run applications (maybe the hello-worlds fit here?)

3) systems templates

Agreed?

Markus

reworking OCL / best practice examples

On Thu, 25 Jun 2009, Markus Klotzbuecher wrote:

> On Thu, Jun 25, 2009 at 08:46:44AM +0200, Herman Bruyninckx wrote:
>> On Thu, 25 Jun 2009, Markus Klotzbuecher wrote:
>>
>>> On Wed, Jun 24, 2009 at 09:14:41AM +0200, Herman Bruyninckx wrote:
>>>> On Wed, 24 Jun 2009, Markus Klotzbuecher wrote:
>>>>
>>>>> On Wed, Jun 24, 2009 at 08:39:35AM +0200, Herman Bruyninckx wrote:
>>>>>> On Wed, 24 Jun 2009, Markus Klotzbuecher wrote:
>>> ...
>>>
>>>>> 1) The library of ready to run components: the current OCL (without
>>>>> hello_world)
>>>>>
>>>>> 2) the examples: the hello-worlds, the application templates, maybe
>>>>> Peters exercises?
>>>>>
>>>>> Questions are:
>>>>>
>>>>> Shall 1) stay be with the name OCL or be renamed to OCR or
>>>>> "component-library" ?
>>>>
>>>> "OCL" can go! It has not been able to create significantly positive
>>>> "legacy" anyway. 1) should become the "demos" subproject.
>>>
>>> But it's actually not demos in there, its, huh, a library of
>>> (ready-to-run) components... The acronym may be confusing but I do
>>> think "component-library" or "component-repository" would be more
>>> appropriate!
>>
>> I don't think so! It _should_ become demos, that is, full-fledged
>> applications for which even binaries could be provided for a small set of
>> platforms. "library" or "repository" stuff (that is, things that you have
>> to work on yourself still before they "do something") should be separted
>> from the "demos", in another directory. We _need_ demos, even one with a
>> "GUI" such as a connection with Blender. I will have a summer intern doing
>> some work in Blender to visualise a report coming from an Orocos
>> application; connection these things together and provide them as "demo"
>> would make an impact (and is feasible for all common platform, as far as
>> Blender is concerned). And Blender is a _very small_ download compared to
>> what it offers :-)
>
> Ok, so then we have three items:
>
> 1) orocos-components (former OCL, the library, the ready to run
> building blocks for system builders.
>
> 2) demos: ready to run applications (maybe the hello-worlds fit here?)
Indeed.

> 3) systems templates
>
> Agreed?
>
Mostly...

The naming should be a bit more consisten; for example, either
"orocos components", "orocos demos", and "orocos systems templates", or
everything without the "orocos". I think the former makes sense, since all
these directories live in the "orocos" name space anyway.

Herman

reworking OCL / best practice examples

On Thu, Jun 25, 2009 at 12:48:09PM +0200, Herman Bruyninckx wrote:
> On Thu, 25 Jun 2009, Markus Klotzbuecher wrote:
> > On Thu, Jun 25, 2009 at 08:46:44AM +0200, Herman Bruyninckx wrote:
> >> On Thu, 25 Jun 2009, Markus Klotzbuecher wrote:

> > Ok, so then we have three items:
> >
> > 1) orocos-components (former OCL, the library, the ready to run
> > building blocks for system builders.
> >
> > 2) demos: ready to run applications (maybe the hello-worlds fit here?)
> Indeed.
>
> > 3) systems templates
> >
> > Agreed?
> >
> Mostly...
>
> The naming should be a bit more consisten; for example, either
> "orocos components", "orocos demos", and "orocos systems templates", or
> everything without the "orocos". I think the former makes sense, since all
> these directories live in the "orocos" name space anyway.

Ok, agreed! So the next question is how shall these items should be
partitioned with respect to SC repositories? All in individual ones?
All in one? I think I favour all in one. If you agree, how call the
top-level repository containing "component-library", "demos", and
"system-templates"?

Tough questions!
Markus

reworking OCL / best practice examples

On Jun 25, 2009, at 06:48 , Herman Bruyninckx wrote:

> On Thu, 25 Jun 2009, Markus Klotzbuecher wrote:
>
>> On Thu, Jun 25, 2009 at 08:46:44AM +0200, Herman Bruyninckx wrote:
>>> On Thu, 25 Jun 2009, Markus Klotzbuecher wrote:
>>>
>>>> On Wed, Jun 24, 2009 at 09:14:41AM +0200, Herman Bruyninckx wrote:
>>>>> On Wed, 24 Jun 2009, Markus Klotzbuecher wrote:
>>>>>
>>>>>> On Wed, Jun 24, 2009 at 08:39:35AM +0200, Herman Bruyninckx
>>>>>> wrote:
>>>>>>> On Wed, 24 Jun 2009, Markus Klotzbuecher wrote:
>>>> ...
>>>>
>>>>>> 1) The library of ready to run components: the current OCL
>>>>>> (without
>>>>>> hello_world)
>>>>>>
>>>>>> 2) the examples: the hello-worlds, the application templates,
>>>>>> maybe
>>>>>> Peters exercises?
>>>>>>
>>>>>> Questions are:
>>>>>>
>>>>>> Shall 1) stay be with the name OCL or be renamed to OCR or
>>>>>> "component-library" ?
>>>>>
>>>>> "OCL" can go! It has not been able to create significantly
>>>>> positive
>>>>> "legacy" anyway. 1) should become the "demos" subproject.
>>>>
>>>> But it's actually not demos in there, its, huh, a library of
>>>> (ready-to-run) components... The acronym may be confusing but I do
>>>> think "component-library" or "component-repository" would be more
>>>> appropriate!
>>>
>>> I don't think so! It _should_ become demos, that is, full-fledged
>>> applications for which even binaries could be provided for a small
>>> set of
>>> platforms. "library" or "repository" stuff (that is, things that
>>> you have
>>> to work on yourself still before they "do something") should be
>>> separted
>>> from the "demos", in another directory. We _need_ demos, even one
>>> with a
>>> "GUI" such as a connection with Blender. I will have a summer
>>> intern doing
>>> some work in Blender to visualise a report coming from an Orocos
>>> application; connection these things together and provide them as
>>> "demo"
>>> would make an impact (and is feasible for all common platform, as
>>> far as
>>> Blender is concerned). And Blender is a _very small_ download
>>> compared to
>>> what it offers :-)
>>
>> Ok, so then we have three items:
>>
>> 1) orocos-components (former OCL, the library, the ready to run
>> building blocks for system builders.

I really haven't seen a compelling argument for changing names here.
OCL is a Library of useful Orocos Components. Seriously, what is wrong
with the acronym? Changing this will change a mountain of the "OCL"
code, as well as most of your community's code. As Klaas and I have
noted, we make major use of OCL and so we will have to go through and
"fix" all our code for the changes you make to the name (as you'll be
updating the namespace it is all in, won't you). What is the benefit
of this potentially unnecessary work???

NB in just *one* of the projects I use Orocos on, we have 600
instances of the term "ocl" spread over 400 files. One project, one
user. YMMV

>> 2) demos: ready to run applications (maybe the hello-worlds fit
>> here?)
> Indeed.
>
>> 3) systems templates
>>
>> Agreed?
>>
> Mostly...
>
> The naming should be a bit more consisten; for example, either
> "orocos components", "orocos demos", and "orocos systems templates",
> or
> everything without the "orocos". I think the former makes sense,
> since all
> these directories live in the "orocos" name space anyway.

Can you please define the _substantiative difference_ between "demos"
and "system templates", and how I would chose which to place an
example system/program/component in?

Cheers
S

reworking OCL / best practice examples

On Thu, 25 Jun 2009, S Roderick wrote:

> On Jun 25, 2009, at 06:48 , Herman Bruyninckx wrote:
>
>> On Thu, 25 Jun 2009, Markus Klotzbuecher wrote:
>>
>>> On Thu, Jun 25, 2009 at 08:46:44AM +0200, Herman Bruyninckx wrote:
>>>> On Thu, 25 Jun 2009, Markus Klotzbuecher wrote:
>>>>
>>>>> On Wed, Jun 24, 2009 at 09:14:41AM +0200, Herman Bruyninckx wrote:
>>>>>> On Wed, 24 Jun 2009, Markus Klotzbuecher wrote:
>>>>>>
>>>>>>> On Wed, Jun 24, 2009 at 08:39:35AM +0200, Herman Bruyninckx
>>>>>>> wrote:
>>>>>>>> On Wed, 24 Jun 2009, Markus Klotzbuecher wrote:
>>>>> ...
>>>>>
>>>>>>> 1) The library of ready to run components: the current OCL
>>>>>>> (without
>>>>>>> hello_world)
>>>>>>>
>>>>>>> 2) the examples: the hello-worlds, the application templates,
>>>>>>> maybe
>>>>>>> Peters exercises?
>>>>>>>
>>>>>>> Questions are:
>>>>>>>
>>>>>>> Shall 1) stay be with the name OCL or be renamed to OCR or
>>>>>>> "component-library" ?
>>>>>>
>>>>>> "OCL" can go! It has not been able to create significantly
>>>>>> positive
>>>>>> "legacy" anyway. 1) should become the "demos" subproject.
>>>>>
>>>>> But it's actually not demos in there, its, huh, a library of
>>>>> (ready-to-run) components... The acronym may be confusing but I do
>>>>> think "component-library" or "component-repository" would be more
>>>>> appropriate!
>>>>
>>>> I don't think so! It _should_ become demos, that is, full-fledged
>>>> applications for which even binaries could be provided for a small
>>>> set of
>>>> platforms. "library" or "repository" stuff (that is, things that
>>>> you have
>>>> to work on yourself still before they "do something") should be
>>>> separted
>>>> from the "demos", in another directory. We _need_ demos, even one
>>>> with a
>>>> "GUI" such as a connection with Blender. I will have a summer
>>>> intern doing
>>>> some work in Blender to visualise a report coming from an Orocos
>>>> application; connection these things together and provide them as
>>>> "demo"
>>>> would make an impact (and is feasible for all common platform, as
>>>> far as
>>>> Blender is concerned). And Blender is a _very small_ download
>>>> compared to
>>>> what it offers :-)
>>>
>>> Ok, so then we have three items:
>>>
>>> 1) orocos-components (former OCL, the library, the ready to run
>>> building blocks for system builders.
>
> I really haven't seen a compelling argument for changing names here.
> OCL is a Library of useful Orocos Components. Seriously, what is wrong
> with the acronym? Changing this will change a mountain of the "OCL"
> code, as well as most of your community's code. As Klaas and I have
> noted, we make major use of OCL and so we will have to go through and
> "fix" all our code for the changes you make to the name (as you'll be
> updating the namespace it is all in, won't you). What is the benefit
> of this potentially unnecessary work???

As far as I see it, it's a matter of where to put things in the source tree
(and in the documentation) and not about changing the code...

> NB in just *one* of the projects I use Orocos on, we have 600
> instances of the term "ocl" spread over 400 files. One project, one
> user. YMMV
>
>>> 2) demos: ready to run applications (maybe the hello-worlds fit
>>> here?)
>> Indeed.
>>
>>> 3) systems templates
>>>
>>> Agreed?
>>>
>> Mostly...
>>
>> The naming should be a bit more consisten; for example, either
>> "orocos components", "orocos demos", and "orocos systems templates",
>> or
>> everything without the "orocos". I think the former makes sense,
>> since all
>> these directories live in the "orocos" name space anyway.
>
> Can you please define the _substantiative difference_ between "demos"
> and "system templates", and how I would chose which to place an
> example system/program/component in?

Strange to have to explain this to a software expert :-) A demo is
something that runs "out of the box", while a template is an example of how
you _could_ do something, and it needs extra work to fill in a lot of
details or to combine it in an architecture before you have something that
indeed runs.

Herman

reworking OCL / best practice examples

On Jun 25, 2009, at 09:19 , Herman Bruyninckx wrote:

> On Thu, 25 Jun 2009, S Roderick wrote:
>
>> On Jun 25, 2009, at 06:48 , Herman Bruyninckx wrote:
>>
>>> On Thu, 25 Jun 2009, Markus Klotzbuecher wrote:
>>>
>>>> On Thu, Jun 25, 2009 at 08:46:44AM +0200, Herman Bruyninckx wrote:
>>>>> On Thu, 25 Jun 2009, Markus Klotzbuecher wrote:
>>>>>
>>>>>> On Wed, Jun 24, 2009 at 09:14:41AM +0200, Herman Bruyninckx
>>>>>> wrote:
>>>>>>> On Wed, 24 Jun 2009, Markus Klotzbuecher wrote:
>>>>>>>
>>>>>>>> On Wed, Jun 24, 2009 at 08:39:35AM +0200, Herman Bruyninckx
>>>>>>>> wrote:
>>>>>>>>> On Wed, 24 Jun 2009, Markus Klotzbuecher wrote:
>>>>>> ...
>>>>>>
>>>>>>>> 1) The library of ready to run components: the current OCL
>>>>>>>> (without
>>>>>>>> hello_world)
>>>>>>>>
>>>>>>>> 2) the examples: the hello-worlds, the application templates,
>>>>>>>> maybe
>>>>>>>> Peters exercises?
>>>>>>>>
>>>>>>>> Questions are:
>>>>>>>>
>>>>>>>> Shall 1) stay be with the name OCL or be renamed to OCR or
>>>>>>>> "component-library" ?
>>>>>>>
>>>>>>> "OCL" can go! It has not been able to create significantly
>>>>>>> positive
>>>>>>> "legacy" anyway. 1) should become the "demos" subproject.
>>>>>>
>>>>>> But it's actually not demos in there, its, huh, a library of
>>>>>> (ready-to-run) components... The acronym may be confusing but I
>>>>>> do
>>>>>> think "component-library" or "component-repository" would be more
>>>>>> appropriate!
>>>>>
>>>>> I don't think so! It _should_ become demos, that is, full-fledged
>>>>> applications for which even binaries could be provided for a small
>>>>> set of
>>>>> platforms. "library" or "repository" stuff (that is, things that
>>>>> you have
>>>>> to work on yourself still before they "do something") should be
>>>>> separted
>>>>> from the "demos", in another directory. We _need_ demos, even one
>>>>> with a
>>>>> "GUI" such as a connection with Blender. I will have a summer
>>>>> intern doing
>>>>> some work in Blender to visualise a report coming from an Orocos
>>>>> application; connection these things together and provide them as
>>>>> "demo"
>>>>> would make an impact (and is feasible for all common platform, as
>>>>> far as
>>>>> Blender is concerned). And Blender is a _very small_ download
>>>>> compared to
>>>>> what it offers :-)
>>>>
>>>> Ok, so then we have three items:
>>>>
>>>> 1) orocos-components (former OCL, the library, the ready to run
>>>> building blocks for system builders.
>>
>> I really haven't seen a compelling argument for changing names here.
>> OCL is a Library of useful Orocos Components. Seriously, what is
>> wrong
>> with the acronym? Changing this will change a mountain of the "OCL"
>> code, as well as most of your community's code. As Klaas and I have
>> noted, we make major use of OCL and so we will have to go through and
>> "fix" all our code for the changes you make to the name (as you'll be
>> updating the namespace it is all in, won't you). What is the benefit
>> of this potentially unnecessary work???
>
> As far as I see it, it's a matter of where to put things in the
> source tree
> (and in the documentation) and not about changing the code...

So the name will change, but you won't match up the namespace or
anything like that? So the code will still be OCL::TaskBrowser but the
project name, and documentation, will now be "orocos-library" (or
whatever). I must really be missing something ...

>> NB in just *one* of the projects I use Orocos on, we have 600
>> instances of the term "ocl" spread over 400 files. One project, one
>> user. YMMV
>>
>>>> 2) demos: ready to run applications (maybe the hello-worlds fit
>>>> here?)
>>> Indeed.
>>>
>>>> 3) systems templates
>>>>
>>>> Agreed?
>>>>
>>> Mostly...
>>>
>>> The naming should be a bit more consisten; for example, either
>>> "orocos components", "orocos demos", and "orocos systems templates",
>>> or
>>> everything without the "orocos". I think the former makes sense,
>>> since all
>>> these directories live in the "orocos" name space anyway.
>>
>> Can you please define the _substantiative difference_ between "demos"
>> and "system templates", and how I would chose which to place an
>> example system/program/component in?
>
> Strange to have to explain this to a software expert :-) A demo is
> something that runs "out of the box", while a template is an example
> of how
> you _could_ do something, and it needs extra work to fill in a lot of
> details or to combine it in an architecture before you have
> something that
> indeed runs.

Be careful whom you label an "expert"!!! :-)

Given the distinction above, why not just provide full working
examples (ie demos). If you are going to the trouble of providing a
system template, provide a full _working_ example that someone can
start from. What benefit does the distinction above provide to a) the
example developer, and b) the person trying to learn or start from the
example?

Stephen

reworking OCL / best practice examples

On Thu, 25 Jun 2009, S Roderick wrote:

> On Jun 25, 2009, at 09:19 , Herman Bruyninckx wrote:
[...]
>>>> The naming should be a bit more consisten; for example, either
>>>> "orocos components", "orocos demos", and "orocos systems templates",
>>>> or everything without the "orocos". I think the former makes sense,
>>>> since all these directories live in the "orocos" name space anyway.
>>>
>>> Can you please define the _substantiative difference_ between "demos"
>>> and "system templates", and how I would chose which to place an
>>> example system/program/component in?
>>
>> Strange to have to explain this to a software expert :-) A demo is
>> something that runs "out of the box", while a template is an example
>> of how you _could_ do something, and it needs extra work to fill in a
>> lot of details or to combine it in an architecture before you have
>> something that indeed runs.
>
> Be careful whom you label an "expert"!!! :-)
>
> Given the distinction above, why not just provide full working
> examples (ie demos). If you are going to the trouble of providing a
> system template, provide a full _working_ example that someone can
> start from. What benefit does the distinction above provide to a) the
> example developer, and b) the person trying to learn or start from the
> example?

Strange to have to explain this to an expert in software packaging :-)

The efforts of making (and maintaining!) a demo (that can _run_ after
downloading a binary) is exponentially larger than providing non-functional
templates that you "just" want to distribute to help people understand how
they _could_ make their own application. For example, it will be
_impossible_ to make a "force controlled robot" demo, but it will be
possible to provide the template (and to document it).

Herman

reworking OCL / best practice examples

>
> What we want is some good examples which are well documented and show
> how to solve some common problems. They should run without specific
> hardware and involve the cartesian and naxes components.
>

Well, I would not be so restrictive about it.
For example, we can contribute with a "design pattern" that we use
very often of Hardware Abstract Layer for sensors (laser, gyroscopes,
force sensors, etc).
And it is not related to motion control (directly)

> The question is, should these example reside within OCL or be a new
> higher-level subproject, e.g. BPL (best practices library?)
>

Personally, I think that we need something very common in other
framework such as Player or Orca2, which is a Abstract Device
Interface.

robotics.stanford.edu/~gerkey/research/final_papers/iros03-abstraction.pdf

Forgetting about names (OCL,BFL,HDNAYCBSO, ..) what we might need is:

1) The Abstract Device Interface definition.
2) Design Pattern (or best practice if you prefer) repository. Just
example with didactic purpose.
3) Ready to run reusable components, some of them Hardware dependent
(it MUST use section 1) as dependency and be "inspired" bu section 2)
).
4) a set of tools to make the life of the Orocos user easier. They
will be hardware and application __independent__ (Deployment,
Reporting, TaskBrowser, Viewer, etc).

Right now, the OCL includes groups 3 and 4.

What do you think?

Davide

reworking OCL / best practice examples

Hi Davide,

Thanks for your feedback.

On Mon, May 04, 2009 at 02:38:18PM +0200, Davide Faconti wrote:
> >
> > What we want is some good examples which are well documented and show
> > how to solve some common problems. They should run without specific
> > hardware and involve the cartesian and naxes components.
>
> Well, I would not be so restrictive about it.

Well, I have to start somewhere and I think that depending on certain
hardware doesn't add much value for somebody who wants to learn how to
best structure an application.

> For example, we can contribute with a "design pattern" that we use
> very often of Hardware Abstract Layer for sensors (laser, gyroscopes,
> force sensors, etc).

Ok, your welcome to contribute :-)

> And it is not related to motion control (directly)
> > The question is, should these example reside within OCL or be a new
> > higher-level subproject, e.g. BPL (best practices library?)
> >
>
> Personally, I think that we need something very common in other
> framework such as Player or Orca2, which is a Abstract Device
> Interface.

Hmm. I'm in general opposed to adding glue layers. What exactly do you
want to achieve with such a layer? Don't we have operating systems for
this purpose?

> robotics.stanford.edu/~gerkey/research/final_papers/iros03-abstraction.pdf
>
> Forgetting about names (OCL,BFL,HDNAYCBSO, ..) what we might need is:
>
> 1) The Abstract Device Interface definition.
> 2) Design Pattern (or best practice if you prefer) repository. Just
> example with didactic purpose.
> 3) Ready to run reusable components, some of them Hardware dependent
> (it MUST use section 1) as dependency and be "inspired" bu section 2)
> ).
> 4) a set of tools to make the life of the Orocos user easier. They
> will be hardware and application __independent__ (Deployment,
> Reporting, TaskBrowser, Viewer, etc).
>
> Right now, the OCL includes groups 3 and 4.
>
> What do you think?

I'm undecided about 1), I agree we want 2), 3) needs some cleanup and
I certainly agree with 4).

Markus

reworking OCL / best practice examples

About the importance of the Abstract Device Interface (ADI)

First, let me tell you that this is something already identified in
many projects of robotic frameworks. Hundreds of researchers using
Player have been using it.
What does make a component reusable?
First, you need a common communication layer between the components
(and this is what RTT does).
Bu secondary, you need to know that component A and B, which interact
HAS the same interface.
In your application, of course they have the same interface, because
YOU have been coding BOTH the components and you had to agree with...
YOURSELF! (extend it to a team of people working together).

Now think what would happen if components A and B has been written by
2 programmers that don't know each other...
Let's give a name to the components: SickLaserProducer (A) and
LocalizationComponent (B)

SickLaserProducer has been written by a team which used it for
obstacle avoidance.
Another group saw the component on the web, download it and decide to
use it. They ADAPT LocalizationComponent to the interface of
SickLaserProducer.

Few weeks later they found out that the laser Sick is to bulky for
their application and they found another component for another
hardware: HokuyoLaserProducer.
Unfortunately the two LaserProducer are not based on any standard
interface (ADI) and they are written in a different way. Of course, we
may expect that they both use DataPort to transmit the data, but the
name of the port will be different and maybe one is in integer
(millimeters) and the other one is in meters(double). They also differ
in size of the array and range.

In few words, you have to write again the RTT code of LocalizationComponent.

If the 3 components would have followed the skeleton given by the ADI,
all these components will be reusable in the robotic community, even
LocalizationComponent, that, in our example, was custom made for a
certain LaserProducer.

How such ADI for the laser scanner should look like?
Just to start it would have:

- number of measurements (points) for scan (*)
- stream of distance points
- unit of measurement of the distance (*)
- maximum range (*)
- minimum and maximum angle (*)
- a command to put the sensor in sleep (to save energy). This one
might be assent on same LaserProducer, but there is no problem: thanks
to RTT we can know that this interface is not available in RUN-TIME

(*) = it MUST NOT be hardcoded in LocalizationComponent, because it is
hardware dependent.

Reusability means: make two or more components interact without
recompiling them!!!

If OCL provides "Ready to use reusable components, some of them
Hardware dependent", such components MUST be base on a well planned
ADI, otherwise it is a huge waste of time, because no one can easily
reuse them.
The good news is: we don't need to reinvent the wheel! We should just
look what other senior projects such as Player have already done, copy
it (opensource is about it) and look what is wrong/missing to improve
it.

Right now my team is VERY busy, but I hope we can put some work on the
ADI in Autumn 2009

Davide

reworking OCL / best practice examples

> How such ADI for the laser scanner should look like?
> Just to start it would have:
>
> - number of measurements (points) for scan (*)
> - stream of distance points
> - unit of measurement of the distance (*)
And how is the unit defined ? If you want to standardize, standardize the unit
already (i.e. distance points are in ...).

> - maximum range (*)
Interesting. What would you use it for ?

--
Dr. Ing. Sylvain Joyeux
Space and Security Robotics

DFKI Bremen
Robert-Hooke-Straße 5
28359 Bremen, Germany

Phone: +49 (0)421 218-64136
E-Mail: sylvain [dot] joyeux [..] ...

Weitere Informationen: http://www.dfki.de/robotik
-----------------------------------------------------------------------
Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern
Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
(Vorsitzender) Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
USt-Id.Nr.: DE 148646973
Steuernummer: 19/673/0060/3
---------------------------------------------------------------------

reworking OCL / best practice examples

Dear Davide,

On Mon, May 04, 2009 at 07:38:36PM +0200, Davide Faconti wrote:
> About the importance of the Abstract Device Interface (ADI)
...

Thank you for your explanation. I do understand of course that such
abstract interfaces can be important. At least theoretically :-) In
practice these interfaces are very hard to get right. If they do not
provide what developers want, they will not use them. Secondly they
obscure things and add further code which doesn't (at least
immediately) add value. It is counterproductive in terms of agility,
meaning the ability to quickly understand and work on the code.

I'm not saying it's a bad idea, I'm just not sure it's a good one :-)

> Reusability means: make two or more components interact without
> recompiling them!!!

Does recompiling really matter? How often do you change your
laserscanners is your projects?

> If OCL provides "Ready to use reusable components, some of them
> Hardware dependent", such components MUST be base on a well planned
> ADI, otherwise it is a huge waste of time, because no one can easily
> reuse them.

Doesn't an ADI just move the problem somewhere else? It will still
need device specific code to access a device (a driver!) which will be
required for each new hardware?

> The good news is: we don't need to reinvent the wheel! We should just
> look what other senior projects such as Player have already done, copy
> it (opensource is about it) and look what is wrong/missing to improve
> it.

I agree with this.

> Right now my team is VERY busy, but I hope we can put some work on the
> ADI in Autumn 2009

Code always makes things clear :-)

In any case I think ADI or not is outside of the scope my OCL/Best
practice examples project.

Best regards
Markus

reworking OCL / best practice examples

On Tue, 5 May 2009, Markus Klotzb???cher wrote:

> Dear Davide,
>
> On Mon, May 04, 2009 at 07:38:36PM +0200, Davide Faconti wrote:
>> About the importance of the Abstract Device Interface (ADI)
> ...
>
> Thank you for your explanation. I do understand of course that such
> abstract interfaces can be important. At least theoretically :-) In
> practice these interfaces are very hard to get right. If they do not
> provide what developers want, they will not use them. Secondly they
> obscure things and add further code which doesn't (at least
> immediately) add value.
Abstract interfaces do not add any code! And (the good ones) do the
opposite of obscuring things: they (try to) make the semantics completely
clear. So, although I gave some critical remarks in previous messages, I am
all in favour of creating generic hardware abstractions and corresponding
APIs.

> It is counterproductive in terms of agility,
> meaning the ability to quickly understand and work on the code.

Agility is in practice often leading to the opposite of well-designed
interfaces...

> I'm not saying it's a bad idea, I'm just not sure it's a good one :-)
It's a good idea, but we need to be careful about its implementation :-)

>> Reusability means: make two or more components interact without
>> recompiling them!!!
>
> Does recompiling really matter? How often do you change your
> laserscanners is your projects?

Recompiling _does_ matter, certainly for industrial components, or for
large scale (re)deployment.

>> If OCL provides "Ready to use reusable components, some of them
>> Hardware dependent", such components MUST be base on a well planned
>> ADI, otherwise it is a huge waste of time, because no one can easily
>> reuse them.
>
> Doesn't an ADI just move the problem somewhere else? It will still
> need device specific code to access a device (a driver!) which will be
> required for each new hardware?

Yes, but that _localizes_ the effort to that particular device! At least,
if the abstract interfaces are indeed generic.

>> The good news is: we don't need to reinvent the wheel! We should just
>> look what other senior projects such as Player have already done, copy
>> it (opensource is about it) and look what is wrong/missing to improve
>> it.
>
> I agree with this.
>
>> Right now my team is VERY busy, but I hope we can put some work on the
>> ADI in Autumn 2009
>
> Code always makes things clear :-)

Ahum... :-)

> In any case I think ADI or not is outside of the scope my OCL/Best
> practice examples project.

That's true. For the time being, at least :-)

Herman

reworking OCL / best practice examples

> > Thank you for your explanation. I do understand of course that such
> > abstract interfaces can be important. At least theoretically :-)

After 5 years of robot coding I can tell you that it can save you a
lot of time and boring refactoring! Its importance is very practical
and not theoretical at all.

> > practice these interfaces are very hard to get right. If they do not
> > provide what developers want, they will not use them. Secondly they
> > obscure things and add further code which doesn't (at least
> > immediately) add value.
>
> Abstract interfaces do not add any code! And (the good ones) do the
> opposite of obscuring things: they (try to) make the semantics completely
> clear. So, although I gave some critical remarks in previous messages, I am
> all in favour of creating generic hardware abstractions and corresponding
> APIs.
>

I agree with Herman. And I would add that they are what guaranty that
2 components with the same purpose (PathPlanning for example, just to
move from the usual Laser scanner example) can be interchanged without
any extra effort from the user side, because they "look the same" from
the outside. Otherwise "give a try" to the code of someone else
usually take you weeks of integration instead of hours.

>
> > It is counterproductive in terms of agility,
> > meaning the ability to quickly understand and work on the code.
>
> Agility is in practice often leading to the opposite of well-designed
> interfaces...

One more time I agree. Agility usually means "I will do it in my way"
that is translated in "I am writing the component for myself, I don't
care if it is going to be reused from someone else or not".

>
> >> Reusability means: make two or more components interact without
> >> recompiling them!!!
> >
> > Does recompiling really matter? How often do you change your
> > laserscanners is your projects?
>

When I say that I don't want recompiling, it is not really about the
effort of write "make".
And, most important, I am NOT thinking about MY project but abort
creating a repository of reusable components in the robot community
(so, forget my humanoid robots).

"Don't recompile", or "plug-and-play" to use a not very accurate
buzzword, means that you don't need to "hack" an existing piece of
code (component).
To "hack it" means that, if you want to use the code of someone else
(one more time, it is all about reusability), you must learn how it
works, look at the part of the code that need to be modified and
modify it. Then of course it comes testing and debugging.
After this amount of time spent, your customized component will work
in your system, but it will NOT be compatible anymore with the rest of
the community, just with your own system.
Let me repeat myself. ADI is the ONLY way to make possible to exchange
components in the robotic community.

> >
> > Doesn't an ADI just move the problem somewhere else? It will still
> > need device specific code to access a device (a driver!) which will be
> > required for each new hardware?
>

Of course you need specific code. The ADI doesn't make your particular
MotorController or LaserProducer works.
It just make possible that ALL the MotorControllers and ALL the
LaserProducers talk the same "language" and are seen from the OUTSIDE
in the same way (you should not realize which camera, motor, laser or
sensor you are really using... it is the same concept of
plug-and-play).

Please remember as well that an ADI is a very short set of rules.
Comparing it to C++, imagine it as a class declaration with purely
virtual functions.
It is therefore complicated (as Herman said) to get it right, but once
you have decided, the implementation is done with few lines of code,
actually.

Anyway, I would not continue with such a debate. I think the phrase
"a little less conversation, I little more action" apply to this case.
(...further it comes my utopic plan...)
Someone needs to start doing it and showing its advantage to the community.
Community will judge what its good or bad about what you have done,
and taking this feedback into account, we do an improvement "loop"
until we don't get it right.

I don't expect you to do such ADI, Markus, but you should definitively
take a look to what has been done in other robotic framework which had
a large success worldwide (compared with Orocos) such as Player.
As Newton said: "If I have seen further it is by standing on the
shoulders of giants."

reworking OCL / best practice examples

On Tue, May 05, 2009 at 09:48:55AM +0200, Davide Faconti wrote:

> > > practice these interfaces are very hard to get right. If they do not
> > > provide what developers want, they will not use them. Secondly they
> > > obscure things and add further code which doesn't (at least
> > > immediately) add value.
> >
> > Abstract interfaces do not add any code! And (the good ones) do the
> > opposite of obscuring things: they (try to) make the semantics completely
> > clear. So, although I gave some critical remarks in previous messages, I am
> > all in favour of creating generic hardware abstractions and corresponding
> > APIs.
> >
>
> I agree with Herman. And I would add that they are what guaranty that
> 2 components with the same purpose (PathPlanning for example, just to
> move from the usual Laser scanner example) can be interchanged without
> any extra effort from the user side, because they "look the same" from
> the outside. Otherwise "give a try" to the code of someone else
> usually take you weeks of integration instead of hours.

Ok, I'm somwhat in doubt about this "no code by abstract interfaces"
hypotheses, but I'll be pleased to find out otherwise.

> > > It is counterproductive in terms of agility,
> > > meaning the ability to quickly understand and work on the code.
> >
> > Agility is in practice often leading to the opposite of well-designed
> > interfaces...

IMO these requirements are not exclusive. Reusability is nice, but
people forget that we spend most of the time maintaining software, not
writing it. Usually by people who didn't write the code, so
understandability, clearness and conciseness and indispensable
properties.

> Anyway, I would not continue with such a debate. I think the phrase
> "a little less conversation, I little more action" apply to this case.
> (...further it comes my utopic plan...)

Agreed. As I said, I _do_ see the value of such such interfaces, I'm
just not sure how it can be done without making a mess. The BRICS
project will find out :-)

Regards
Markus

reworking OCL / best practice examples

I have a suggestion about the "refactoring" of OCL, by splitting it up in
two parts with clearer goals:

1. OCR (Orocos Component Repository): a collection ('repository') or
working orocos components and/or systems, provided by any community member
that wants to share his/her efforts.

2. SAT (System Architecture Templates): a small set of extremely
well-documented and motivated _system_ design examples, that the community
has accepted as "best practice" in a _certain use case_, and after thorough
discussion.

Herman

reworking OCL / best practice examples

On Tue, May 05, 2009 at 08:55:18AM +0200, Herman Bruyninckx wrote:
> I have a suggestion about the "refactoring" of OCL, by splitting it up in
> two parts with clearer goals:
>
> 1. OCR (Orocos Component Repository): a collection ('repository') or
> working orocos components and/or systems, provided by any community member
> that wants to share his/her efforts.

Ok. And OCR "Optical Character Recognition" will be at least less
confusing than OCL "Object Constraint Language".

> 2. SAT (System Architecture Templates): a small set of extremely
> well-documented and motivated _system_ design examples, that the community
> has accepted as "best practice" in a _certain use case_, and after thorough
> discussion.

Ok, fine. I'll create a small inital example for discussion and post
it here.

Markus

reworking OCL / best practice examples

On Tue, 5 May 2009, Markus Klotzb???cher wrote:

> On Tue, May 05, 2009 at 08:55:18AM +0200, Herman Bruyninckx wrote:
>> I have a suggestion about the "refactoring" of OCL, by splitting it up in
>> two parts with clearer goals:
>>
>> 1. OCR (Orocos Component Repository): a collection ('repository') or
>> working orocos components and/or systems, provided by any community member
>> that wants to share his/her efforts.
>
> Ok. And OCR "Optical Character Recognition" will be at least less
> confusing than OCL "Object Constraint Language".
>
>> 2. SAT (System Architecture Templates): a small set of extremely
>> well-documented and motivated _system_ design examples, that the community
>> has accepted as "best practice" in a _certain use case_, and after thorough
>> discussion.
>
> Ok, fine. I'll create a small inital example for discussion and post
> it here.

Don't hurry too much: let other people comment on this suggestion first :-)

Herman

reworking OCL / best practice examples

On Tue, May 05, 2009 at 09:13:44AM +0200, Herman Bruyninckx wrote:
> On Tue, 5 May 2009, Markus Klotzb???cher wrote:
>
> > On Tue, May 05, 2009 at 08:55:18AM +0200, Herman Bruyninckx wrote:
> >> I have a suggestion about the "refactoring" of OCL, by splitting it up in
> >> two parts with clearer goals:
> >>
> >> 1. OCR (Orocos Component Repository): a collection ('repository') or
> >> working orocos components and/or systems, provided by any community member
> >> that wants to share his/her efforts.
> >
> > Ok. And OCR "Optical Character Recognition" will be at least less
> > confusing than OCL "Object Constraint Language".
> >
> >> 2. SAT (System Architecture Templates): a small set of extremely
> >> well-documented and motivated _system_ design examples, that the community
> >> has accepted as "best practice" in a _certain use case_, and after thorough
> >> discussion.
> >
> > Ok, fine. I'll create a small inital example for discussion and post
> > it here.
>
> Don't hurry too much: let other people comment on this suggestion first :-)

Ok... anyone any suggestions here? I plan to get started here really
soon now... :-)

Markus

reworking OCL / best practice examples

2009/6/19 Markus Klotzbuecher <markus [dot] klotzbuecher [..] ...>

> On Tue, May 05, 2009 at 09:13:44AM +0200, Herman Bruyninckx wrote:
> > On Tue, 5 May 2009, Markus Klotzb???cher wrote:
> >
> > > On Tue, May 05, 2009 at 08:55:18AM +0200, Herman Bruyninckx wrote:
> > >> I have a suggestion about the "refactoring" of OCL, by splitting it up
> in
> > >> two parts with clearer goals:
> > >>
> > >> 1. OCR (Orocos Component Repository): a collection ('repository') or
> > >> working orocos components and/or systems, provided by any community
> member
> > >> that wants to share his/her efforts.
> > >
> > > Ok. And OCR "Optical Character Recognition" will be at least less
> > > confusing than OCL "Object Constraint Language".
> > >
> > >> 2. SAT (System Architecture Templates): a small set of extremely
> > >> well-documented and motivated _system_ design examples, that the
> community
> > >> has accepted as "best practice" in a _certain use case_, and after
> thorough
> > >> discussion.
> > >
> > > Ok, fine. I'll create a small inital example for discussion and post
> > > it here.
> >
> > Don't hurry too much: let other people comment on this suggestion first
> :-)
>
> Ok... anyone any suggestions here? I plan to get started here really
> soon now... :-)
> <http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev>
>
I would also define a Small Application Examples category. This would
contain small applications which can be used as a starting point for more
advanced applications. (for instance a BFL filter component, ... (using the
BFL toolkit, ...) )
Personnaly I like to use this slick components as a starting point for more
advanced system applications.

I think that each SAT and SAE should get a primary responsable: this person
is then responsible to get the component to work with the latest release AND
to keep the documentation up to date.

Tinne

reworking OCL / best practice examples

Hi Tinne,

On Fri, Jun 19, 2009 at 03:59:01PM +0200, Tinne De Laet wrote:
> 2009/6/19 Markus Klotzbuecher <markus [dot] klotzbuecher [..] ...>
> On Tue, May 05, 2009 at 09:13:44AM +0200, Herman Bruyninckx wrote:
> > On Tue, 5 May 2009, Markus Klotzb???cher wrote:
> >
> > > On Tue, May 05, 2009 at 08:55:18AM +0200, Herman Bruyninckx wrote:
> > >> I have a suggestion about the "refactoring" of OCL, by splitting it up
> in
> > >> two parts with clearer goals:
> > >>
> > >> 1. OCR (Orocos Component Repository): a collection ('repository') or
> > >> working orocos components and/or systems, provided by any community
> member
> > >> that wants to share his/her efforts.
> > >
> > > Ok. And OCR "Optical Character Recognition" will be at least less
> > > confusing than OCL "Object Constraint Language".
> > >
> > >> 2. SAT (System Architecture Templates): a small set of extremely
> > >> well-documented and motivated _system_ design examples, that the
> community
> > >> has accepted as "best practice" in a _certain use case_, and after
> thorough
> > >> discussion.
> > >
> > > Ok, fine. I'll create a small inital example for discussion and post
> > > it here.
> >
> > Don't hurry too much: let other people comment on this suggestion first
> :-)
>
> Ok... anyone any suggestions here? I plan to get started here really
> soon now... :-)
>
> I would also define a Small Application Examples category. This would contain
> small applications which can be used as a starting point for more advanced
> applications. (for instance a BFL filter component, ... (using the BFL toolkit,
> ...) )
> Personnaly I like to use this slick components as a starting point for more
> advanced system applications.
>
> I think that each SAT and SAE should get a primary responsable: this person is
> then responsible to get the component to work with the latest release AND to
> keep the documentation up to date.

Good idea, I think these "hello-worlds" (for different domains) are
important indeed. I wonder how to partition these items? SAT and SAE
could probably well live together in one SC repository, while OCR
should be kept seperate? Shall we really create all these new acronyms
or will they be confusing?

Markus

reworking OCL / best practice examples

On Mon, Jun 22, 2009 at 8:46 AM, Markus Klotzbuecher <
markus [dot] klotzbuecher [..] ...> wrote:

> Hi Tinne,
>
> On Fri, Jun 19, 2009 at 03:59:01PM +0200, Tinne De Laet wrote:
> > 2009/6/19 Markus Klotzbuecher <markus [dot] klotzbuecher [..] ...>
> > On Tue, May 05, 2009 at 09:13:44AM +0200, Herman Bruyninckx wrote:
> > > On Tue, 5 May 2009, Markus Klotzb???cher wrote:
> > >
> > > > On Tue, May 05, 2009 at 08:55:18AM +0200, Herman Bruyninckx
> wrote:
> > > >> I have a suggestion about the "refactoring" of OCL, by splitting
> it up
> > in
> > > >> two parts with clearer goals:
> > > >>
> > > >> 1. OCR (Orocos Component Repository): a collection
> ('repository') or
> > > >> working orocos components and/or systems, provided by any
> community
> > member
> > > >> that wants to share his/her efforts.
> > > >
> > > > Ok. And OCR "Optical Character Recognition" will be at least less
> > > > confusing than OCL "Object Constraint Language".
> > > >
> > > >> 2. SAT (System Architecture Templates): a small set of extremely
> > > >> well-documented and motivated _system_ design examples, that the
> > community
> > > >> has accepted as "best practice" in a _certain use case_, and
> after
> > thorough
> > > >> discussion.
> > > >
> > > > Ok, fine. I'll create a small inital example for discussion and
> post
> > > > it here.
> > >
> > > Don't hurry too much: let other people comment on this suggestion
> first
> > :-)
> >
> > Ok... anyone any suggestions here? I plan to get started here really
> > soon now... :-)
> >
> > I would also define a Small Application Examples category. This would
> contain
> > small applications which can be used as a starting point for more
> advanced
> > applications. (for instance a BFL filter component, ... (using the BFL
> toolkit,
> > ...) )
> > Personnaly I like to use this slick components as a starting point for
> more
> > advanced system applications.
> >
> > I think that each SAT and SAE should get a primary responsable: this
> person is
> > then responsible to get the component to work with the latest release AND
> to
> > keep the documentation up to date.
>
> Good idea, I think these "hello-worlds" (for different domains) are
> important indeed. I wonder how to partition these items? SAT and SAE
> could probably well live together in one SC repository, while OCR
> should be kept seperate? Shall we really create all these new acronyms
> or will they be confusing?

I for one find them a bit confusing. They all have a previous (unrelated)
meaning to me,
- SAT: Scholastic Aptitude Test
- SAE: Society of Automotive Engineers
- OCR: Optical Character Recognition (as mentioned before)

I think it won't be easy to find three-letter acronyms with vowels that
don't make us think first of something else. Are acronyms really necessary?
Do we want them short because of the folder name associated to them? If so,
we could use the complete name "Orocos Component Repository" to describe the
'entity', and maybe something like "Components" for the folder name.
Anyone?

Adolfo.

> Markus
> --
> Orocos-Dev mailing list
> Orocos-Dev [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
>

reworking OCL / best practice examples

2009/6/22 Adolfo Rodríguez Tsouroukdissian <adolfo [dot] rodriguez [..] ...>:
> I for one find them a bit confusing. They all have a previous (unrelated)
> meaning to me,
> - SAT: Scholastic Aptitude Test
> - SAE: Society of Automotive Engineers
> - OCR: Optical Character Recognition (as mentioned before)
>
> I think it won't be easy to find three-letter acronyms with vowels that
> don't make us think first of something else. Are acronyms really necessary?
> Do we want them short because of the folder name associated to them? If so,
> we could use the complete name "Orocos Component Repository" to describe the
> 'entity', and maybe something like "Components" for the folder name.
> Anyone?

I'm also leaning towards 'orocos-components' 'orocos-applications' (or
similar) as directory names and full names on the website. RTT, KDL,
BFL, leave them that way, but the higher level constructs can have
'higher level names'.

Peter

reworking OCL / best practice examples

On Mon, Jun 22, 2009 at 11:52:02AM +0200, Peter Soetens wrote:
> 2009/6/22 Adolfo Rodríguez Tsouroukdissian <adolfo [dot] rodriguez [..] ...>:
> > I for one find them a bit confusing. They all have a previous (unrelated)
> > meaning to me,
> > - SAT: Scholastic Aptitude Test
> > - SAE: Society of Automotive Engineers
> > - OCR: Optical Character Recognition (as mentioned before)
> >
> > I think it won't be easy to find three-letter acronyms with vowels that
> > don't make us think first of something else. Are acronyms really necessary?
> > Do we want them short because of the folder name associated to them? If so,
> > we could use the complete name "Orocos Component Repository" to describe the
> > 'entity', and maybe something like "Components" for the folder name.
> > Anyone?
>
> I'm also leaning towards 'orocos-components' 'orocos-applications' (or

How about "orocos-examples" instead of "orocos-applications"? For
instance that would fit well with the debian *-examples packages.

> similar) as directory names and full names on the website. RTT, KDL,
> BFL, leave them that way, but the higher level constructs can have
> 'higher level names'.

And OCL? The disadvantage of renaming it is that this acronym is
already known and changing it would require quite some renaming in the
sources. What do you think?

Markus

reworking OCL / best practice examples

On Wed, 24 Jun 2009, Markus Klotzbuecher wrote:

> On Mon, Jun 22, 2009 at 11:52:02AM +0200, Peter Soetens wrote:
>> 2009/6/22 Adolfo Rodríguez Tsouroukdissian <adolfo [dot] rodriguez [..] ...>:
>>> I for one find them a bit confusing. They all have a previous (unrelated)
>>> meaning to me,
>>> - SAT: Scholastic Aptitude Test
>>> - SAE: Society of Automotive Engineers
>>> - OCR: Optical Character Recognition (as mentioned before)
>>>
>>> I think it won't be easy to find three-letter acronyms with vowels that
>>> don't make us think first of something else. Are acronyms really necessary?
>>> Do we want them short because of the folder name associated to them? If so,
>>> we could use the complete name "Orocos Component Repository" to describe the
>>> 'entity', and maybe something like "Components" for the folder name.
>>> Anyone?
>>
>> I'm also leaning towards 'orocos-components' 'orocos-applications' (or
>
> How about "orocos-examples" instead of "orocos-applications"? For
> instance that would fit well with the debian *-examples packages.
>
>> similar) as directory names and full names on the website. RTT, KDL,
>> BFL, leave them that way, but the higher level constructs can have
>> 'higher level names'.
>
> And OCL? The disadvantage of renaming it is that this acronym is
> already known and changing it would require quite some renaming in the
> sources. What do you think?
>
When "renaming" a three-letter acronym into a fully fledged "name", I see
no problem. My preference goes to Orocos-application-templates...

Herman

reworking OCL / best practice examples

On Wed, Jun 24, 2009 at 08:39:35AM +0200, Herman Bruyninckx wrote:
> On Wed, 24 Jun 2009, Markus Klotzbuecher wrote:
>
>> On Mon, Jun 22, 2009 at 11:52:02AM +0200, Peter Soetens wrote:
>>> 2009/6/22 Adolfo Rodríguez Tsouroukdissian <adolfo [dot] rodriguez [..] ...>:
>>>> I for one find them a bit confusing. They all have a previous (unrelated)
>>>> meaning to me,
>>>> - SAT: Scholastic Aptitude Test
>>>> - SAE: Society of Automotive Engineers
>>>> - OCR: Optical Character Recognition (as mentioned before)
>>>>
>>>> I think it won't be easy to find three-letter acronyms with vowels that
>>>> don't make us think first of something else. Are acronyms really necessary?
>>>> Do we want them short because of the folder name associated to them? If so,
>>>> we could use the complete name "Orocos Component Repository" to describe the
>>>> 'entity', and maybe something like "Components" for the folder name.
>>>> Anyone?
>>>
>>> I'm also leaning towards 'orocos-components' 'orocos-applications' (or
>>
>> How about "orocos-examples" instead of "orocos-applications"? For
>> instance that would fit well with the debian *-examples packages.
>>
>>> similar) as directory names and full names on the website. RTT, KDL,
>>> BFL, leave them that way, but the higher level constructs can have
>>> 'higher level names'.
>>
>> And OCL? The disadvantage of renaming it is that this acronym is
>> already known and changing it would require quite some renaming in the
>> sources. What do you think?
>>
> When "renaming" a three-letter acronym into a fully fledged "name", I see
> no problem. My preference goes to Orocos-application-templates...

Hang on... what today is OCL will be split into two entities:

1) The library of ready to run components: the current OCL (without
hello_world)

2) the examples: the hello-worlds, the application templates, maybe
Peters exercises?

Questions are:

Shall 1) stay be with the name OCL or be renamed to OCR or
"component-library" ?

How shall 2) be called?

Markus

reworking OCL / best practice examples

On Wed, 24 Jun 2009, Markus Klotzbuecher wrote:

> On Wed, Jun 24, 2009 at 08:39:35AM +0200, Herman Bruyninckx wrote:
>> On Wed, 24 Jun 2009, Markus Klotzbuecher wrote:
>>
>>> On Mon, Jun 22, 2009 at 11:52:02AM +0200, Peter Soetens wrote:
>>>> 2009/6/22 Adolfo Rodríguez Tsouroukdissian <adolfo [dot] rodriguez [..] ...>:
>>>>> I for one find them a bit confusing. They all have a previous (unrelated)
>>>>> meaning to me,
>>>>> - SAT: Scholastic Aptitude Test
>>>>> - SAE: Society of Automotive Engineers
>>>>> - OCR: Optical Character Recognition (as mentioned before)
>>>>>
>>>>> I think it won't be easy to find three-letter acronyms with vowels that
>>>>> don't make us think first of something else. Are acronyms really necessary?
>>>>> Do we want them short because of the folder name associated to them? If so,
>>>>> we could use the complete name "Orocos Component Repository" to describe the
>>>>> 'entity', and maybe something like "Components" for the folder name.
>>>>> Anyone?
>>>>
>>>> I'm also leaning towards 'orocos-components' 'orocos-applications' (or
>>>
>>> How about "orocos-examples" instead of "orocos-applications"? For
>>> instance that would fit well with the debian *-examples packages.
>>>
>>>> similar) as directory names and full names on the website. RTT, KDL,
>>>> BFL, leave them that way, but the higher level constructs can have
>>>> 'higher level names'.
>>>
>>> And OCL? The disadvantage of renaming it is that this acronym is
>>> already known and changing it would require quite some renaming in the
>>> sources. What do you think?
>>>
>> When "renaming" a three-letter acronym into a fully fledged "name", I see
>> no problem. My preference goes to Orocos-application-templates...
>
> Hang on... what today is OCL will be split into two entities:
>
> 1) The library of ready to run components: the current OCL (without
> hello_world)
>
> 2) the examples: the hello-worlds, the application templates, maybe
> Peters exercises?
>
> Questions are:
>
> Shall 1) stay be with the name OCL or be renamed to OCR or
> "component-library" ?

"OCL" can go! It has not been able to create significantly positive
"legacy" anyway. 1) should become the "demos" subproject.

> How shall 2) be called?

"application (architecture) templates" or something similar.

Herman

reworking OCL / best practice examples

On Wed, Jun 24, 2009 at 09:14:41AM +0200, Herman Bruyninckx wrote:
> On Wed, 24 Jun 2009, Markus Klotzbuecher wrote:
>
>> On Wed, Jun 24, 2009 at 08:39:35AM +0200, Herman Bruyninckx wrote:
>>> On Wed, 24 Jun 2009, Markus Klotzbuecher wrote:
...

>> 1) The library of ready to run components: the current OCL (without
>> hello_world)
>>
>> 2) the examples: the hello-worlds, the application templates, maybe
>> Peters exercises?
>>
>> Questions are:
>>
>> Shall 1) stay be with the name OCL or be renamed to OCR or
>> "component-library" ?
>
> "OCL" can go! It has not been able to create significantly positive
> "legacy" anyway. 1) should become the "demos" subproject.

But it's actually not demos in there, its, huh, a library of
(ready-to-run) components... The acronym may be confusing but I do
think "component-library" or "component-repository" would be more
appropriate!

>> How shall 2) be called?
>
> "application (architecture) templates" or something similar.

That would be fine for me!

Markus

reworking OCL / best practice examples

On Wed, Jun 24, 2009 at 9:14 AM, Herman
Bruyninckx<Herman [dot] Bruyninckx [..] ...> wrote:
[...]
>> Shall 1) stay be with the name OCL or be renamed to OCR or
>> "component-library" ?
>
> "OCL" can go! It has not been able to create significantly positive
> "legacy" anyway. 1) should become the "demos" subproject.

Ahum? Personally I think the OCL "legacy" is one of the main (if not
_the_) advantages of using orocos, i.e. it offers ready-to-use
functionality that is very useful for most applications. It is what
makes us win time. 90% (admitted, I just made up this number :-) of
our applications uses reporting, deployer, timercomponent and one of
the device driver components.

Klaas

reworking OCL / best practice examples

On Jun 24, 2009, at 13:30 , Klaas Gadeyne wrote:

> On Wed, Jun 24, 2009 at 9:14 AM, Herman
> Bruyninckx<Herman [dot] Bruyninckx [..] ...> wrote:
> [...]
>>> Shall 1) stay be with the name OCL or be renamed to OCR or
>>> "component-library" ?
>>
>> "OCL" can go! It has not been able to create significantly positive
>> "legacy" anyway. 1) should become the "demos" subproject.
>
> Ahum? Personally I think the OCL "legacy" is one of the main (if not
> _the_) advantages of using orocos, i.e. it offers ready-to-use
> functionality that is very useful for most applications. It is what
> makes us win time. 90% (admitted, I just made up this number :-) of
> our applications uses reporting, deployer, timercomponent and one of
> the device driver components.

100% of our projects use the deployer and reporting. Maybe 20% use a
comedi component also.

Till now, OCL has also been the *only* way to derive any kind of
system-level examples and information ...
Stephen

reworking OCL / best practice examples

On Wed, 24 Jun 2009, S Roderick wrote:

> On Jun 24, 2009, at 13:30 , Klaas Gadeyne wrote:
>
>> On Wed, Jun 24, 2009 at 9:14 AM, Herman
>> Bruyninckx<Herman [dot] Bruyninckx [..] ...> wrote:
>> [...]
>>>> Shall 1) stay be with the name OCL or be renamed to OCR or
>>>> "component-library" ?
>>>
>>> "OCL" can go! It has not been able to create significantly positive
>>> "legacy" anyway. 1) should become the "demos" subproject.
>>
>> Ahum? Personally I think the OCL "legacy" is one of the main (if not
>> _the_) advantages of using orocos, i.e. it offers ready-to-use
>> functionality that is very useful for most applications. It is what
>> makes us win time.
Confusion caused by me: I was talking about the string "OCL", that is, the
name. I fully agree with your comments about the usefulness of the
_contents_ :-) (Although it should be refactored.)

> 90% (admitted, I just made up this number :-) of
>> our applications uses reporting, deployer, timercomponent and one of
>> the device driver components.
>
> 100% of our projects use the deployer and reporting. Maybe 20% use a
> comedi component also.
>
> Till now, OCL has also been the *only* way to derive any kind of
> system-level examples and information ...

And that's exactly what we want to improve with the suggested refactoring.

> Stephen

Herman

reworking OCL / best practice examples

On Jun 24, 2009, at 03:14 , Herman Bruyninckx wrote:

> On Wed, 24 Jun 2009, Markus Klotzbuecher wrote:
>
>> On Wed, Jun 24, 2009 at 08:39:35AM +0200, Herman Bruyninckx wrote:
>>> On Wed, 24 Jun 2009, Markus Klotzbuecher wrote:
>>>
>>>> On Mon, Jun 22, 2009 at 11:52:02AM +0200, Peter Soetens wrote:
>>>>> 2009/6/22 Adolfo Rodríguez Tsouroukdissian <adolfo [dot] rodriguez [..] ...
>>>>> >:
>>>>>> I for one find them a bit confusing. They all have a previous
>>>>>> (unrelated)
>>>>>> meaning to me,
>>>>>> - SAT: Scholastic Aptitude Test
>>>>>> - SAE: Society of Automotive Engineers
>>>>>> - OCR: Optical Character Recognition (as mentioned before)
>>>>>>
>>>>>> I think it won't be easy to find three-letter acronyms with
>>>>>> vowels that
>>>>>> don't make us think first of something else. Are acronyms
>>>>>> really necessary?
>>>>>> Do we want them short because of the folder name associated to
>>>>>> them? If so,
>>>>>> we could use the complete name "Orocos Component Repository" to
>>>>>> describe the
>>>>>> 'entity', and maybe something like "Components" for the folder
>>>>>> name.
>>>>>> Anyone?
>>>>>
>>>>> I'm also leaning towards 'orocos-components' 'orocos-
>>>>> applications' (or
>>>>
>>>> How about "orocos-examples" instead of "orocos-applications"? For
>>>> instance that would fit well with the debian *-examples packages.
>>>>
>>>>> similar) as directory names and full names on the website. RTT,
>>>>> KDL,
>>>>> BFL, leave them that way, but the higher level constructs can have
>>>>> 'higher level names'.
>>>>
>>>> And OCL? The disadvantage of renaming it is that this acronym is
>>>> already known and changing it would require quite some renaming
>>>> in the
>>>> sources. What do you think?
>>>>
>>> When "renaming" a three-letter acronym into a fully fledged
>>> "name", I see
>>> no problem. My preference goes to Orocos-application-templates...
>>
>> Hang on... what today is OCL will be split into two entities:
>>
>> 1) The library of ready to run components: the current OCL (without
>> hello_world)
>>
>> 2) the examples: the hello-worlds, the application templates, maybe
>> Peters exercises?
>>
>> Questions are:
>>
>> Shall 1) stay be with the name OCL or be renamed to OCR or
>> "component-library" ?
>
> "OCL" can go! It has not been able to create significantly positive
> "legacy" anyway. 1) should become the "demos" subproject.

I disagree. OCL is useful, very much so when it comes to the deployer,
reporting, and motion control (at the very least). Taking out
helloworld makes sense. Ditching the rest makes *no* sense to me.

>> How shall 2) be called?
>
> "application (architecture) templates" or something similar.

I'm ambiguous about this. As long as a new user can make immediate
sense of the name.
Stephen

reworking OCL / best practice examples

On Jun 22, 2009, at 05:52 , Peter Soetens wrote:

> 2009/6/22 Adolfo Rodríguez Tsouroukdissian <adolfo [dot] rodriguez [..] ...
> >:
>> I for one find them a bit confusing. They all have a previous
>> (unrelated)
>> meaning to me,
>> - SAT: Scholastic Aptitude Test
>> - SAE: Society of Automotive Engineers
>> - OCR: Optical Character Recognition (as mentioned before)
>>
>> I think it won't be easy to find three-letter acronyms with vowels
>> that
>> don't make us think first of something else. Are acronyms really
>> necessary?
>> Do we want them short because of the folder name associated to
>> them? If so,
>> we could use the complete name "Orocos Component Repository" to
>> describe the
>> 'entity', and maybe something like "Components" for the folder name.
>> Anyone?
>
> I'm also leaning towards 'orocos-components' 'orocos-applications' (or
> similar) as directory names and full names on the website. RTT, KDL,
> BFL, leave them that way, but the higher level constructs can have
> 'higher level names'.

+1 for not using acronyms
S

reworking OCL / best practice examples

On Mon, 4 May 2009, Davide Faconti wrote:

> About the importance of the Abstract Device Interface (ADI)
>
> First, let me tell you that this is something already identified in
> many projects of robotic frameworks. Hundreds of researchers using
> Player have been using it.
> What does make a component reusable?
> First, you need a common communication layer between the components
> (and this is what RTT does).
> Bu secondary, you need to know that component A and B, which interact
> HAS the same interface.
> In your application, of course they have the same interface, because
> YOU have been coding BOTH the components and you had to agree with...
> YOURSELF! (extend it to a team of people working together).
>
> Now think what would happen if components A and B has been written by
> 2 programmers that don't know each other...
> Let's give a name to the components: SickLaserProducer (A) and
> LocalizationComponent (B)
>
> SickLaserProducer has been written by a team which used it for
> obstacle avoidance.
> Another group saw the component on the web, download it and decide to
> use it. They ADAPT LocalizationComponent to the interface of
> SickLaserProducer.
>
> Few weeks later they found out that the laser Sick is to bulky for
> their application and they found another component for another
> hardware: HokuyoLaserProducer.
> Unfortunately the two LaserProducer are not based on any standard
> interface (ADI) and they are written in a different way. Of course, we
> may expect that they both use DataPort to transmit the data, but the
> name of the port will be different and maybe one is in integer
> (millimeters) and the other one is in meters(double). They also differ
> in size of the array and range.
>
> In few words, you have to write again the RTT code of LocalizationComponent.
>
> If the 3 components would have followed the skeleton given by the ADI,
> all these components will be reusable in the robotic community, even
> LocalizationComponent, that, in our example, was custom made for a
> certain LaserProducer.
>
> How such ADI for the laser scanner should look like?
> Just to start it would have:
>
> - number of measurements (points) for scan (*)
> - stream of distance points
> - unit of measurement of the distance (*)
> - maximum range (*)
> - minimum and maximum angle (*)
> - a command to put the sensor in sleep (to save energy). This one
> might be assent on same LaserProducer, but there is no problem: thanks
> to RTT we can know that this interface is not available in RUN-TIME
>
> (*) = it MUST NOT be hardcoded in LocalizationComponent, because it is
> hardware dependent.
>
> Reusability means: make two or more components interact without
> recompiling them!!!
>
> If OCL provides "Ready to use reusable components, some of them
> Hardware dependent", such components MUST be base on a well planned
> ADI, otherwise it is a huge waste of time, because no one can easily
> reuse them.
> The good news is: we don't need to reinvent the wheel! We should just
> look what other senior projects such as Player have already done, copy
> it (opensource is about it) and look what is wrong/missing to improve
> it.

I started such an initiative four years ago or so, with people involved
from the major open source projects of that time. There was initial
enthusiasm, but that died out a bit too fast. The major reason was that we
couldn't even agree on the simples standardization, such as position! For
example, the projects with mobile robots as major use case were not
motivated to use a full 6D position representation (a 'frame'), while other
projects such as Orocos could not live with only planar worlds...

I still believe that such standardization is necessary, and we are going to
make concrete suggestions via the BRICS project. But the problem is far
more complex than you can imagine, mostly due to incompatibilities at the
level of human characters :-)

> Right now my team is VERY busy, but I hope we can put some work on the
> ADI in Autumn 2009
Great! By that time BRICS will have produced its draft document.

Also don't forget that Orocos uses already the Comedi API to access
"bare" physical devices; there is no _dependency_ on that API though.

> Davide

Herman

reworking OCL / best practice examples

>> The good news is: we don't need to reinvent the wheel! We should just
>> look what other senior projects such as Player have already done, copy
>> it (opensource is about it) and look what is wrong/missing to improve
>> it.
>
> I started such an initiative four years ago or so, with people involved
> from the major open source projects of that time. There was initial
> enthusiasm, but that died out a bit too fast. The major reason was that we
> couldn't even agree on the simples standardization, such as position! For
> example, the projects with mobile robots as major use case were not
> motivated to use a full 6D position representation (a 'frame'), while other
> projects such as Orocos could not live with only planar worlds...
>

I believe is going to be tough, but I hope that, if someone start the
initiative is going to be a BIT more easy.
We should try to find out something ACCEPTABLE and really USEFUL for a
large odience instead of trying defining something perfect.
An by trial and error, and gatering the feedback of expertizes, we
will get close to our goal.
What I said, of course, is a "would like to".

> I still believe that such standardization is necessary, and we are going to
> make concrete suggestions via the BRICS project. But the problem is far
> more complex than you can imagine, mostly due to incompatibilities at the
> level of human characters :-)
>

I can believe that! Any lesson learned about a strategy to keep low
developers ego ?

>> Right now my team is VERY busy, but I hope we can put some work on the
>> ADI in Autumn 2009
> Great! By that time BRICS will have produced its draft document.
>
> Also don't forget that Orocos uses already the Comedi API to access
> "bare" physical devices; there is no _dependency_ on that API though.
>

Comedi look a very good example, indeed.

reworking OCL / best practice examples

> Personally, I think that we need something very common in other
> framework such as Player or Orca2, which is a Abstract Device
> Interface.
>
> robotics.stanford.edu/~gerkey/research/final_papers/iros03-abstraction.pdf
>
Well ... I never was able to *really* know wether or not these HALs where a
good or a bad thing. When I see the player HAL, I'm feeling like "OK, that's
generic but actually there's a lot of VERY useful information that never gets
through". I do feel the need for HALs (hey, that allows for easy replacement
of devices and software, which is definitely very nice to have). But ...

Let's for instance take the laser scanner. Some scanners give quality
information: hokuyos for instance give error codes for each ranges. Some other
methods use the intensity readings to add reliability values to the ranges.

Another example would be GPS interfaces, as the availability of accuracy
information really depends on the device you have.

And why those values are removed from the HALs ? Because they are not generic
enough. I.e. I always have the feeling that HALs are the interface of the less
powerful devices and less powerful approaches out there. If you want anything
more advanced, you have to use something different.

What do you people think ?

reworking OCL / best practice examples

On Mon, May 4, 2009 at 3:06 PM, Sylvain Joyeux <sylvain [dot] joyeux [..] ...>wrote:

> > Personally, I think that we need something very common in other
> > framework such as Player or Orca2, which is a Abstract Device
> > Interface.
> >
> >
> robotics.stanford.edu/~gerkey/research/final_papers/iros03-abstraction.pdf<http://robotics.stanford.edu/%7Egerkey/research/final_papers/iros03-abstraction.pdf>
> >
> Well ... I never was able to *really* know wether or not these HALs where a
> good or a bad thing. When I see the player HAL, I'm feeling like "OK,
> that's
> generic but actually there's a lot of VERY useful information that never
> gets
> through". I do feel the need for HALs (hey, that allows for easy
> replacement
> of devices and software, which is definitely very nice to have). But ...
>
> Let's for instance take the laser scanner. Some scanners give quality
> information: hokuyos for instance give error codes for each ranges. Some
> other
> methods use the intensity readings to add reliability values to the ranges.
>
> Another example would be GPS interfaces, as the availability of accuracy
> information really depends on the device you have.
>
> And why those values are removed from the HALs ? Because they are not
> generic
> enough. I.e. I always have the feeling that HALs are the interface of the
> less
> powerful devices and less powerful approaches out there. If you want
> anything
> more advanced, you have to use something different.
>
> What do you people think ?

This is exactly my experience with HALs as well. I tried it with rtt/dev and
came to
exactly the same conclusion. Its nice for simple demo programs (or Comedi),
but when you
want to use your sensor fully, talk to the device's C API directly (and let
the OS abstract
as much as possible for you)

Peter

reworking OCL / best practice examples

On Mon, May 4, 2009 at 3:06 PM, Sylvain Joyeux <sylvain [dot] joyeux [..] ...>wrote:

> > Personally, I think that we need something very common in other
> > framework such as Player or Orca2, which is a Abstract Device
> > Interface.
> >
> >
> robotics.stanford.edu/~gerkey/research/final_papers/iros03-abstraction.pdf<http://robotics.stanford.edu/%7Egerkey/research/final_papers/iros03-abstraction.pdf>
> >
> Well ... I never was able to *really* know wether or not these HALs where a
> good or a bad thing. When I see the player HAL, I'm feeling like "OK,
> that's
> generic but actually there's a lot of VERY useful information that never
> gets
> through". I do feel the need for HALs (hey, that allows for easy
> replacement
> of devices and software, which is definitely very nice to have). But ...
>
> Let's for instance take the laser scanner. Some scanners give quality
> information: hokuyos for instance give error codes for each ranges. Some
> other
> methods use the intensity readings to add reliability values to the ranges.
>
> Another example would be GPS interfaces, as the availability of accuracy
> information really depends on the device you have.
>
> And why those values are removed from the HALs ? Because they are not
> generic
> enough. I.e. I always have the feeling that HALs are the interface of the
> less
> powerful devices and less powerful approaches out there. If you want
> anything
> more advanced, you have to use something different.
>
> What do you people think ?

This is exactly my experience with HALs as well. I tried it with rtt/dev and
came to
exactly the same conclusion. Its nice for simple demo programs (or Comedi),
but when you
want to use your sensor fully, talk to the device's C API directly (and let
the OS abstract
as much as possible for you)

Peter

reworking OCL / best practice examples

On Thu, 7 May 2009, Peter Soetens wrote:

> On Mon, May 4, 2009 at 3:06 PM, Sylvain Joyeux <sylvain [dot] joyeux [..] ...<mailto:sylvain [dot] joyeux [..] ...>> wrote:
>> Personally, I think that we need something very common in other
>> framework such as Player or Orca2, which is a Abstract Device
>> Interface.
>>
>> robotics.stanford.edu/~gerkey/research/final_papers/iros03-abstraction.pdf<http://robotics.stanford.edu/%7Egerkey/research/final_papers/iros03-abstraction.pdf>
>>
> Well ... I never was able to *really* know wether or not these HALs where a
> good or a bad thing. When I see the player HAL, I'm feeling like "OK, that's
> generic but actually there's a lot of VERY useful information that never gets
> through". I do feel the need for HALs (hey, that allows for easy replacement
> of devices and software, which is definitely very nice to have). But ...
>
> Let's for instance take the laser scanner. Some scanners give quality
> information: hokuyos for instance give error codes for each ranges. Some other
> methods use the intensity readings to add reliability values to the ranges.
>
> Another example would be GPS interfaces, as the availability of accuracy
> information really depends on the device you have.
>
> And why those values are removed from the HALs ? Because they are not generic
> enough. I.e. I always have the feeling that HALs are the interface of the less
> powerful devices and less powerful approaches out there. If you want anything
> more advanced, you have to use something different.
>
> What do you people think ?

In KDL we solved this problem (I think): we worked hard to find the "real"
generic parts in one "HAL" (in KDL, the "HAL" is the generic way to define
the operations on kinematic chains, such as forward and inverse dynamics,
etc.), and made this into an abstract interface; then we _aggregate_ a
"solver interface" (for each possible _algorithm_ that fills in a particular
kinematic operation), a "kinematic chain" interface (for each possible
family of robots that have the same kinematics, up to constant geometric
parameterrs), a "joint vector" interface (for representing the joint values
of a chain) and finally a "Cartesian frames" interface (a robot can have
multiple of them).
The advantage is that the _semantics_ of the interface(s) are standardized,
as well as the calling signature; the concrete implementation (including
the language binding) are not, but require only one-off efforts.

> This is exactly my experience with HALs as well. I tried it with rtt/dev
> and came to exactly the same conclusion. Its nice for simple demo
> programs (or Comedi), but when you want to use your sensor fully, talk to
> the device's C API directly (and let the OS abstract as much as possible
> for you)

I don't agree. This is an inherently unscalable situation in a real
component-based (let alone _service oriented_) system!

Orocos _has_ to get out of this "I-am-the-only-guy-working-on-this-hardware"
mentality and _solve_ this problem!

Herman

reworking OCL / best practice examples

>Orocos _has_ to get out of this "I-am-the-only-guy-working-on-this-hardware"
> mentality and _solve_ this problem!

I fully agree with Herman.

>> Let's for instance take the laser scanner. Some scanners give quality
>> information: hokuyos for instance give error codes for each ranges. Some other
>> methods use the intensity readings to add reliability values to the ranges.
>>
>> Another example would be GPS interfaces, as the availability of accuracy
>> information really depends on the device you have.
>>
>
>> This is exactly my experience with HALs as well. I tried it with rtt/dev
>> and came to exactly the same conclusion. Its nice for simple demo
>> programs (or Comedi), but when you want to use your sensor fully, talk to
>> the device's C API directly (and let the OS abstract as much as possible
>> for you)
>

I think you are a bit too pessimistic about the HAL, and in front of
your eyes, in the very same moment that you are reading this e-mail,
you have an example.

Your screen, mouse and keyboard are running through the equivalent of
a standard interface, some of them will work with generic drivers,
others will require that you install the driver of the vendor. But one
they are installed, all the programs who need them for input/output,
will not have to write any vendor specific code.
This is what OS do...

Let me do another example that is closer to robotic community, an
example of successfully standard interface: a CAMERA (to be more
specific, a frame grabber or a USB camera)
When I try to grab images from a camera, I don't have to change my
"user" program. I just try to open the device and if I succeed, I can
get information about the image such as dimensions of the image and
special properties such as exposure, shutter, number of channels,
white balance. Some cheap camera will tell you. "look man, I DONT
provide this feature" (manual exposure for example) and this is
"accepted" by the user that will be able to perform its duty anyway.
In you application (Skype, OpenCV, etc) you don't need to do any
hardware specific programming. Sometimes you want to take advantage of
hardware specific features, such as manual trigger of the frame
grabber, but this is up to you and its for a very limited number of
users.
I insist: if this was successfully done for cameras, why isn't it
possible to do the same for other kind of devices?

Davide

reworking OCL / best practice examples

>Orocos _has_ to get out of this "I-am-the-only-guy-working-on-this-hardware"
> mentality and _solve_ this problem!

I fully agree with Herman.

>> Let's for instance take the laser scanner. Some scanners give quality
>> information: hokuyos for instance give error codes for each ranges. Some other
>> methods use the intensity readings to add reliability values to the ranges.
>>
>> Another example would be GPS interfaces, as the availability of accuracy
>> information really depends on the device you have.
>>
>
>> This is exactly my experience with HALs as well. I tried it with rtt/dev
>> and came to exactly the same conclusion. Its nice for simple demo
>> programs (or Comedi), but when you want to use your sensor fully, talk to
>> the device's C API directly (and let the OS abstract as much as possible
>> for you)
>

I think you are a bit too pessimistic about the HAL, and in front of
your eyes, in the very same moment that you are reading this e-mail,
you have an example.

Your screen, mouse and keyboard are running through the equivalent of
a standard interface, some of them will work with generic drivers,
others will require that you install the driver of the vendor. But one
they are installed, all the programs who need them for input/output,
will not have to write any vendor specific code.
This is what OS do...

Let me do another example that is closer to robotic community, an
example of successfully standard interface: a CAMERA (to be more
specific, a frame grabber or a USB camera)
When I try to grab images from a camera, I don't have to change my
"user" program. I just try to open the device and if I succeed, I can
get information about the image such as dimensions of the image and
special properties such as exposure, shutter, number of channels,
white balance. Some cheap camera will tell you. "look man, I DONT
provide this feature" (manual exposure for example) and this is
"accepted" by the user that will be able to perform its duty anyway.
In you application (Skype, OpenCV, etc) you don't need to do any
hardware specific programming. Sometimes you want to take advantage of
hardware specific features, such as manual trigger of the frame
grabber, but this is up to you and its for a very limited number of
users.
I insist: if this was successfully done for cameras, why isn't it
possible to do the same for other kind of devices?

Davide

reworking OCL / best practice examples

> >Orocos _has_ to get out of this "I-am-the-only-guy-working-on-this-
> hardware"
> > mentality and _solve_ this problem!
>
> I fully agree with Herman.
>
In principle I do to. But I wonder how. Our controller for example
doesn't support floating points. So we can forget about an AnalogInput
interface using doubles... (because double emulation code takes way to
much time...) For your walking robot's hardware for example this
constraint is not an issue.

Sander.

reworking OCL / best practice examples

> >Orocos _has_ to get out of this "I-am-the-only-guy-working-on-this-
> hardware"
> > mentality and _solve_ this problem!
>
> I fully agree with Herman.
>
In principle I do to. But I wonder how. Our controller for example
doesn't support floating points. So we can forget about an AnalogInput
interface using doubles... (because double emulation code takes way to
much time...) For your walking robot's hardware for example this
constraint is not an issue.

Sander.

reworking OCL / best practice examples

On Fri, 8 May 2009, Vandenbroucke Sander wrote:

>>> Orocos _has_ to get out of this "I-am-the-only-guy-working-on-this-
>> hardware"
>>> mentality and _solve_ this problem!
>>
>> I fully agree with Herman.
>>
> In principle I do to. But I wonder how. Our controller for example
> doesn't support floating points. So we can forget about an AnalogInput
> interface using doubles... (because double emulation code takes way to
> much time...) For your walking robot's hardware for example this
> constraint is not an issue.
>

This practical problem is solved by separating the standardized APIs from
the concrete algorithms behind them.

Herman

reworking OCL / best practice examples

To get more insight and (maybe) a bit of inspiration about this topic,
I would suggest the reading of the paper "Really Reusable Robot Code
and the Player/Stage Project".
We may argue that may be Player didn't do what he promised, but still
I think that the philosophy presented in the paper is still a valuable
contribution to the topic.

For lazy (or busy) people, I have extracted the more significant test
(in my opinion) and I have copied in the following Wiki page:

http://www.orocos.org/wiki/orocos/ocl-wiki/quotes-really-reusable-robot-...

Davide

reworking OCL / best practice examples

On Thu, May 7, 2009 at 10:34 PM, Peter Soetens <peter [..] ...>wrote:

>
> This is exactly my experience with HALs as well. I tried it with rtt/dev
> and came to
> exactly the same conclusion. Its nice for simple demo programs (or Comedi),
> but when you
> want to use your sensor fully, talk to the device's C API directly (and let
> the OS abstract
> as much as possible for you)
>

Other project that tried to find such a HAL for motion control were OSACA (
http://www.osaca.org/),
OSEC and OMAP (which used Microsoft IDL) They all described interfaces and
the
necessary state diagrams to use the objects correctly. They were huge
efforts, but failed
to set the standard. Especially the OMAP API is worth taking a look at for
seeing the complexity you'll
end up with. And they didn't even start using laser scanners (I'm guessing)
! Look for
'THE OMAC API SET WORKING DOCUMENT' PDF on the internet.

In the end, I'd rather adapt my hardware component to my 'logic/calculation'
components.
The former is easy to write and test (given a C api exists), the latter is
not and is what you
want to reuse most. But that's only my opinion...

Peter

reworking OCL / best practice examples

On Thu, May 7, 2009 at 10:34 PM, Peter Soetens <peter [..] ...>wrote:

>
> This is exactly my experience with HALs as well. I tried it with rtt/dev
> and came to
> exactly the same conclusion. Its nice for simple demo programs (or Comedi),
> but when you
> want to use your sensor fully, talk to the device's C API directly (and let
> the OS abstract
> as much as possible for you)
>

Other project that tried to find such a HAL for motion control were OSACA (
http://www.osaca.org/),
OSEC and OMAP (which used Microsoft IDL) They all described interfaces and
the
necessary state diagrams to use the objects correctly. They were huge
efforts, but failed
to set the standard. Especially the OMAP API is worth taking a look at for
seeing the complexity you'll
end up with. And they didn't even start using laser scanners (I'm guessing)
! Look for
'THE OMAC API SET WORKING DOCUMENT' PDF on the internet.

In the end, I'd rather adapt my hardware component to my 'logic/calculation'
components.
The former is easy to write and test (given a C api exists), the latter is
not and is what you
want to reuse most. But that's only my opinion...

Peter

reworking OCL / best practice examples

On May 7, 2009, at 17:04 , Peter Soetens wrote:

> On Thu, May 7, 2009 at 10:34 PM, Peter Soetens <peter [..] ...
> > wrote:
>
> This is exactly my experience with HALs as well. I tried it with rtt/
> dev and came to
> exactly the same conclusion. Its nice for simple demo programs (or
> Comedi), but when you
> want to use your sensor fully, talk to the device's C API directly
> (and let the OS abstract
> as much as possible for you)
>
> Other project that tried to find such a HAL for motion control were
> OSACA (http://www.osaca.org/),
> OSEC and OMAP (which used Microsoft IDL) They all described
> interfaces and the
> necessary state diagrams to use the objects correctly. They were
> huge efforts, but failed
> to set the standard. Especially the OMAP API is worth taking a look
> at for seeing the complexity you'll
> end up with. And they didn't even start using laser scanners (I'm
> guessing) ! Look for
> 'THE OMAC API SET WORKING DOCUMENT' PDF on the internet.
>
> In the end, I'd rather adapt my hardware component to my 'logic/
> calculation' components.
> The former is easy to write and test (given a C api exists), the
> latter is not and is what you
> want to reuse most. But that's only my opinion...

+1.

You see this also with "generic" USB devices. Nice that the bus is
standard, shame you have to write a custom driver for every single
device out there.

reworking OCL / best practice examples

On Mon, 4 May 2009, Sylvain Joyeux wrote:

>> Personally, I think that we need something very common in other
>> framework such as Player or Orca2, which is a Abstract Device
>> Interface.
>>
>> robotics.stanford.edu/~gerkey/research/final_papers/iros03-abstraction.pdf
>>
> Well ... I never was able to *really* know wether or not these HALs where a
> good or a bad thing. When I see the player HAL, I'm feeling like "OK, that's
> generic but actually there's a lot of VERY useful information that never gets
> through". I do feel the need for HALs (hey, that allows for easy replacement
> of devices and software, which is definitely very nice to have). But ...
>
> Let's for instance take the laser scanner. Some scanners give quality
> information: hokuyos for instance give error codes for each ranges. Some other
> methods use the intensity readings to add reliability values to the ranges.
>
> Another example would be GPS interfaces, as the availability of accuracy
> information really depends on the device you have.
>
> And why those values are removed from the HALs ? Because they are not generic
> enough. I.e. I always have the feeling that HALs are the interface of the less
> powerful devices and less powerful approaches out there. If you want anything
> more advanced, you have to use something different.
>
> What do you people think ?

"Aggregation" of the generic HALs with a device-specific interface that
covers the extra properties of that specific device.
Take the example of a laserscanner: _the_ important thing is that the
device provides a (planar) scan, irrespective of the technology used or of
the vendor; such a scan has natural properties (number, angle range, etc.)
as mentioned already by Davide. But each specific scanner has its own
specific properties, depending on the technology used or the algorithms
provided with the device.

FYI: In Orocos/KDL (and Orocos/BFL) we are working towards such a (set of)
interfaces, and we have been discussing this approach for quite a long
time. The goal there is to find the smallest possible interface to
kinematic chains (or Dynamic Bayesian Nets), while allowing for the rich
variety of numerical "solvers" that each come with their own feature set.

Herman