single_lwr_example not running Action server

[kjyv]

Following the Readme for simple_lwr_example, I start roslaunch single_lwr_launch single_lwr.launch load_moveit:=true While this opens up gazebo, rviz and moveit and I can plan trajectories, executing results in `

MoveitSimpleControllerManager: Action client not connected: /lwr/joint_trajectory_controller/follow_joint_trajectory

Apparently, it is necessary to answer to the joint messages with an Action server which is provided by lwr_hw for real hardware or as a gazebo plugin. However, compiling it, adding the plugin to the world file for gazebo is not documented and took me a bit (sorry, new to ROS). Also, I don't see how switching between simulation or hardware is done only with the flags as described.

[carlosjoserg]

Hi @kjyv sorry for the slow response.

Yep, sorry for the poor documentation, that example assumes some basics of ROS, ros-controls, and MoveIt!, among other things.

Apparently, it is necessary to answer to the joint messages with an Action server which is provided by lwr_hw for real hardware or as a gazebo plugin. However, compiling it, adding the plugin to the world file for gazebo is not documented and took me a bit (sorry, new to ROS).

I don't fully understand what you mean, the example should work out-of-the-box, but of course compilation is necessary. Adding the plugin in the world file shouldn't be necessary, since the gazebo_ros spawner is used, and the plugin is already part of the urdf here.

Also, I don't see how switching between simulation or hardware is done only with the flags as described.

If you type roslaunch single_lwr_launch single_lwr.launch --ros-args you will see all the args that you can set. Among them, you have the use_lwr_sim. This is a true/false flag that either loads gazebo and spawn the lwr model (default behavior), or launch a node that interfaces with the real arm, for which you would need to run a KRL script.

Nevertheless, this example is meant to be a guide to write your own launch and configuration files and not using it directly, since your setup could be different that the robot mounted on a box. The good thing is that you shouldn't need to write a single line of C++ for most applications.

[kjyv]

Thanks for your answer. I have not used ROS before, so that may or may not be part of the issue. I'm not sure if I missed something on my part, but I've opened the ticket because I had to tinker a bit before getting it to work after following the Readme and it included adding the plugin to the simple_environment.world file. Before I did that, the following error can be seen:

[ERROR] [1459956917.137989837, 15.001000000]: MoveitSimpleControllerManager: Action client not connected: /lwr/joint_trajectory_controller/follow_joint_trajectory

and henceforth, the joint_trajectory_controller is not loaded and no trajectories are executed.

I can see that in the gazebo section in the kuka_lwr.gazebo.xacro file, the plugin is being included, but it doesn't seem to load up the ActionServer this way. Though I get the message "Finished loading Gazebo ROS API Plugin.", not sure if that is this plugin or another. Maybe I didn't build it the right way so it simply wasn't found in the right location. That could be added to the Readme.

Even though you might mean it to be a starting point, I'd say an example should still run on it's own so it is then possible to customize it. Also the Readme explains how to run it, so I guess it should be possible to do so without other things. But to be honest, it is also pretty much my setup - the arm mounted upwards on a table, so I don't really need to customize anything.

About switching between hardware and simulation, I was referring to the fact that there are two plugins - liblwr_hw.so and liblwr_hw_gazebo_plugin.so - which seemed to relate to hardware and gazebo robots. In the URDF, I didn't see them being loaded depending on the flag, but it seems that liblwr_hw is really a lib for the nodes and no separate plugin.

[kjyv]

Ok, yes. The change in the world file is not necessary if the paths are right. Basically, the information I was missing is that after compiling, there should be a directory lwr_hw/lib which in my case was under build/devel. The same applies for lwr_controllers/lib. Standard mkdir build, cmake .., make and then symlinking it could maybe be added to the Readme of lwr_controllers / lwr_hw and I guess then this ticket can be closed ;)

[carlosjoserg]

I think building with plain catkin this is not an issue.

If you are using a different building method and want to share it by adding it to the Readme, you are welcome!