Real time kernel unable to setup sched_FIFO

[shuobh]

Summary

We have followed the tutorial but the robot still reports an error saying Scheduling is NOT SCHED_FIFO, same as the issue mentioned in sched_FIFO.

Versions

• ROS Driver version: 2.1.2
• Affected Robot Software Version(s): 5
• Affected Robot Hardware Version(s): UR3e
• URCaps Software version(s): 5.11.1

Impact

Impact rt performance

Issue details

The tutorial pointed out the importance of setting the driver thread to sched_FIFO to guarantee real-time performance, but by following the tutorial, we failed to do so. Setting the priority returns "Operation not permitted" which seems to be a permission issue.

Project status at point of discovered

In normal use

Steps to Reproduce

1. Follow the tutorial to install real time kernel and setup privileges to use real-time scheduling.
2. Run the driver code with a real robot and the driver node will report the error. I've pasted my setup below.

   infinity@nuc-41-robot-35:~$ id -Gn
   infinity adm cdrom sudo audio dip plugdev lpadmin pulse pulse-access lxd sambashare realtime

   
   infinity@nuc-41-robot-35:~$ cat /etc/security/limits.conf
   # /etc/security/limits.conf
   #
   #Each line describes a limit for a user in the form:
   #
   #<domain>        <type>  <item>  <value>
   #
   #Where:
   #<domain> can be:
   #        - a user name
   #        - a group name, with @group syntax
   #        - the wildcard *, for default entry
   #        - the wildcard %, can be also used with %group syntax,
   #                 for maxlogin limit
   #        - NOTE: group and wildcard limits are not applied to root.
   #          To apply a limit to the root user, <domain> must be
   #          the literal username root.
   #
   #<type> can have the two values:
   #        - "soft" for enforcing the soft limits
   #        - "hard" for enforcing hard limits
   #
   #<item> can be one of the following:
   #        - core - limits the core file size (KB)
   #        - data - max data size (KB)
   #        - fsize - maximum filesize (KB)
   #        - memlock - max locked-in-memory address space (KB)
   #        - nofile - max number of open file descriptors
   #        - rss - max resident set size (KB)
   #        - stack - max stack size (KB)
   #        - cpu - max CPU time (MIN)
   #        - nproc - max number of processes
   #        - as - address space limit (KB)
   #        - maxlogins - max number of logins for this user
   #        - maxsyslogins - max number of logins on the system
   #        - priority - the priority to run user process with
   #        - locks - max number of file locks the user can hold
   #        - sigpending - max number of pending signals
   #        - msgqueue - max memory used by POSIX message queues (bytes)
   #        - nice - max nice priority allowed to raise to values: [-20, 19]
   #        - rtprio - max realtime priority
   #        - chroot - change root to directory (Debian-specific)
   #
   #<domain>      <type>  <item>         <value>
   #

* soft core 0

root hard core 100000

* hard rss 10000

@student hard nproc 20

@faculty soft nproc 20

@faculty hard nproc 50

ftp hard nproc 0

ftp - chroot /ftp

@student - maxlogins 4

@realtime soft rtprio 99 @realtime soft priority 99 @realtime soft memlock 102400 @realtime hard rtprio 99 @realtime hard priority 99 @realtime hard memlock 102400

End of file

[shuobh]

We found the issue. Our driver is running as a part of service on init startup which /etc/security/limits.conf is not yet applied. The solution is to add ulimit -HS -r 99 -e 99 -l 102400 to your service script