path planning and execution with a real robot arm

[Quantao Yang]

Hi all,
i need to do kinematic planning and execution with my schunk 7 dof arm. I just followed the moveit setup assistant and i can do some planning in the RVIZ perfectly, everything seems fine. Now i want to do planning and execution with the real arm in our lab. So i go on with these tutorials: Create a MoveIt Package for an Industrial Robot and controller_configuration. But when i test using this command roslaunch schunk_moveit_config moveit_planning_execution.launch, I get some errors like:
[ INFO] [1404732436.690900864]: Loading robot model 'schunk'...
[ INFO] [1404732437.444701819]: Loading robot model 'schunk'...
[ INFO] [1404732437.522727873]: MoveitSimpleControllerManager: Waiting for arm_controller/joint_trajectory_action to come up
[ WARN] [1404732437.773476170]: The root link base_link has an inertia specified in the URDF, but KDL does not support a root link with an inertia.  As a workaround, you can add an extra dummy link to your URDF.
[ INFO] [1404732437.957020739]: Starting scene monitor
[ INFO] [1404732437.961134461]: Listening to '/move_group/monitored_planning_scene'
[ERROR] [1404732437.963374340]: Failed to call service /get_planning_scene at /tmp/buildd/ros-hydro-moveit-ros-planning-0.5.16-0precise-20140527-1656/planning_scene_monitor/src/planning_scene_monitor.cpp:431
[ WARN] [1404732438.468215354]: The root link base_link has an inertia specified in the URDF, but KDL does not support a root link with an inertia.  As a workaround, you can add an extra dummy link to your URDF.
[ INFO] [1404732438.481723706]: Constructing new MoveGroup connection for group 'lwa'
[ INFO] [1404732442.522901428]: MoveitSimpleControllerManager: Waiting for arm_controller/joint_trajectory_action to come up
[ERROR] [1404732447.523168432]: MoveitSimpleControllerManager: Action client not connected: arm_controller/joint_trajectory_action
[ INFO] [1404732452.554659308]: MoveitSimpleControllerManager: Waiting for gripper_controller/gripper_action to come up
[ INFO] [1404732457.554842362]: MoveitSimpleControllerManager: Waiting for gripper_controller/gripper_action to come up
[ERROR] [1404732462.555062991]: MoveitSimpleControllerManager: Action client not connected: gripper_controller/gripper_action

I would like to ask two questions,
(1) Am I in the correct direction to execute path planning with a real robot arm?
(2) For the above errors, i think it's due to the absence of controllers, is it? If so, what should i do to add them?


Best regards,
Quantao

[Dave Hershberger]

I'm not familiar with the Schunk 7 dof arm, but I know that the problem you are having is that you are either not running an arm controller node, or you have some topic/namespace names wrong.

The "controller configuration" link you gave only describes how to connect MoveIt to an existing robot controller.  If you look at the first paragraph on that page you'll see that it says it assumes you already have your robot controller running.

That controller needs to implement one of the actionlib action servers like FollowJointTrajectory.

It could be you just need to run another launch file to get it started.

To see if it is just a misconfiguration of names, do a 'rostopic list -v' and search for a topic being *subscribed* of type
'FollowJointTrajectoryActionGoal'.

Dave

[Shaun Edwards]

Quantao,

The ROS-I tutorial assumes that you have platform specific nodes that know how to talk to your robot and provide the Joint Trajectory Action as Dave suggested.  In the "moveit_planning_execution.launch" template, you must add these nodes here.  I'm not sure how the Schunk drivers are written, so I can't provide any help on your specific platform.

Shaun 

[Quantao Yang]

Hi Dave,

thanks for your great reply. I run the command 'rostopic list -v' and find a topic:  /joint_trajectory_action/goal [control_msgs/FollowJointTrajectoryActionGoal], so does it mean that i mistake some topic names, if so how to find the wrong names?

As for controllers, I don't understand where it comes from, because didn't write a controller node, is it provided by moveit? Sorry for this silly question.

Best regards,

Quantao

