search

jbohg / kuka_lwr_rtnet

Xenomai and RTNet Interface for Kuka LBR IV Arms
16 stars 6 forks source link

Compilation error etc #1

Open n3opl4n opened 10 years ago

n3opl4n commented 10 years ago

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

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 commented 10 years ago

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

Jeannette

n3opl4n commented 10 years ago

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 commented 10 years ago

Hi Fotis, I added #include 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 commented 10 years ago

BTW, I also added the fridualseq_rt.cpp

jbohg commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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 https://github.com/jbohg/kuka_lwr_rtnet/issues/1#issuecomment-62302253.