OROCOS remarks

> Components are usually parts of a greater whole, so maybe first this whole
> should be defined. I personally favour top-down design in opposition to
> bottom-up one. Whatever we create has to match other components, and that
> can be attained more easily if you have a general idea how this greater
> whole (robot system controller in this case) will look like.

Well, I don't agree completely :-) Another thing that became clear on
the meeting was that the `whole' is very different for everybody,
i.e., most people don't agree on the architecture of their robot
system software. Therefore, we decided to avoid architectural
discussions and focus on the bottom-up building blocks. Of course,
once people start to build systems with these blocks, we will notice
that the specifications of some blocks have to be adapted. This means
that the API will be quite volatile during the first year of the
project, I think.


C.Z.:
OK - this makes the task more clear to me. You want to deliver just the building blocks without specifying the overall structure of the controller. I am not in favour of this approach, but can go on with it and find out what will come of it. With this approach you give more space for the creativity of users, but on the other hand make the task of building a controller more difficult for them. Maybe a middle of the road approach would be valid - at least we should hint to the users what an exemplary structure should look like? Although you can build very diverse structures out of LEGO blocks, the company delivers plans how to build something specific.


>  SPECIFIC REMARK
> In the discussion some space was devoted to the communication of the modules
> (or their components - that was not clear to me). This is one of the most
> important aspects of building a controller from disjoint components. I would
> like to pint out that communication should take into account two modes of
> operation: normal and failure. Normal mode is when everything is going on as
> planned - and that was what the discussion concentrated on. The failure mode
> was not at its focus.

We indeed didn't spend much time about errors... We did discriminate
multiple modes, though, where the configuration (or supervision) mode
would be a second mode next to the normal mode.

C.Z.:
My experience shows that monitoring errors is not an add on. It is interwined with the normal mode of operation. The components have to detect their own error states, transmit them to upper control layers, and those layers have to be able to retransmit the errors whilst adding some information of their own. Finally the information should reach the user interface, and thus the operator. As components have usually multiple states of their own, otside (disjoint) monitoring would be very cumbersome and time consuming, so I don't think it would be feasible.


> From experience I know that the code devoted to
> failure mode is usually as large as the one dealing with normal functioning.
> There are 3 kinds of failure communication due to:
> 1. Non fatal errors (e.g. user demanding something that is beyond the
> capabilities of the system)
> 2. Fatal errors (e.g. robot hardware malfunction - for instance somebody
> forgot to power up the motors)
> 3. System errors (e.g the control network malfunctioned)
> Reactions to all of those errors need to be included in the specification of
> the modules.

I agree with this suggestion. Maybe you have some concrete examples
that you can post on the mailinglist?

C.Z.:
Non-fatal errors, e.g.:
a) location outside the workspace of a manipulator - usually results in a computational error within the inverse kinematics
b) a sensor due to transmission error delivers garbage
c) time constraints imposed on a motion are to demanding (motion to fast)
After the ocurrance of those errors you can try some error recovery procedure. Surely the system should not disintegrate due to them.

Fatal-errors, e.g.:
a) malfunction of servomotor or position encoder
b) some hardware missing
Here at the most you can and should inform the operator about the cause of malfunction

System errors, e.g.:
a) if the controller is distributed over a network of computers, and some network connections malfunction it might be impossible to notify the operator
b) operating system error
Those errors cause the malfunction of the "brain", which at the same time is the main means of internal communication. Here partial disintegration of the system is inevitable. What to do then - personally I don't know! This is a quetion for discussion.

> I am speaking about notification of the operator rather than
> "artificial intelligence" methods of solving the problems as they arrise.
> Moreover it is anticipated that the user will be putting the components
> together to create a control program suting his/her needs. Here errors can
> arrise, so detecting them is of paramount importance. The easier you can do
> it the greater the value of the created software.

Indeed. And this is, in my opinion, one of the functions of the
supervisor mode: check on-line wether the components are connected in
meaningful ways. I have no idea yet how to do this in practice, though
:-)

C.Z.:
This can be done by some kind of initial "simulation" of the behaviour of the connected components. I am speaking about something happening at run-time. This makes it necessary for the components to perform some kind of self diagnostics (rather continually than periodically) and be able to communicate their findings to the others.

Cheers,
Cezary