"RttLwrOSFController" could not be found
Closed this issue · 9 comments
Today we tried to reproduce the system as described here: http://cogimon.github.io/software/gettingstarted.html
The GZ Server, however, reported the following error. We were using Ubuntu Trusty and Gazebo 6.5 from Ubuntu Packages.
Log >>
[Wrn] [ColladaLoader.cc:1761] Triangle input semantic: 'COLOR' is currently not supported Found model kuka-lwr! 35.040 [ Warning][GazeboDeployerWorldPlugin::load] Model has 8 joints 35.040 [ Warning][GazeboDeployerWorldPlugin::load] Not adding (fake) fixed joint [arm_world_joint] idx:0 35.040 [ Warning][GazeboDeployerWorldPlugin::load] Adding joint [lwr_arm_0_joint] idx:1 Adding joint [lwr_arm_0_joint] idx:1 35.040 [ Warning][GazeboDeployerWorldPlugin::load] Adding joint [lwr_arm_1_joint] idx:2 Adding joint [lwr_arm_1_joint] idx:2 35.040 [ Warning][GazeboDeployerWorldPlugin::load] Adding joint [lwr_arm_2_joint] idx:3 Adding joint [lwr_arm_2_joint] idx:3 35.040 [ Warning][GazeboDeployerWorldPlugin::load] Adding joint [lwr_arm_3_joint] idx:4 Adding joint [lwr_arm_3_joint] idx:4 35.040 [ Warning][GazeboDeployerWorldPlugin::load] Adding joint [lwr_arm_4_joint] idx:5 Adding joint [lwr_arm_4_joint] idx:5 35.040 [ Warning][GazeboDeployerWorldPlugin::load] Adding joint [lwr_arm_5_joint] idx:6 Adding joint [lwr_arm_5_joint] idx:6 35.040 [ Warning][GazeboDeployerWorldPlugin::load] Adding joint [lwr_arm_6_joint] idx:7 Adding joint [lwr_arm_6_joint] idx:7 35.040 [ Warning][GazeboDeployerWorldPlugin::load] Gazebo model found 7 joints 35.041 [ Warning][GazeboDeployerWorldPlugin::load] Done configuring gazebo 35.080 [ Warning][Thread] Lowering scheduler type to SCHED_OTHER for non-privileged users.. 35.080 [ Warning][Thread] Forcing priority (99) of thread with SCHED_OTHER policy to 0. 35.080 [ Warning][lwr_gazebo] Lowering scheduler type to SCHED_OTHER for non-privileged users.. 35.081 [ ERROR ][loadComponent] Unable to create Orocos Component 'RttLwrOSFController': unknown component type. 35.082 [ ERROR ][ScriptingService] eval() :Parse error at line 18: Service or Task "gazebo" has no Peer or Service lwr_osf_controller (or gazebo was not found at all). [Err] [rtt_gazebo_deployer_world_plugin.cpp:730] Could not run ops script from file /homes/fl/local_data/fl/repro_systems/cogimon-minimal-lwr-nightly/etc/cogimon-scenarios/scenario-wipe-board/script/scn-wipe-board-short.ops! Connect to Gazebo Update Loop 85.999 [ Warning][GazeboDeployerModelPlugin::gazeboUpdate] Time went backwards by -0.999 seconds! (85999000000 --> 85000000000) Found model kuka-lwr! 293.675 [ ERROR ][loadComponent] Failed to load component with name lwr_gazebo: already present as peer or loaded. [Err] [rtt_gazebo_deployer_world_plugin.cpp:480] Could not load rtt_gazebo model component: "LWRGazeboComponent" Could not load rtt_gazebo model component: "LWRGazeboComponent" 433.999 [ Warning][GazeboDeployerModelPlugin::gazeboUpdate] Time went backwards by -0.999 seconds! (433999000000 --> 433000000000)
My first guess would be that either the rtt-lwr-osf-controller is not cloned into your setup, or that the shared object is not included in the RTT_COMPONENT_PATH, i.e., export RTT_COMPONENT_PATH=$RTT_COMPONENT_PATH:$(path-to-)/rtt-lwr-osf-controller/build/src/orocos, or both.
I am pretty sure it is in there. Could you try to replicate the distribution?
You will need the latest build gen for that.
Thanks!
You're right, it's in there. So that seems to be fine. Could you please show me the content of RTT_COMPONENT_PATH before starting the gzserver?
I think I've found the issue: In the distribution there was an old project used that - with regards to the name - creates exactly the same lib-file. I guess depending on the build order of jenkins, it can happen that you end up with the deprecated lib-file that does not contain RttLwrOSFController. I removed the old entry from the distribution and pushed it.
Just for clarification: Was that the template project or something else?
Yes exactly, that was only the template project for a controller.
diff --git a/distributions/cogimon-minimal-lwr-nightly.distribution b/distributions/cogimon-minimal-lwr-nightly.distribution
index c5dd1c8..3a66fc2 100644
@@ -157,10 +157,6 @@
"master"
],
[
- "rtt-lwr-controller-template",
- "master"
- ],
- [
"rtt-lwr-osf-controller",
"RY1.0.0"
],
Shouldn't then the template project generate a differently named shared library? Clearly stating its template purpose... But that should probably be an issue for the corresponding template project.
@warp1337 Could you test the distribution again after this change?
That's totally true. It's just due to the fact that the osf-controller emerged from this template, and no one bothered to change the name in the CMake file accordingly. But in general the template shouldn't be included in the distribution at all.
Edit: Changed lib name of the template to RTTControllerTemplate. It shouldn't interfere any more. See https://github.com/corlab/rtt-lwr-controller-template/commit/04305b371d6e37cdbb3ce82e25176b0c54d2db8a
Since the problem is resolved by the adapted distribution file, I am going to close this issue!