Hard Realtime userspace (yes) , Hard realtime CORBA (maybe)

Hi,

The single biggest problem (well, one of them) on the Orocos@KUL front (the 
hard realtime people) was that the code was only usable as Linux kernel 
modules. Shortly put, this means that not even the libc library was available 
for your application, let stand the standard C++ library. In the past, we 
have put a lot of effort in  getting some basic library support in the linux 
kernel anyway. Because this approach was most successful with RTAI, we 
encouraged everyone to use it. With new GNU compilers, coming up (gcc 3.X), 
the same problem (library support) must be solved again ( see the 
http://www.orocos.org/cvs_status.html file). 

Fortunately, there is an alternative. It's called LXRT (LinuXRealTime) and is 
a natural extension to RTAI. If you want to know some basics, you can read 
the document I have written here : 
http://people.mech.kuleuven.ac.be/~psoetens/portingtolxrt.html

In short, LXRT allows you to communicate hard realtime with your hardware from 
userspace, allows a hard realtime thread to run in the same process as a not 
realtime thread (i.e. your GUI), and provides communication primitives 
between both. It is what we were waiting for. The future of kernel modules is 
reserved for experts (like people writing realtime device drivers), rather 
than the normal Orocos user, who wants to control a robot. 

The next (logical) step is connecting the userspace programs together. LXRT 
allows to bind realtime and not realtime programs together. What Anders & Co 
have been doing for mobile robots can thus be merged with the KUL software. 
Enter CORBA. 
One month ago, a company called OCI has started a port of ACE (a C++ OS 
abstraction layer) and TAO (a C++ CORBA implementation) to RTAI/LXRT, with 
the aim of writing CORBA servers that would be realtime capable. The porting 
effort finished now, but is far from complete. The community will be asked to 
help ending the port (which is freely available). So I hope now you 
understand why a common IDL specification between hard and soft realtime is 
indispensable. They will be able to communicate, and therefore, should speak 
the same language.

Will Orocos, in the end, become a CORBA bastion ? Hard to say. IDL does not 
force you to use CORBA, it is just a language independent way of describing 
object interfaces. But will it rely on CORBA to provide its functionality ? 
At a higher level, probably yes, for (embedded) robot control, probably not. 
Allowing distribution of functionality has always been a key aim of this 
group, so in the end, you might choose between the compact, efficient 
implementation (think KUL) and the distributed heavier implementation (think 
KTH). That's a choice we wish to leave to the user.

As a quite important footnote, these evolutions have quite an impact on the OS 
abstraction layer. Will we choose ACE as the default OS abstraction layer? I 
remember grave opposition to this on the first Orocos meeting, but looking at 
the realizations of ACE ( 
http://www.cs.wustl.edu/~schmidt/ACE-versions-i.html ), then you know they 
are doing a better job than we do. I regret that ACE did not support RTAI two 
years ago, it could have saved Orocos@KUL a lot of time. Well, are we 
prepared to put the ACE-requirement on any OS we want to use ? This would 
rule out RTLinux and ecos right away, along with other embedded applications.
Any thoughts/comments of the community are welcome.

Peter

-- 
Peter Soetens
The Orocos Project  : http://www.orocos.org
KU Leuven - Belgium
--