Re: How to build an Orocos application

At 16.15 15/01/2003 +0100, you wrote:
>On Wed, 15 Jan 2003 [email protected] wrote:
>
> > I need to write a simple orocos application.
> > I want to create:
> >  3 RT processes (ZTT),
> > 1 RT process (ZLT),
> > 1 Not-RT process in user space.
> > All ZTT processes must be connected with ZLT Process by fifo's,
> > The not-RT process  must be connected to ZLT process,
>
>Well, what I (personally) want to achieve with Orocos is that this kind
>of design will not be happening anymore after Orocos has matured :-)
>Why? Because starting a design with saying that you need fifo's to do a
>job is mixing up things, and is the reason for non-portability of
>applications.
>Anyway, if you want to define fifo's and threads yourself, you'd better
>not try to use Orocos, because it will create overhead for you. And the
>transparent IPC is exactly a part of Orocos that is not yet
>implemented... We are working on the _infrastructure_ and not yet on
>applications.


Actually, we want to develop the software to control the COMAU SMART 3S 
robot with open controller we have in our lab using as far as possible the 
Orocos concepts, tools, and software infrastructure. We want to run the 
control software in a pc running  RTAI. The pc is bus-to-bus connected to 
the COMAU C3G controller. The controller transmits joint position and the 
pc reads them, computes control algorithms and sends back motor current 
setpoints (sampling frequency 1 KHz).

So far, the students (Piercarlo and Fabrizio) have been able to install the 
Comedi drivers and the 6 Orocos 0.9.0 drivers, and to test them. All tests 
are OK, besides those requiring boards be physically installed.

The problem is that now they don't know how to proceed to build a motion 
control application similar to the one done in Leuven with the Kuka robot. 
Maybe there is a document explaining how to proceed, but they haven't been 
able to find it in the OROCOS site.

Just to see the problem from another point of view, I suggested them to 
investigate how a simple multitasking software architecture (consisting of 
few basic tasks, one of them asynchronous and low priority) could be built 
over the Real Time Control Core. I understood the latter is a software 
built over a real time kernel to support implementation of process control 
software. I expected to be a proper use of the Core to try to implement 
such an architecture over it. Where am I wrong?

I mentioned the fifo queue because I think it is a task communication 
approach that can hardly get rid of in a robot controller. I see the need 
of a fifo buffer between the Trajectory generation and the Trajectory 
interpolation tasks, for instance, to be used to implement MOVE commands 
with VIA points. I read a paper on the RTCCore, recently, but how the task 
communication works was not discussed in detail there. Could Herman (an 
author of the paper) or someone else give more details about it? We wish to 
use OROCOS to avoid overhead concerning implementation of things like fifo 
buffers, but we expect these kind of functionalities are made available to 
the user by RTCCore.


>But of course, this doesn't help you at this moment :-(
>And I have no real advice at this moment, because I know that things are
>still changing before we reach 1.0...

Could this statement be made more explicit?

I apologize in advance for questioning about issues that might be well 
known to everybody.
Thanks for attention and help.
Gianantonio