Re: Orocos and RTAI/LXRT

Paolo Mantegazza <[email protected]>
Newsgroups gmane.science.robotics.orocos.user
Organization Dipartimento di Ingegneria Aerospaziale, Politecnico di Milano (DIAPM)
Message-ID <[email protected]>
Pierangelo Masarati wrote:
> 
> Herman Bruyninckx wrote:
> > On Wed, 25 Jun 2003, Pierangelo Masarati wrote:
> >
> > [...]
> >
> >>Our multibody software is a mix of C++, F77 and C, linked to many
> >>standard and specialized libraries, and the major effort in exploiting
> >>LXRT was to ensure no system calls were performed during the normal
> >>execution (e.g. after hard real-time is enforced), which required
> >>patching a couple of libraries.
> >>
> >
> > Do you have more information on this topic you mention, i.e.,
> > the programming policy to ensure no system calls are performed?
> 
> Basically,
> 
> any time a program in hard real-time executes a system call,
> the process is kicked back to soft real-time.  All system calls
> must be done thru LXRT calls.  This is basically
> a trial-and-error process when adding real-time capabilities
> to an existing program.  In our case, all logging and diagnostics
> messaging has been wrapped by RTAI mailboxes, talking to a
> low priority messaging dispatcher; the most annoying problem
> was with Umfpack calling times() during linear algebra operations
> for performance profiling even when no profiling was required.
> We patched Umfpack to allow to programmatically disable profiling.
> 
> I'm not aware of specific documentation on this, there has been
> a flourishing of howtos and informal documents on RTAI and LXRT.
> 
> I think you should ask Paolo (who's in CC and might answer in turn).
> 

I've been instrumental only in avoiding them to loose time to read the
RTAI manual and READMEs to determine the few calls that were needed,
i.e. attach the real time extension, making it soft/hard and so on.

All the rest appears to have gone relatively smooth. The basic idea
implemented by Pierangelo and friends has been to have the multibody
code perform a couple of dummy resolution loops just the determine the,
already available, initial set up and linking, thus ensuring that all
parts of the code where run and thus all data allocated before locking
it all into memory. Fortunately the code does not keep deleting/creating
objects.

Paolo.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.