Comments on Zielinski's papers...

I've been reading
 - The MRROC++ System
 - BY HOW MUCH SHOULD A GENERAL PURPOSE PROGRAMMING LANGUAGE BE
   EXTENDED TO BECOME A MULTI-ROBOT SYSTEM PROGRAMMING LANGUAGE?

and here are some questions and points of discussion. They are
directed to Cezary in the first place, but I think others can add
useful comments and insights too :-)

- You use QNX-4. At what level, and through which API, do you make
  abstraction of the RTOS? (I ask this question because I would like
  to have Orocos being independent of a particular RTOS also.)
  Do you use only the QNX message passing IPC primitives? Are they
  sufficient, or do you feel the need from time to time for
  `raw' IPC between threads available? (E.g., shared memory, mutexes,
  ...)

  If I understand the QNX messaging correctly, it is a blocking
  `rendez-vous' (à la Concurrent Sequential Processing), which makes it
  much easier to understand the workings of programs, but which puts
  quite a strong constraint on the in which tasks can do their stuff
  in parallel.

  My question (to the whole group) here is: what kinds of IPC do we
  _really_ need?

- is the terminology ``named data aggregation'' yours, or is it a
  name and concept that is used more widely?

- I recognize the same patterns in your architecture as in the
  components of Orocos (as far as we have already discussed these
  patterns): supervisor (`master', `ECP'), worker (`servo', `EDP'),
  sensor, actuator (`effector'), status/monitoring, `user interface',
  (motion) generator.

  That is probably no coincidence because this pattern comes back
  everywhere in robotics. (Maybe that is even the _definition_ of
  a robotic system, i.e., one that has each of these components?:-)

  At KULeuven, we are currently working on the design of the motion
  control part in more detail, and we have only a few more parts and
  more flexibility in IPC configuration, but the `pattern' is the
  same, fortunately.

  So, my conclusion is that our understanding of this division into
  components is quite mature at this moment.

- ``The user's program (task) is coded by writing some
    distinct portions of MP [supervisor of whole system] and ECP
    [supervisor of robot control system].''

  Also this is compatible with the views expressed by others in
  Orocos: the above-mentioned pattern is the basis, in which the
  user/task programmer/developer adds specific parts, being confronted
  with only a small part of the complexity of the whole thing.

- what Orocos wants to do more is to provide really _independent_
  components (as far as independence is practically achievable, of
  course), i.e., each component has an interface that allows
  distributed, dynamic configuration (among other things).

  An example of the added flexibility can be understood by looking at
  Figure 4 in the MRROC++ paper: I might misread this figure, but it
  suggests that the Move instruction blocks in each of the rectangles
  in the flow diagram (reading sensors, calculating motion, ,,,)?
  Orocos would have to allow not to block (if one desires so), and use
  a `stub' of the sensor and motion components.
  The same reasoning holds for all other `higher' levels of the robot
  control system.
  But maybe what you call ``the images of sensors re ecting the state
  of virtual sensors'' is exactly the same as what I call a `stub'?

- How can a process that is blocked in a Wait state be interrupted?
  For example, when the user wants to stop the currently executed
  motion?

- `` Errors are dealt with within the whole system by exception
  handling, so the user needs not deliver the program code responsible
  for that.''

  But can the users add their own error recovery?

- Do I understand it correctly that you don't allow the user to, for
  example, change the servo control algorithm? Or its tuning
  parameters?

- how do you extend the Move and Wait commands for sensor-driven
  commands, such as force control or visual tracking?

Herman