Answers

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

Within QNX IPC we mainly use message passing (i.e. Send-Receive-Reply) which is the same regardless whether the processes reside on the same computer or on several connected by Ethernet. We also use proxies, especially where contact with interrupt handling routines has to be established. We didn't have need for other forms of IPC, but I think that you could come up with a problem that would be better handled by shared memory (especially if you want to move large data blocks - but I personally think taht in such situations you should do some processing on tthe initiator's side, aggregate data, and then send the aggregated effect) . In QNX all primitives are C functions. You use them in your own code by simply calling them with adequate actual parameters, so no specific API is needed. 


> 
>   If I understand the QNX messaging correctly, it is a blocking
>   `rendez-vous' (a 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.

You have both flavours: blocking and non-blocking. You either use Receie or Creceive. If the send has to be non blocking you use an intermediate process, but that is just a technicality. If the processes are on phisically separate computers then everything is executed in parallel. Usually there is no need for that. Moreover you have to take into account longer IPC latencies in the case of network version.

> 
>   My question (to the whole group) here is: what kinds of IPC do we
>   _really_ need?
> 
I think that the above syffice, but would not object to others. I like diversity as long as it does not lead to confusion.

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

I think that both within computer science and control this term is used. Although I don't  know if anybody is using it within robotics community.

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

I trace this to hierarchical control systems - this architecture is well established and prety useful.


>   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.
> 
Glad to hear it - it will be much easier to cooperate.

>   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].''
> 
That is correct.

>   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.
> 
This was the main idea behind MRROC systems.

> - 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).
> 
This is a good way forward. MRROC++ is not perfect. It still needs new ideas.

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

MRROC permits two kinds of cooperation with sensors: interactive and non-interactive. In the case of non-interactive the motion process obtains the most current reading available, so no waiting for processing is necessary. In the case of interactive communication the process of obtaining a reading is split into two parts: request of data, and reading of data. Both are disjoint and it is anticipated that that in the meantime the reading and aggregation will be performed. If not an itermediate process can be used, but that more or less ammounts to no-interactive communication. 

I don't know exactly what a stub is, but I think that that is more or less the same as the thing I call an image. The image is a representation of the sensor reading on the side of the motion process (MP or ECP).

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

In that case we use signals. They are generated by the operator through the User Interface UI.

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

Yes, because they can catch the error on a lower level. If they fix the problem, the system on the upper level does not have to be informed about the mishap.

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

No this is not correct. The paper does not say much about the EDP. Please take a look at the fig.8 of the RoMoCo conference paper. There you have the EDP commands. Currently you can have up to 256 servo algorithms per each servo and each of those servos can handle 256 sets of parameters, so I think that it is more than enough. If you are cerful you can switch between algorithms or their parameters even during motion execution. The problem is to have the current values in both algorithms, e.g. especially the integral component, but also the previus value for the sake of differentiation. In this respect both algorithms have to update their variables or when the switch is executed an update has to be performed.

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

You don't have, as sensor interaction is included in the Move or Wait instructions. Please note that you deliver both the list of sensor images used and the generator/condition as arguments. The list determines to which sensors you want to talk and the generator determines how you use the sensor readings in motion generation/modification. The same applies for the condition of the Wait instruction.

I am waiting for the next batch of questions.
Cezary

> 
> Herman