Re: Error handling for components (Was Re: OROCOS remarks)

On Fri, 21 Sep 2001, Cezary Zielinski wrote:

[...]
> > Ok, I see we are really thinking about the same lines: the confusion
> > was that I was talking about `architecture in the large' (= how should
> > all components in a robot control software work together), while you
> > were rather talking about `architecture in the small' (=how does a more
> > linited set of functionality (=`component' in my terminology) work

> I had both sizes in view. For instance the operator interface - which is
> standard for all MRROC++ based implementations - requires the general view
> of the architecture.

Indeed: an operator works with a specific architecture. The
`operators' in the short-term Orocos scope are the _designers_ of
robot control software, so the horizon is a bit different :-)

> Most people go for the standard architecture. The problem is
> that they have very diverse needs. For instance I have a group dealing with
> control algorithms reducing the effects of friction, which is very
> non-linear. On the other extreme I am interested in behavioural control -
> which is very high level. Nevertheless the general architecture and the
> components are well suited to both.

Maybe that's the case for _your_ needs, but not for the needs of
somebody else. For example: somebody wants to _distribute_ the control
functionality over multiple processors. Or wants to run a
behaviour-based algorithm that takes input of another system or
another set of sensors.

> From time to time we have to tailor the
> components, but usually it is fairly simple.

That sounds great! :-) Probably it would be very interesting for us if
you could summarize MRROC++ on this mailing list? (Or in a document I
can put on the web.)

[...]
> > But of course, some `glue' may be needed. But this is a `software
> > pattern' (``Facade''), i.e., a mature and well-uderstood technical
> > issue.
> >
>
> I don't object to this approach. I think that the first few tries will be a
> miss, but will gain us  invaluable experience.
> This is a field of knowledge in its infancy - perhaps that is why it
> is so exciting for me.

But your experiences (and those of ourselves, Smartsoft, Genom, DROS,
etc.) _are_ already these ``first few tries''! I think the `infancy'
is really over, _if_ we succeed in really drawing the lessons from
all our previous experiences! So, I very much welcome a more detailed
description of your experiences :-)


> Bear in mind that we don't have any established mathematical tools
> that can be applied to solve our problems -

I don't completely agree :-) One of the things I learned at the
meeting is that there _are_ proven solutions to some of our problems,
e.g. (almost) everything that has to do with (distributed)
communication between de-coupled components; or FSM-based task
scheduling and monitoring.

[...]
> > > We took the view that all the components should degrade
> > > gracefully leaving the hardware in a safe state. Unfortunately
> > > this leads to the whole system commiting sucide.
> >
> > Is this really an unavoidable result? I would look at it more as of a
> > kind of `hibernation': the components wait to be woken up again,
> > without having lost their `senses'. But it's too early to forecast
> > what will be possible in this respect.
> >
> Yes - this is a solution, but that would need the introduction of some
> "artificial intelligence" which would make decisions disregarding the
> operator (lack of communication presumably cuts him off).

Some errors can be dealt with automatically (without needing
``intelligence''), e.g., loss of communication, loss of tracking of an
object, etc. Others cannot, and the system should then wait for the
operator to take action. If this is not possible, the system has
become useless (as it should).

Herman