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

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

> 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
---------------------------------------------------------------------

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

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

On Thu, 7 May 2009, Peter Soetens wrote:

> On Mon, May 4, 2009 at 3:06 PM, Sylvain Joyeux <sylvain [dot] 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 ?

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

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

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