[Quantao Yang]

Hi Shaun,

thank for your information and actually i just followed that launch template. 

Best regards,

Quantao

[Dave Hershberger]

When you run 'rostopic list -v' it shows first a list of published topics and next a list of subscribed topics.

The MoveIt code you are already running publishes on that topic, so you should see at least one publisher of it.

What you are looking for is a subscriber to that topic.

You can also do: 'rostopic info /joint_trajectory_action/goal' which shows all the publishers and subscribers of the topic.

Dave

[Quantao Yang]

Hi Dave,
when i run 'rostopic info /joint_trajectory_action/goal', i got:
     Type: control_msgs/FollowJointTrajectoryActionGoal
     Publishers: None
     Subscribers: * /joint_trajectory_action (http://quantao-PC:45399/)
There is no publisher, what's the problem?

Quantao






在 2014年7月8日星期二UTC+2上午12时49分17秒，Dave Hershberger写道：

[Luis Rubio]

Hello Quantao,

I am new in moveIt! but I am working with Gazebo simulator and I had the same problem. My problem was solved changing the namespaces, my gazebo controllers was in a specified namespace, so I had to change these lines:

In moveit_planning_execution.launch:

  <!-- run the robot simulator and action interface nodes -->
  <group if="$(arg sim)" ns="your_namespace">
    <include file="$(find industrial_robot_simulator)/launch/robot_interface_simulator.launch" />
  </group>

In controllers.yaml:
    controller_list:
      - name: /your_namespace/your_controller_name
        ...

In move_group.launch:
  <node name="move_group" launch-prefix="$(arg launch_prefix)" pkg="moveit_ros_move_group" type="move_group" respawn="false" output="screen" args="$(arg command_args)">
    <!-- Set the display variable, in case OpenGL code is used internally -->
    <remap from="/joint_states" to="/your_namespace/joint_states" />
    <env name="DISPLAY" value="$(optenv DISPLAY :0)" />

If is the same problem, this might help you.

Best regards,
Luis

[Quantao Yang]

Hi Luis,
i am also new in moveit and ROS, actually i don't know what the namespace and the controller are specified for in my project and, is the controller provided by moveit itself? Because i didn't write any  controller node. What's your understanding about them?

Best regards,
Quantao




在 2014年7月8日星期二UTC+2下午3时16分56秒，Luis Rubio写道：

[Michael Ferguson]

I recall there was an interesting discuss several years ago about the navigation stack, and specifically the fact that the "move_base" node does everything except "actually move the base" -- that is, the controllers that turn the commands into actual electric pulses somewhere in the robot which results in movement is outside of the move_base node -- the same holds true for MoveIt (which, in this case, does everything except actually "move it").

The missing link here is that MoveIt only comes up with the planned trajectory based on the model of the robot (which includes the URDF, the velocity/acceleration limits, and meshes to specify the collision model). MoveIt then has a simple interface that allows sending these trajectories to external controllers. The controller implementations vary widely depending on the actual robot used -- but are almost always based on the control_msgs/FollowJointTrajectoryAction specification.

For most ROS robots, there is a separate "driver" node, which might bake the controllers right in, or possibly use a plugin interface to load generic controllers, such as those found in the ros_control project. Regardless of how the controllers are actually implemented, the driver has to know how to actually turn the trajectory computed by MoveIt into commands for the underlying hardware. The documentation for the driver/controller used should specify where in the ROS namespace the controller is exposed by the driver (what name the topics take at runtime), and that will in turn tell what to put into the controllers.yaml. I'm not sure what the exact driver is that you are using for the Schunk arm -- but if you point us at the package we might be able to help out more.

-Fergs

[Quantao Yang]

Hi Fergs,
thanks for your great explanation and the driver  of this arm is Can Bus ESD CAN PCI 405.
For a desired position and orientation of the end effector, can i calculate the corresponding joint values(IK calculation), then send them directly to the driver?


Quantao


在 2014年7月9日星期三UTC+2上午11时13分37秒，Fergs写道：