Compilation error etc

[n3opl4n]

At first I would like to congratulate you for your work. The guide help me setup successfully (I believe) the rtnet over xenomai 2.6.4. However I bumped into some problems like

• In the CMakeList.txt there are some non-existent files (fridualseq_rt.cpp) which I had to remove in order to compile
• After "cmake ." and during building I got some errors that signal() and SIGXCPU are undefined. After some googling I added "#include <signal.h>" at some source files and the build was successful. Was this addition correct?
• Finally I tried running some firstAppRT and friTestRT without success. I get the following result for friFirstAppRT (the robot was with FRIOpen and was waiting for perfect quality for command mode, the pc IP is 192.168.0.10 and the robot IP 192.168.0.1):

Opening FRI Version 1.0.4101.8198 Interface for First Sample
cannot open log pipe
Press [Enter] to exit.
WARNING: Switched out of RealTime. Stack-trace in syslog.
preinitialized server adress to 192.168.0.10
preinitialized remote host to 192.168.0.1 and port 4803
friRemote 49938
FRI Version 1.0.4101.8198

The nonRT applications seem to work fine though.
My configuration is: Xubuntu 12.04, Kernel: 3.8.13-xenomai-2.6.4, RTadapter: Realtek 8139

Fotis

[jbohg]

Hi Fotis, thanks very much for the feedback . I'll look into it during this week and come back to you asap.

Jeannette

[n3opl4n]

For the SIGXCPU error I had to include "signal.h". As for the friSecondAppRT it did run correctly. I made a fork and did some changes there, that work in our configuration with Xenomai 2.6.4

[jbohg]

Hi Fotis,
I added #include <signal.h> in friSecondAppRT and it compiles just fine. So, I can add this to be forward compatible with your newer kernel and xenomai. I was just wondering about one thing: Did you not have to add this header to the other executables that contain SIGXCPU?

This code has been tested only for our configuration, i.e. older kernel, older xenomai etc. So it is great that you check what needs to be adapted o make it work with the newer version. We are also planning to upgrade soon. Would you like to be added as a collaborator instead of maintaining a fork? Then you can make a new branch for your setup and I can test it on our side to see if it can be merged back into master bit by bit.

You mentioned in your first post that firstAppRT and friTestRT weren't working. But friSecondAppRT is functioning now?

My configuration is : Ubuntu 12.04, Kernel : 2.6.35, xenomai 2.5.as described in the Readme

[jbohg]

BTW, I also added the fridualseq_rt.cpp

[jbohg]

I double-checked now all the executables in this project. There was indeed a bug in firstAppRT and I fixed it. But what already should have been correctly working was friTestRT. The only thing this code does is to send back the received packages within the required millisecond. And the FRI on the ARM should switch into CMD mode.

If I understand you correctly,friSecondAppRT did run correctly? Then it is strange that the much simpler program friTestRT did not.

I didn't test friSecondAppRT myself yet.

I have one recommendation for monitoring the packages that go through thertnet interface. Use wireshark if you are not already doing that

sudo apt-get install wireshark

This helped me tremendously to debug this.

[n3opl4n]

I didn't check all the applications to see if they work. But I did have to include "signal.h" to get them compiled. I guess the friTestRT worked fine just like the friSecondAppRT, but in the latter I could verify that the joints were moving with a sinusoidal motion.

I don't really have any additions to make, your code was really helpful to me in order to get my apps working with Xenomai. With xenomai 2.6.4 I thing that you no longer have to add "mlockall(MCL_CURRENT | MCL_FUTURE);" because it does that automatically. However, I didn't remove it and it still works fine.

Finally, when I use the logpipes to monitor the robot variables at a non-real-time loop, I see that the quality switches between 2 (OK) and 3 (Perfect) without any noticeable effect on the operation of the robot. I will give a try to wireshark as you suggest, maybe it has something to do with my ethernet adapter. For example, when I run rtping I get an average value of 0.5ms. I am not sure if this could get any better.
At least I don't get the real-time loop to switch to secondary mode because of delays.

Fotis

[jbohg]

Hi again Fotis,

really helpful to know that this code also works with xenomai 2.6.4. I will
in that case add signal.h wherever SIGXCPU is used. I will also add a
comment above mlockall(MCL_CURRENT | MCL_FUTURE); to clarify that it is
optional for 2.6.4.

The FRI on the arms stays in command mode until two packages get lost in a
row. In that case, it switches to monitor modes and the brakes are
activated. Switching quality to OK should happen, because once in a while a
package gets lost. But the next package should be in time then otherwise
the FRI goes to Monitor mode.

It is strange though that this happens. I can run rtping on my side as well
to see what the average value is for our case. I will also run the sample
program with the logpipe to check if we also have these quality switches.
It is a while ago that I have done that. And I don't remember the result
now.

Jeannette

On Sun, Nov 9, 2014 at 1:47 PM, n3opl4n notifications@github.com wrote:

I didn't check all the applications to see if they work. But I did have to
include "signal.h" to get them compiled. I guess the friTestRT worked fine
just like the friSecondAppRT, but in the latter I could verify that the
joints were moving with a sinusoidal motion.

I don't really have any additions to make, your code was really helpful to
me in order to get my apps working with Xenomai. With xenomai 2.6.4 I thing
that you no longer have to add "mlockall(MCL_CURRENT | MCL_FUTURE);"
because it does that automatically. However, I didn't remove it and it
still works fine.

Finally, when I use the logpipes to monitor the robot variables at a
non-real-time loop, I see that the quality switches between 2 (OK) and 3
(Perfect) without any noticeable effect on the operation of the robot. I
will give a try to wireshark as you suggest, maybe it has something to do
with my ethernet adapter. For example, when I run rtping I get an average
value of 0.5ms. I am not sure if this could get any better.
At least I don't get the real-time loop to switch to secondary mode
because of delays.

Fotis

—
Reply to this email directly or view it on GitHub
#1 (comment).