Xenomai and RTnet configured for Ubuntu 12.04 hydro not able to send trajectory msgs

hi, script does not pass this FriQuality and FriState wait for ($FriQuality==#PERFECT) wait for ($FriState==#CMD)

**how to succeed in this?

Once i uncomment the above After effects of uncommenting ; wait for ($FriQuality==#PERFECT) ; wait for ($FriState==#CMD)

I am using this kuka_lwr pack to work with moveit. unfortunately no execution in real time occurs

Using T1 mode

The .src and .dat is loaded in krc according to the instruction and the program gets it to fri remote loop

Display::----------------------------------------------------------- preinitialized remote host to 192.168.0.20 IP 127.0.1.1 - Port 49938 friRemote 49938 FRI Version 1.0.4101.8198 [ INFO] [1437406588.740566841]: Handling joint: lwr_0_joint [ INFO] [1437406588.740808771]: Handling joint: lwr_1_joint [ INFO] [1437406588.740884619]: Handling joint: lwr_2_joint [ INFO] [1437406588.740943635]: Handling joint: lwr_3_joint [ INFO] [1437406588.741000486]: Handling joint: lwr_4_joint [ INFO] [1437406588.741066835]: Handling joint: lwr_5_joint [ INFO] [1437406588.741123756]: Handling joint: lwr_6_joint [ INFO] [1437406588.741184099]: Register state and effort interfaces Opening FRI Version 1.0.4101.8198 Interface for LWR ROS server [ INFO] [1437406588.741271261]: Performing handshake to KRL [ INFO] [1437406588.741330905]: LWR Status: timestamp 0 state 0 quality 0 desiredMsrSampleTime 0 desiredCmdSampleTiintfme 0 safetyLimits 0 statistics answerRate 0 latency 0 jitter 0 missRate 0 missCounter 0

[ INFO] [1437406588.742782487]: Done handshake ! Display::-----------------------------------------------------------XXX

This shows the data exchange is made..

launch roslaunch single_lwr_launch kuka_lwr.launch use_lwr_sim:=false lwr_powered:=true load_moveit:=true

Display::----------------------------------------------------------- [ INFO] [1437407627.058239322]: MoveitSimpleControllerManager: Added FollowJointTrajectory controller for /lwr/joint_trajectory_controller [ INFO] [1437407627.058367551]: Returned 1 controllers in list [ INFO] [1437407627.069346884]: Trajectory execution is managing controllers Display::-----------------------------------------------------------XXX

the joint trajectory controller is activated and client establish its connection

**when started the moveit the current state of real KUKA is exactly shown in rviz (the aligned model)

i use interactive markers to move the arm ( rviz motion planning tool ) and the moveit gives out the plan succesfully but no real execution is performed Display::----------------------------------------------------------- [ INFO] [1437408505.743505954]: Solution found in 0.064542 seconds [ INFO] [1437408505.785797789]: Path simplification took 0.042185 seconds [ INFO] [1437408508.011552332]: Received new trajectory execution service request... [ WARN] [1437408508.011989050]: Dropping first 1 trajectory point(s) out of 27, as they occur before the current time. First valid point will be reached in 0.508s. [ INFO] [1437408511.862701076]: Execution completed: SUCCEEDED Display::-----------------------------------------------------------XXX

the console shows execution is made. unfortunately nothing happens in the real hardware. how the initial states is published but no data transmit or receive happens lately? can i use this pack with gnulinux without realtime app (xenamai and RTnet). is anyone faced this kind of issue. it seems in krc: and remote host:: things works fine loading the script and launching moveit..up to generation of plan...

thanks

Hi @radioactive1014

If the script does not pass the steps of wait for ($FriQuality==#PERFECT) wait for ($FriState==#CMD) the robot will never move.

If you comment that, yes, the node will continue because it does not check for the same thing, and start the controller manager, and you are able to connect to the controller, there is actually communication with the robot because it is in Monitor mode, that's why you see the robot in RViz in the correct configuration. This part is fixed in the next PR #42.

The only things I can think of are related to the network:

Do you have more devices connected to the same network: Could you describe your setup?

What order are you following: First the script and then the node, or the other?

At least me, never tested on Hydro 12.04 and xenomai and RTnet. For the OS, I don't think there should be a problem, there is nothing fancy in the package, standard ROS control. About xenomai and RTnet I can't tell, I know what they are, but don't even know how to configure them.

can i use this pack with gnulinux without realtime

Yes, that is the main reason why I started it, because I didn't want to have extra configurations to use the robot, just install ROS, download, compile and use.

If you don't need to do real-time control, you can use the package as it is.

@radioactive1014 according to our email conversation:

You were using an Intel core i5 hp elitebook laptop. And every time you clicked in RVIZ, the KRC unit complained about bad communication quality and stopped communication.

My guessed was that there was not enough PC capacity to handle everything with the laptop.

The expected communication rate is configured in the KRL script here.

Changing that to 10msec instead of 2 solved the problem.

@carlosjoserg wrote:

You were using an Intel core i5 hp elitebook laptop. And every time you clicked in RVIZ, the KRC unit complained about bad communication quality and stopped communication.

My guessed was that there was not enough PC capacity to handle everything with the laptop.

Running any kind of (accelerated) 3D application on a Xenomai patched kernel is a tricky business. Graphics drivers are often not written with real-time systems in mind and tend to make use of features of the kernel that block heavily, or call into firmware routines that cannot be pre-empted (not even by the Adeos hypervisor).

The Xenomai mailing list receives many questions about even getting a relatively 'simple' (it isn't obviously) and open-source driver as the Intel GMA/HDx drivers working. I'm not surprised that an Elitebook (probably with an Nvidia or AMD video card) would exhibit these issues.

Note that this is not directly related to the performance of the computer involved: higher specced machines can probably mask the issue better as they can 'catch up' quicker, but the fundamental issue is still there.

Changing that to 10msec instead of 2 solved the problem.

This obviously depends on your requirements, but I'd say that this is really a work-around. Getting your real-time system setup properly would have been a solution.

Thanks for that input that explains better the issue.

I agree, it is a work-around, specially because I run this at 2msec (the switch still not with kuka fri) in a good PC without xenomai.

My other suggested quick-fix was to use 1 dedicated PC for controllers and hardware, and N for the rest. On Jul 30, 2015 8:46 AM, "G.A. vd. Hoorn" notifications@github.com wrote:

@carlosjoserg https://github.com/carlosjoserg wrote:

You were using an Intel core i5 hp elitebook laptop. And every time you clicked in RVIZ, the KRC unit complained about bad communication quality and stopped communication.

My guessed was that there was not enough PC capacity to handle everything with the laptop.

Running any kind of (accelerated) 3D application on a Xenomai patched kernel is a tricky business. Graphics drivers are often not written with real-time systems in mind and tend to make use of features of the kernel that block heavily, or call into firmware routines that cannot be pre-empted (not even by the Adeos hypervisor).

The Xenomai mailing list receives many questions about even getting a relatively 'simple' (it isn't obviously) and open-source driver as the Intel GMA/HDx drivers. I'm not surprised that an Elitebook (probably with an Nvidia or AMD video card) would exhibit these issues.

Note that this is not directly related to the performance of the computer involved: higher specced machines can probably mask the issue better as they can 'catch up' quicker, but the fundamental issue is still there.

Changing that to 10msec instead of 2 solved the problem.

This obviously depends on your requirements, but I'd say that this is really a work-around. Getting your real-time system setup properly would have been a solution.

— Reply to this email directly or view it on GitHub https://github.com/CentroEPiaggio/kuka-lwr/issues/43#issuecomment-126203284 .

CentroEPiaggio / kuka-lwr