Re: A working document

My comments are included in the text.
C.

----- Original Message -----
From: "Anthony Mallet" <[email protected]>
To: <[email protected]>
Cc: <[email protected]>
Sent: Friday, December 21, 2001 4:41 PM
Subject: Re: [Orocos] A working document


>
> | 1) Does fig.1 imply that all hardware elements (e.g. actuators, sensors)
=
> | have to be connected  to the upper layers of the system through the =
> | operating system? Is no direct connection (i.e. port access) =
> | anticipated? My experience is that usually sensors and actuators are not
=
> | handled by the operating system directly.
>
> It's true that the 'sensors layer' can sometimes bypass the OS (e.g. for
> huge data transmissions). However, those mechanisms are provided by
> system calls. Thus the OS is still involved, at least for the setup
> phase.
>
My experience is that it usually bypasses the OS. Usually direct
input/output from ports is used. Unless you are thinking about those fancy
sensors connected to the system through RS232 etc. In that case you are
right that OS facilities for handling RS232 are used.


> It's difficult to choose a good place for the OS in the figure you
> mention. Maybe we should draw a single box, made of the two components
> 'OS' and 'sensors interface'.
>

That would solve only the outward appearance, but still leave the problem of
implementation untouched. As I understand OROCOS either wants to use a
public domain OS (such as Linux) or create one for our own use. In both
cases we have to decide where the low level communication with sensors will
be located.

>
> | 2) How important do you think time-out is in the case of robotic =
> | components?=20
>
> I think you talking about the 'max-time' field of services and codels?
> The timeout is only a way to detect failures (e.g. a servoing task that
> lasts too much and thus cannot execute properly). Once detected, it is
> possible to make the information available for other modules or for the
> decision layer.
> For instance, a module could run perfectly on a machine with much CPU,
> but I could completely fail on another machine, or if the CPU gets
> overloaded.
> Not all the components  are interrested in such temporal properties, but
> for the lowest (real-time) level, I think it's important. Don't you?
>

Such a feature of the system would be usefull, but quite difficult to
implement as we are taking of measuring time with high resoluton (e.g. less
than 1 ms). If a system is not able to execute the srvo loop in prescribed
time (e.g. 1 ms) will it be able to measure time with that resolution? RTOS
usually depend on timeslices. For slow CPUs thay can be 10ms or 50ms. The
other problem is that the fact that the CPU is too slow would emerge at
run-time. That would mean that the servo algorithm is already executing.
Large delays destabilise the system and that you usually hear as the robot
starts to shake, so ypu wuill have the information aboyt the inadequacy of
the CPU long before you will be able to read the warning off the screen.
Nevertheless maybe there are some technicl means (which currently don't come
to my mind) that can solve the above mentioned problems. Maybe the
utilisation of external clock (hardware) and high priority interrupts could
solve the problem.

>
> | 3) Are codels pure code? (no data structures). That would imply =
> | disjunction between code and data which is contrary to object oriented =
> | paradigm, which has its benefits.
>
> Yes, definitely. Codels are made of code, and perform tasks on data that
> come from elsewhere.
>
> The purpose of modules is to give a specification of their interface in
> terms of functionality, so that the decision procedures can do symbolic
> reasonning. Besides this, you are free to put what you need into the
> codels. For instance, I see no problem in sharing the same class between
> several modules, and thus use a pure object oriented approach _within_
> codels, to manipulate the structure that are exchanged between the
> modules.
>
>
> | 4) I would suggest a change in terminology. Instead of using the term =
> | "database" I would use the term "component image". Database has a =
> | slightly different meaning in computer science. In this case the outside
=
> | world (other components) percive the component through the exported =
> | image. This compnent perceives other components through imported image.
=
> | Thus we have a component image.
>
> Yes, database is not the good word :). This is rather an _internal_
> repository that represents the instataneous value of the parameters of
> modules.
> However, this repository is not visible to the outside world. What is
> visible is the exported data (the production of the module), and the
> services that either produce that data or modify the internal parameters.
> So I'm not sure that 'component image' applies here?
>

Again I misunderstood the text. I thought that the database is visible to
the outside world. Under those circumstances i withdraw my suggesion, but
still don't like the name "database".

>
>
> | 5) The question wether communication should be handled within codels or
=
> | outside I would answer in favour of - inside. After all we want to hide
=
> | from the user all the unnecessary details - he/she should concentrate on
=
> | the task not on the communication details. Maybe special communication =
> | codels would do the trick (an intermediate solution).
>
> I completely agree with you on the fact that communication should not be
> left to the user (user = module programmer). This is exactly why I think
> that communication should _not_ be defined within codels: codels are the
> only part the programmer will write. The communication should be handled
> by the module internal engine (which is roughly the same for all modules,
> and thus it is generic and written only once).
> Are you ok with this?

OK. It seems that I misunderstood the concept of codels. I thought that they
are atomic entieties delivered by us to the users (kind of library
procedures). Then out of codels the user assambles his/her algorithm. Your
explanation suggests that the user writes the internal workings of the
codels. In that case you are right that the communication should be placed
outside codels. Nevertheless after some time of using the system people will
have their own libraries of codels, so perhaps the system designers could
deliver some codels in advance? And then we return to the location of the
communication.