Difference in trajectory Execution between MoveIt and Real Robot

asked 2021-12-08 08:30:57 -0600

bhomaidan gravatar image

updated 2021-12-14 08:53:01 -0600

Hi, I'm using YuMi with MoveIt (OMPL, RRTstar) python interface through my own script to move ABB YuMi IRB14000, but the visualized trajectory seems to be different from the actual one which has led to a collision.


My setup is : ros-noetic, abb-robot-driver, ros_control: JointTrajectoryController/velocity_controller

Can you please tell me what is the possible cause/s of this odd behavior, and how can I possibly avoid it? thanks in advance.

Note that: I have modified the following files in abb_robot_driver to work with MoveIt


  type: joint_state_controller/JointStateController
  publish_rate: 250

  type         : abb_egm_state_controller/EGMStateController
  publish_rate : 250

  type: velocity_controllers/JointTrajectoryController
    - yumi_robl_joint_1
    - yumi_robl_joint_2
    - yumi_robl_joint_3
    - yumi_robl_joint_4
    - yumi_robl_joint_5
    - yumi_robl_joint_6
    - yumi_robl_joint_7
    - yumi_robr_joint_1
    - yumi_robr_joint_2
    - yumi_robr_joint_3
    - yumi_robr_joint_4
    - yumi_robr_joint_5
    - yumi_robr_joint_6
    - yumi_robr_joint_7
    stopped_velocity_tolerance: 0
    yumi_robl_joint_1: {p: 1.0, i: 0, d: 0.00, i_clamp: 0.1}
    yumi_robl_joint_2: {p: 1.0, i: 0, d: 0.00, i_clamp: 0.1}
    yumi_robl_joint_3: {p: 1.0, i: 0, d: 0.00, i_clamp: 0.1}
    yumi_robl_joint_4: {p: 1.0, i: 0, d: 0.00, i_clamp: 0.1}
    yumi_robl_joint_5: {p: 1.0, i: 0, d: 0.00, i_clamp: 0.1}
    yumi_robl_joint_6: {p: 1.0, i: 0, d: 0.00, i_clamp: 0.1}
    yumi_robl_joint_7: {p: 1.0, i: 0, d: 0.00, i_clamp: 0.1}
    yumi_robr_joint_1: {p: 1.0, i: 0, d: 0.00, i_clamp: 0.1}
    yumi_robr_joint_2: {p: 1.0, i: 0, d: 0.00, i_clamp: 0.1}
    yumi_robr_joint_3: {p: 1.0, i: 0, d: 0.00, i_clamp: 0.1}
    yumi_robr_joint_4: {p: 1.0, i: 0, d: 0.00, i_clamp: 0.1}
    yumi_robr_joint_5: {p: 1.0, i: 0, d: 0.00, i_clamp: 0.1}
    yumi_robr_joint_6: {p: 1.0, i: 0, d: 0.00, i_clamp: 0.1}
    yumi_robr_joint_7: {p: 1.0, i: 0, d: 0.00, i_clamp: 0.1}


<node pkg="controller_manager" type="spawner" name="stopped" args="--stopped jnt_traj_vel_controller"/>

and here is my launch file:

and my launch file moveit_planning_execution.launch looks like this:


  <!-- the "sim" argument controls whether we connect to a Simulated or Real robot -->
  <!--  - if sim=false, a robot_ip argument is required -->
  <arg name="sim" default="false" doc="Use industrial robot simulator instead of real robot" />
  <arg name="robot_ip" unless="$(arg sim)" value="" doc="IP of controller (only required if not using industrial simulator)" />

  <!-- By default, we do not start a database (it can be large) -->
  <arg name="db" default="false" doc="Start the MoveIt database" />
  <!-- Allow user to specify database location -->
  <arg name="db_path" default="$(find yumi_moveit_config)/default_warehouse_mongo_db" doc="Path to database files" />

  <!-- load the robot_description parameter before launching ROS-I nodes -->
  <include file="$(find yumi_moveit_config)/launch/planning_context.launch" >
    <arg name="load_robot_description" value="true" />

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

  <!-- run the "real robot" interface nodes -->
  <!--   - this typically includes: robot_state, motion_interface, and joint_trajectory_action nodes -->
  <!--   - replace these ...
edit retag flag offensive close merge delete


I don't have an answer, but I'm wondering whether you feel you've provided sufficient information.

It's really difficult to see what's going on in the .gif, whether it shows what is supposed to happen or not and what you observed. Additionally, you don't explain what you were doing, what happened exactly and how you were trying to do what you were trying to do (ie: used RViz with the MoveIt Motion Planning plugin, wrote your own scripts, something else, etc).

I'd recommend to provide more information, as I don't expect anyone to be able to give any insightful answers like this.

gvdhoorn gravatar image gvdhoorn  ( 2021-12-08 11:00:13 -0600 )edit

If your code ran the RRT* planner a second time to move the physical arm, there is no guarantee that the plan is anything like the first one.

Mike Scheutzow gravatar image Mike Scheutzow  ( 2021-12-08 13:36:17 -0600 )edit

@MikeScheutzow do you think that movegroup.allow_replanning(False) might solve this problem? or should I do further steps?

bhomaidan gravatar image bhomaidan  ( 2021-12-08 13:57:14 -0600 )edit


  • I have edited the question, and still not sure if the provided info represents a minimal reproducible example, but I'm not sure which extra info should I provide.

  • The .gif shows the planned trajectory (what was supposed to happen) and the collision state (what actually happened) during the actual execution with a real robot.

  • I was using executing a joint-space movement using MoveIt-API in python and added a table object to the scene., the visualization RViz, and MoveIt, but I'm using my python script to do the interfacing with MoveIt instead of the RViz GUI interface.

bhomaidan gravatar image bhomaidan  ( 2021-12-08 14:18:48 -0600 )edit

You have another problem to handle: unless something has changed, moveit does not do collision checking when executing a Joint Trajectory path. There is a method you can call to check a particular set of joint values for collision in the scene, but it's up to you to call it periodically and stop the arm if there is a problem.

Regarding your question above, I don't know the semantics of allow_replanning().

Mike Scheutzow gravatar image Mike Scheutzow  ( 2021-12-09 07:42:55 -0600 )edit