Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

add xenomai 3 support with xenomai 2 compatibility #301

Closed

Conversation

ahoarau
Copy link
Contributor

@ahoarau ahoarau commented Jun 14, 2019

Hopefully the latest version before merging.
This contains #245 + resetting the variables on the FindXenomai.cmake.
I rebased the changes from the latest commit of toolchain-2.9.

It builds with xenomai 2.6.5 and xenomai 3 (from the git repo, 3.1-devel)

@ahoarau
Copy link
Contributor Author

ahoarau commented Jun 14, 2019

@meyerj I believe many tests are failing because of timeouts.
If I run catkin test rtt -i -v:

[rtt:make]       Start  4: task-test                                                                                                                                                                         
[rtt:make]  4/40 Test  #4: task-test ........................***Failed   25.54 sec    

But If I go to the build directory and run the test manually:

$ ./task-test
WARNING: You are not root. This program *may* require that you are root.
Running 27 test cases...

*** No errors detected

But right after I run it again:

$ ./task-test
WARNING: You are not root. This program *may* require that you are root.
Running 27 test cases...
rtt/tests/taskthread_fd_test.cpp(269): error: in "ActivitiesThreadTestSuite/testFileDescriptor_Timeout": check 4 == mcomp.countTimeout has failed [4 != 0]
rtt/tests/taskthread_fd_test.cpp(279): error: in "ActivitiesThreadTestSuite/testFileDescriptor_Timeout": check 5 == mcomp.countTimeout has failed [5 != 1]
rtt/tests/taskthread_fd_test.cpp(286): error: in "ActivitiesThreadTestSuite/testFileDescriptor_Timeout": check 5 + 3 == mcomp.countTimeout has failed [8 != 4]

*** 3 failures are detected in the test module "Master Test Suite"

buffers_test causes the system to hang immediately. But the stream in a ROS topic is working..

@ahoarau
Copy link
Contributor Author

ahoarau commented Jun 25, 2019

Here's the simplest Dockerfile to test different versions:

ARG ROS_DISTRO=melodic
ARG BASE_IMAGE=amd64/ros:${ROS_DISTRO}-ros-base
FROM ${BASE_IMAGE}

ARG XENOMAI_VERSION=3.0.8


RUN apt-get update --fix-missing
RUN apt-get install -y libboost-all-dev wget curl cmake
RUN curl -L https://xenomai.org/downloads/xenomai/stable/xenomai-${XENOMAI_VERSION}.tar.bz2 | tar -xj
WORKDIR xenomai-${XENOMAI_VERSION}
RUN ./configure --with-pic --with-core=cobalt --enable-smp --disable-tls --enable-dlopen-libs --prefix=/usr/xenomai-$
{XENOMAI_VERSION}
RUN make -j$(nproc) && make install
ENV XENOMAI_ROOT_DIR=/usr/xenomai-${XENOMAI_VERSION}
ENV PATH=$XENOMAI_ROOT_DIR/bin:$XENOMAI_ROOT_DIR/sbin:$PATH
ENV PKG_CONFIG_PATH=$XENOMAI_ROOT_DIR/lib/pkgconfig:$PKG_CONFIG_PATH
ENV LD_LIBRARY_PATH=$XENOMAI_ROOT_DIR/lib:$LD_LIBRARY_PATH

ENV OROCOS_TARGET=xenomai

WORKDIR /rtt_ws/src
RUN curl -L https://github.com/ahoarau/rtt/archive/xenomai3-support-v3.tar.gz  | tar -xz
RUN curl -L https://github.com/orocos-toolchain/log4cpp/archive/toolchain-2.9.tar.gz  | tar -xz
RUN curl -L https://github.com/orocos-toolchain/ocl/archive/toolchain-2.9.tar.gz  | tar -xz
RUN curl -L https://github.com/ahoarau/rtt_ros_integration/archive/xenomai3-support-v3.tar.gz  | tar -xz
WORKDIR /rtt_ws
RUN . /opt/ros/${ROS_DISTRO}/setup.sh && rosdep install --from-path src/ -i -r -y
RUN . /opt/ros/${ROS_DISTRO}/setup.sh && catkin_make_isolated --install -DCMAKE_BUILD_TYPE=Release

To test :

docker build --build-arg XENOMAI_VERSION=3.0.8 --build-arg ROS_DISTRO=melodic . 
docker build --build-arg XENOMAI_VERSION=2.6.5 --build-arg ROS_DISTRO=kinetic  . 

@ahoarau
Copy link
Contributor Author

ahoarau commented Jul 5, 2019

With this commit I fixed the xenomai task names called "Task@1 ." in /proc/xenomai/sched/stat 0b8e411

Here's the output of just loading and setting an activity to a component :

Deployer [S]> loadComponent("a","TaskContext")
4.513 [ Info   ][Thread] Creating Thread for scheduler=ORO_SCHED_OTHER, priority=1, CPU affinity=0, with name='GlobalEngine'
4.513 [ Debug  ][Thread] Raizing default stack size to 128kb for Xenomai threads in Orocos.
4.514 [ Debug  ][Thread] Spawned Xenomai task 'GlobalEngine'
    sched_type   ORO_SCHED_OTHER
    stack_size   128000
    priority     0
    cpu_affinity 0

4.518 [ Info   ][GlobalEngine] Thread created with scheduler type 'ORO_SCHED_OTHER', priority 0, cpu affinity 0 and period 0 (PID= 12386 ).
4.518 [ Debug  ][loadComponent] Trying to create component a of type TaskContext
4.518 [ Debug  ][loadComponent] Found factory for Component type TaskContext
4.518 [ Info   ][Thread] Creating Thread for scheduler=ORO_SCHED_OTHER, priority=1, CPU affinity=0, with name='a'
4.518 [ Debug  ][Thread] Raizing default stack size to 128kb for Xenomai threads in Orocos.
4.518 [ Debug  ][Thread] Spawned Xenomai task 'a'
    sched_type   ORO_SCHED_OTHER
    stack_size   128000
    priority     0
    cpu_affinity 0

4.522 [ Info   ][a] Thread created with scheduler type 'ORO_SCHED_OTHER', priority 0, cpu affinity 0 and period 0 (PID= 12387 ).
4.523 [ Info   ][loadComponent] Adding a as new peer:  OK.
 = true                

Deployer [S]> setActivity("a",0.1,10,ORO_SCHED_RT)
344.443 [ Info   ][Thread] Creating Thread for scheduler=ORO_SCHED_RT, priority=10, CPU affinity=4294967295, with name='a'
344.443 [ Debug  ][Thread] Raizing default stack size to 128kb for Xenomai threads in Orocos.
344.443 [ Debug  ][a1] Spawned Xenomai task 'a1'
    sched_type   ORO_SCHED_RT
    stack_size   128000
    priority     10
    cpu_affinity 4294967295

344.448 [ Info   ][a1] Thread created with scheduler type 'ORO_SCHED_RT', priority 10, cpu affinity 7 and period 0.1 (PID= 12486 ).
344.448 [ Debug  ][Thread] Terminating a
344.448 [ Debug  ][Thread]  done
 = true                

@meyerj

  1. Why loading "a" creates a non-rt thread that gets terminated once we set an activity ot it ?
  2. Shouldn't the activity thread name be called <task_name>_Activity or something ?

os::MutexLock lock(msg_lock);
#endif
msg_cond.broadcast(); // required for waitForFunctions() (3rd party thread)
}
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like this one ? #304

@ahoarau
Copy link
Contributor Author

ahoarau commented Nov 18, 2019

@meyerj Any news on this PR ?

@ahoarau ahoarau closed this Feb 9, 2021
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant