[Rock-dev] Scheduler warning and realtime

Pierre Letier pierre.letier at spaceapplications.com
Thu Nov 8 16:28:01 CET 2012


Le 11/8/2012 4:09 PM, Sylvain Joyeux a écrit :
> On 11/08/2012 03:27 PM, Pierre Letier wrote:
>> I succeeded to build an application based on Orogen. It is currently 
>> working on a xubuntu 12.04. The application is running correctly but 
>> when I start it, I receive the following warning:
>>
>> 0.037 [ Warning][Thread] Lowering scheduler type to SCHED_OTHER for 
>> non-privileged users..
>> 0.037 [ Warning][Activity] Lowering scheduler type to SCHED_OTHER for 
>> non-privileged users..
>> Based on a google reserach, I found the following answer on the 
>> Orocos mailing list:
>> http://www.orocos.org/node/1089
>>
>> In summary I need to change my user ulimit to use the real-time 
>> scheduler as a non-priveleged user. This solution works (I don't have 
>> anymore the warning). However, I don't know where, in my Orogen 
>> development, I specify that I want to use the real time sheduler. I 
>> don't define any realtime parameter in the deployment (I use the 
>> "automatic" deployment approach) or any priority. I was thinking that 
>> I was automatically in SCHED_OTHER from OROCOS point of view. Do you 
>> have any idea about that ?
> In theory, if you don't add the .realtime tag to the deployed task, 
> the warning should not appear. I thought I fixed it a while back. RTT 
> spawns some threads (for isolating CORBA from the task context for 
> instance), and I thought I made sure they would be spawned with the 
> same scheduler than the task ... Will have to check that.
>> In the future, I would like to port the component in realtime, using 
>> XENOMAI. For that I have the following questions:
>>
>> - Any suggestion/advices about the installation/configuration of 
>> XUBUNTU/XENOMAI/Orogen (e.g. kernel configuration). Is there specific 
>> thinks to do with orogen ?
> In theory, there is nothing special to do with oroGen. In practice, we 
> have not done any Xenomai work in ages, so I don't really know. We 
> moved to using Linux with the RT patchset, which gives good RT 
> performance without the Xenomai caveats (i.e. the normal linux-based 
> monitoring / debugging tools work out of the box)
Interesting, do you have any documentation / link to do that (I am note 
linked to XENOMAI) (see last question).
>
>> - How the orogen codes/component have to be modified/updated to make 
>> them working in the realtime environement (modification of CMAKE ?)
> orogen should be called with the --target=xenomai flag and RTT should 
> be compiled for both xenomai and gnulinux.
>
> The orogen parameter is historical in nature and we should probably 
> make it completely configurable when calling CMake (i.e. cmake 
> -DOROCOS_TARGET=xenomai). Automatically compiling the two 
> configurations for RTT using autoproj is not supported either ... I 
> should have a look at that, since it is also required by 
> cross-compilation setups.
>> - How the GUI UI have to be managed if developped on the same 
>> computer ? (of course not realtime)
> I don't really understand that question ...
I use the Ruby script to call and configure/connect some graphical user 
interface (control buttons, status, plots....). If I use the deployer to 
specify the realtime behavior of some tasks, may I have issues with the 
graphical rendering (I understand it will depend on what I do with the 
realtime tasks) or could the graphical rendering be a problem for the tasks
>> - is there any documentation/tutorial about developping orogen 
>> components on realtime platforms (like Xenomai)
> There was not, but now there is. I quickly wrote this without testing, 
> so it might not be as accurate as one might like ;-)
>
>    https://rock.opendfki.de/wiki/WikiStart/Toolchain/RTPlatforms
>
The link is password protected.

Thank you

-- 
Pierre Letier
Robotics Engineer

25 Years in Space!
1987 - 2012

Space Applications Services NV/SA
Leuvensesteenweg 325, 1932 Zaventem, Belgium
Phone: +32 (0)2-416.05.04
Fax: +32 (0)2-721.54.44
www.spaceapplications.com



More information about the Rock-dev mailing list