Re: How to build an Orocos application

On Wed, 15 Jan 2003 [email protected] wrote:

[...]
> 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.
It doesn't exist yet, because the API we want to offer for such tasks is
not yet there. So, indeed, at this moment, Orocos is not much more than
a wrapper around some RTOS functionality...
On the other hand, the control of your Comau system is not so different
from what we do with our Kuka, so I'm quite sure that Peter could give
more details about how to change our configuration to make it work with
yours. What I wanted to make clear is that also we will have to make a
lot of changes to our system before we reach a stable "version 1.0" API.
So, the efforts you spent now in getting our prototype to work on your
system will be spent in vain, at least partly.

> 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?
You are not wrong at all! It is indeed one of the goals, but the support
needed to ease the job of the ``Application Builder'' is not yet
available in the form we have in mind, i.e., as a simple configuration
API, in which you register your functionality in the appropriate Orocos
components, configure your sampling rate(s), and go...

> 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 agree, but in Orocos we want to separate the configuration of the
framework (and the choice of using a FIFO somewhere is such a
configuration option), from the plugging-in of the application
functionality (such as the servo control function you want to use).

> 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 agree, but this makes uses of two layers of the same Orocos structure,
but with quite different configuration desiderata. This layering is even
more so lacking the needed interfaces...


> Could Herman (an author of the paper) or someone else give more
> details about it?

I have just almost finished the draft of the next version of that paper,
where most of these issues are (hopefully) dealt with in the required
level of detail. Together with Peter and Bob I will try to finalize this
paper in the coming week or so, after which we announce it here, to get
feedback and suggestions from the community. However, much of the things
presented in that paper are not yet implemented, or given more or less
stable names or even functionality.

> 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.
Eventually, yes. Because that's the motivation behind Orocos: to avoid
this overhead in configuring application. But again, before we can avoid
that overhead, we still have a lot of work to do :-)

> I apologize in advance for questioning about issues that might be well
> known to everybody.
>
Please do not apologize! I appreciate this discussion very much, and
agree with the things you expect to see in Orocos. But it's simple not
there yet in a simple to use way.

Best regards,

Herman

-- 
  K.U.Leuven, Mechanical Engineering, Robotics Research Group
<http://people.mech.kuleuven.ac.be/~bruyninc> Tel: +32 16 322480