Some remarks by Cezary Zielinski...

I forward an email conversation with Cezary Zielinski (with his
agreement).

-----------------------------
[...]

> As I didn't attand the meeting I am not aware of all of its results. First
> of all, reading the mails I saw that you are devoting a lot of time to the
> terms: module, component etc. I assume that through a strict definition you
> want to arrive at a detailed specification of the future software.

Indeed. During the meeting is became clear that most people use the
same words for different things, so we decided to try to define our
terms once and for all. Of course, these definitions are not yet cast
in stone, so I am open to remarks about them.

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

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


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

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


Best regards,

Herman