driver: persistent (and incorrect) "Trajectory start position doesn't match current robot position"

observed behaviour: when trying to execute a trajectory through the motoman_driver provided joint_trajectory_action node, the motoros application persistently returns a MotionReplySubcodes::Invalid::DATA_START_POS error, even if target_pos == current_pos for all joints. Analysis of the simple message traffic between motoros and the ROS PC confirmed the receipt of the DATA_START_POS error message.

Starting the servos before commanding a motion does not help (to avoid running into issues with START_MAX_PULSE_DEVIATION and gravity).

The work-around for #91 also does not influence this.

expected: execution of the trajectory

tl;dr: ROS side of driver (incorrectly) assumes order of joint data in incoming goals is identical to what it is configured for / the joint order motoros expects, leading to all trajectories being refused because current_pos == traj[0].target_pos is never true.

It would appear the code in at least JointTrajectoryAction::goalCB(JointTractoryActionServer::GoalHandle gh) makes an assumption about the ordering of joint names in a JointTrajectory message when mapping such a message to an (internally used) motoman_msgs::DynamicJointsGroup.

The current implementation essentially does this in the following way:

find the index of the first joint in the incoming trajectory the node knows about (here). Note that the joints the node knows about are configured using the parameters loaded in the sda10f_motion_interface.yaml file (here for the SDA10)
if it finds that joint name in the goal msg, it saves its index (here), and then proceeds by copying the incoming data into the corresponding DynamicJointsGroup fields, under the assumption that data for consecutive joints in the kinematic chain of the robot is also stored at consecutive indices in the positions, velocities and accelerations arrays

I've emphasised the problematic parts.

This is a dangerous assumption to make in any case, and for instance MoveIt appears to happily re-order joints when submitting goals, making looking for the 'first joint' completely pointless (as there is no guarantee that the order of joint target values in the goal now corresponds to anything on the robot side).

A correct(er?) approach would seem to be to perform the mapping for each joint individually, every time a goal is received. That would mean std::find(..)ing N joints again and again, but there is no requirement for Action clients to maintain the same order of joints as those the server is configured with. It would appear the mapping can also not be cached (at least not be re-used for future incoming goals), as clients could potentially randomise the order in which they specify the joint data every submitted goal.

As the order of the joint targets in the DynamicJointsGroup after the mapping doesn't correspond to the state of the robot at the time the trajectory is executed, the motoros application returns the reported "Trajectory start position doesn't match current robot position". Only in (very) rare circumstances will the commanded trajectory actually be executed (if the re-ordered states happen to match because the joint positions of re-ordered joints are identical).

This was reported by @jettan, @mbharatheesha and @de-vri-es.

I'm not sure, but I think the above described assumption (about joint name ordering) is (at least partly) why the joints and links in fi the motoman_sda10f and the motoman_sia10d xacro macros are named like link_N_A and joint_N_A (with N an increasing number, and A the name of the joint conforming to Motoman specs).

Here for the SDA10F, and here for the SIA10F.

@thiagodefreitas: any input?

I think this is a serious bug, and am considering adding a warning / notice to the wiki page telling prospective users about it.

Thoughts @shaun-edwards ?

Just thought I'd add this: this exact issue seems to also have been reported by @thiagodefreitas in https://github.com/ros-industrial/motoman/pull/42#issuecomment-54307172:

Although motoman joints are usually named as joint_letter, I have an issue when running both drivers(even the current state of the older one from ros-i hydro-devel), where I can not work properly with MoveIt!. I would suggest that an issue is created to investigate this problem with the alphabetical order. For the moment, I have kept it on the URDF as joint_number_letter to avoid this problem.

That would seem to suggest the assumption about s being the first joint and then ++-ing through the rest of the joints was also already present in "the older one from ros-i hydro-devel".

hi @gavanderhoorn ,

I believe I am experiencing this issue using a Yaskawa GP8 and YRC1000 micro controller w/ MoveIt. Is the suggested workaround the fix that you mentioned to the jointtrajectoryaction.cpp?

"A correct(er?) approach would seem to be to perform the mapping for each joint individually, every time a goal is received. That would mean std::find(..)ing N joints again and again, but there is no requirement for Action clients to maintain the same order of joints as those the server is configured with. It would appear the mapping can also not be cached (at least not be re-used for future incoming goals), as clients could potentially randomise the order in which they specify the joint data every submitted goal."

@tanimfresh: first thing to make sure is you get this error from the driver and not from MoveIt itself. MoveIt has added a similar check.

I would suggest to check the origin of the error first, before thinking about changing the driver' source.

If you add this line to your .bashrc, and then open a new terminal and try testing again, it should tell you which node prints this error:

export ROSCONSOLE_FORMAT='[${severity}] [${time}] [${node}] [${logger}]: ${message}'

Hi @gavanderhoorn,

I believe after adding this logging that the error is indeed coming from the driver:


header: 
  seq: 21
  stamp: 
    secs: 1586803189
    nsecs: 399154532
  frame_id: ''
level: 2
name: "/motion_streaming_interface"
msg: "Receiving joint trajectory message"
file: "/home/tanim/vlr-workspace/vlr-software/src/gp8/motoman/motoman_driver/src/industrial_robot_client/joint_trajectory_streamer.cpp"
function: "joint_trajectory_streamer::JointTrajectoryStreamer::jointTrajectoryCB"
line: 128
topics: [/rosout]
---
header: 
  seq: 21
  stamp: 
    secs: 1586803189
    nsecs: 397491854
  frame_id: ''
level: 2
name: "/joint_trajectory_action"
msg: "Received new goal"
file: "/home/tanim/vlr-workspace/vlr-software/src/gp8/industrial_core/industrial_robot_client/src/joint_trajectory_action.cpp"
function: "joint_trajectory_action::JointTrajectoryAction::goalCB"
line: 112
topics: [/rosout, /joint_path_command, /joint_trajectory_action/result, /joint_trajectory_action/feedback,
  /joint_trajectory_action/status]
---
header: 
  seq: 22
  stamp: 
    secs: 1586803189
    nsecs: 399592249
  frame_id: ''
level: 8
name: "/motion_streaming_interface"
msg: "Validation failed: Trajectory doesn't start at current position."
file: "/home/tanim/vlr-workspace/vlr-software/src/gp8/motoman/motoman_driver/src/joint_trajectory_streamer.cpp"
function: "joint_trajectory_streamer::MotomanJointTrajectoryStreamer::is_valid"
line: 504
topics: [/rosout]
---
header: 
  seq: 22
  stamp: 
    secs: 1586803189
    nsecs: 397686828
  frame_id: ''
level: 2
name: "/joint_trajectory_action"
msg: "Publishing trajectory"
file: "/home/tanim/vlr-workspace/vlr-software/src/gp8/industrial_core/industrial_robot_client/src/joint_trajectory_action.cpp"
function: "joint_trajectory_action::JointTrajectoryAction::goalCB"
line: 145
topics: [/rosout, /joint_path_command, /joint_trajectory_action/result, /joint_trajectory_action/feedback,
  /joint_trajectory_action/status]
---
header: 
  seq: 23
  stamp: 
    secs: 1586803189
    nsecs: 421066315
  frame_id: ''
level: 2
name: "/joint_trajectory_action"
msg: "Waiting to check for goal completion until halfway through trajectory"
file: "/home/tanim/vlr-workspace/vlr-software/src/gp8/industrial_core/industrial_robot_client/src/joint_trajectory_action.cpp"
function: "joint_trajectory_action::JointTrajectoryAction::controllerStateCB"
line: 232
topics: [/rosout, /joint_path_command, /joint_trajectory_action/result, /joint_trajectory_action/feedback,
  /joint_trajectory_action/status]

In this case, is the only solution at the moment the method you proposed of changing the driver source? I am also curious as to whether point streaming method introduced in PR 215 may help, as I am planning on implementing this regardless for better closed loop control

In this case, is the only solution at the moment the method you proposed of changing the driver source?

No. The right thing to do would be to diagnose what causes the error to be printed.

There's no point in haphazardly starting to edit files without knowing the cause.

First thing to check: are you using motoman_gp8_support/urdf/gp8_macro.xacro as URDF, or something you created yourself?

If you're using something you created yourself, you'll want to compare with motoman_gp8_support/urdf/gp8_macro.xacro, specifically how the joint names are defined. You'll also want to make sure you use the same joint names in your MoveIt configuration, and make sure to use the correct joint names there as well.

For single group setups with a known-good robot model, the error reported in the OP here should not occur, provided the work-around (including a nr in the joint names) is used.

That's the reason I'd like to understand why you are running into this.

Besides checking which .xacro you are using, it would also be good to post a single JointState message here, so we can compare.

I am also curious as to whether point streaming method introduced in PR 215 may help, as I am planning on implementing this regardless for better closed loop control

No, that's not going to help. And please be aware of #219 and #252.

Hi @gavanderhoorn ,

I am indeed using a different urdf generated by MoveIt. I compared it with the typical gp8_macro.xacro and it looks like the MoveIt setup assistant just appends additional information to this URDF; the joint names are identical. I have included an example of a JointState message below:

---
header: 
  seq: 429
  stamp: 
    secs: 1586841581
    nsecs: 301554218
  frame_id: ''
name: [joint_1_s, joint_2_l, joint_3_u, joint_4_r, joint_5_b, joint_6_t]
position: [0.0, -8.628642535768449e-05, 1.4999072551727295, 8.181230805348605e-05, 2.3968450477696024e-05, 3.7544981751125306e-05]
velocity: [0.0, 0.0, 0.0, 0.0, 0.0, 0.0]
effort: []
---

For single group setups with a known-good robot model, the error reported in the OP here should not occur, provided the work-around (including a nr in the joint names) is used.

Can you please elaborate this workaround? I did not catch this explanation.

I am indeed using a different urdf generated by MoveIt.

This confuses me: MoveIt does not generate any urdfs. You'll have to clarify.

And taking a step back, please:

tell us more about your exact hw setup
how you installed ROS and which version it is
where you got your robot support package (ie: xacros)
whether there are any other devices/robots/equipment in your urdf/xacro
what it is you're trying to do exactly
how you start everything (ie: which .launch files and where did you get them from)

Sure thing. I am referring to the following section of the MoveIt setup assistant: After reviewing the differences, this MoveIt generated URDF includes a few additional section related to gazebo, including transmission and actuator tags.

HW: Yaskawa GP8 manipulator with the YRC1000 micro controller

ROS: Kinetic; installed through Debian packages for Ubuntu with the command sudo apt-get install ros-kinetic-desktop-full

Support package: I installed from Manipulator_tutorials package

Goal:

I have created a list of poses for the end effector to move through. In hopes of minimizing latency between pose motions, I have planned them all ahead of time, being sure to update plan start position. So if I want to move pose1, pose2, pose3; I plan from current position to pose1, plan from pose1(final position/vel/acc) to pose2, etc. I have checked that JointTrajectory[0] positions are equal to the current position before consecutive movements. Additionally, the issue from OP occurs if I execute the poses in the normal method (plan pose 1, execute, plan pose 2, execute, etc) as well.
I am also tasked with creating a "look at" function which will track a position in space as the point moves. For this, I aim to minimize latency as much as possible. In this search, I came across the point streaming method I mentioned earlier. Additionally, I also came across #217 , which is why I was wondering if implementing #215 would help both of the goals I have mentioned here.

Start process: From the previously linked manipulator_tutorial, I run roslaunch motoman_gp8_moveit_config gp8_planning_execution.launch sim:=False

I am referring to the following section of the MoveIt setup assistant:

I would advise you to never use that functionality of the MSA. Due to the fact I have experience with the manual method, I may be biased, but it's not a very nice implementation and unless you are using Gazebo, there is no need to do any of that in the first place.

Support package: I installed from Manipulator_tutorials package

That repository does not actually contain a urdf for the GP8. It uses the GP8 model from motoman_gp8_support in ros-industrial/motoman (ie: this repository). Additionally, the workcell.urdf referenced in the planning_context.launch file (here) does not seem to exist in moveit_tutorial (here). There is a file called workcell.txt, but that contains no references to Motoman robots.

Please clarify whether you have made any local changes to these packages.

In hopes of minimizing latency between pose motions, I have planned them all ahead of time, being sure to update plan start position. So if I want to move pose1, pose2, pose3; I plan from current position to pose1, plan from pose1(final position/vel/acc) to pose2, etc. I have checked that JointTrajectory[0] positions are equal to the current position before consecutive movements.

Due to the very tight threshold, I'm not confident this will work, but you can certainly try.

Additionally, the issue from OP occurs if I execute the poses in the normal method (plan pose 1, execute, plan pose 2, execute, etc) as well.

That should not happen, unless you are using the multi-group code-path and the joint names don't use the "numbers trick".

If you use the RViz MoveIt plugin to plan and execute motions, does it still complain?

I'll try to take a look with the robot we have here tomorrow, but in the meantime a Wireshark capture of the SimpleMessage traffic between the ROS PC and the YRC1000 when MotoROS returns the error would be good to have.

I am also tasked with creating a "look at" function which will track a position in space as the point moves. For this, I aim to minimize latency as much as possible. In this search, I came across the point streaming method I mentioned earlier. Additionally, I also came across #217 , which is why I was wondering if implementing #215 would help both of the goals I have mentioned here.

I still don't understand how adding infinite trajectory mode would help with incorrect joint orders (which is what this issue is about) or start state deviation.

And tracking would be possible with #215, but again please be aware of what is written in #219 and #252.

Hm. I will heed that advice moving forward. We will eventually need to implement this GP8 as part of a combined system that operates primarily in Gazebo, however, so hopefully this part is ok.

-My mistake, I should have mentioned I also have the motoman package you listed. -I have updated those lines specifically to point to the URDF generated by MSA

-I believe the plan stitching method I have implemented works (theoretically), as it works in simulation consistently and works intermittently on hardware. I.e I do not have any issues in RViz in either implementation (pre-plan and execute all plans, or plan/execute/plan/execute).

-I ran the standard implementation (plan/execute) again to check, and I do indeed see the error: Although I should mention that this method definitely produces the error less frequently than my custom implementation.

-It seems that if I put a rospy.sleep() between executions, it helps more often. I still cannot reliably run executions, but if I put a large sleep betweeen execute commands it will finish the poses more often than with a non-existent or small (0.1sec) sleep.

-I will work on getting a wireshark capture ready.

-I think I was taking to heart too much the note on the first post of #217 where the user mentioned that PR 215 was a 'known solution' and you mentioned it was just another implementation. Thinking about it longer I realize that you are right, I'm also not sure why it would help. I am aware of the latency introduced by the MotoPlus filtering and aware that it is unavoidable. As this is the closest implementation of closed loop control I have found, I am hoping to see what type of results it will yield in our end application. Anywho, this topic is unrelated to the post at hand, so I will refrain from mentioning it as an option any further.

For future comments: could you please avoid posting screenshots of code or terminals? It's all text. Just copy-paste it into the comment and use proper code highlighting.

We will eventually need to implement this GP8 as part of a combined system that operates primarily in Gazebo,

As I wrote: I know how to do it manually, and this makes me say I would never use the output of the MSA. If only for the reason it flattens a xacro hierarchy and outputs plain urdf. This removes the modularity and detroys composability.

Furthermore: adding Gazebo compatibility is trivial. I don't need the MSA for that.

But if it works for you then by all means use it.

I believe the plan stitching method I have implemented works (theoretically), as it works in simulation consistently and works intermittently on hardware. I.e I do not have any issues in RViz in either implementation (pre-plan and execute all plans, or plan/execute/plan/execute).

Results in simulation or RViz kinematic playout do not say anything about whether this will work on real hw and with the real driver.

Neither RViz nor simulation uses the driver, so it cannot run into this issue.

I ran the standard implementation (plan/execute) again to check, and I do indeed see the error:

I was more interested in whether the MoveIt RViz plugin works. It's a known-good interface to both MoveIt (and eventually the driver), which your script/code isn't.

So drag the marker, press Plan, check the motion and press Execute. Wait for completion, try to plan and execute another motion.

Please try and report.

It seems that if I put a rospy.sleep() between executions, it helps more often. I still cannot reliably run executions, but if I put a large sleep betweeen execute commands it will finish the poses more often than with a non-existent or small (0.1sec) sleep.

This sounds like what was reported earlier by users trying to plan / execute back-to-back: you have to make sure the robot has finished executing the previous motion. Check the in_motion field of the messages on the robot_status topic for that.

I think I was taking to heart too much the note on the first post of #217 where the user mentioned that PR 215 was a 'known solution' and you mentioned it was just another implementation.

The OP in #217 writes that #215 "is a known solution to this problem". I don't (and didn't) agree with him. What he is implying there is that because of the infinite trajectory, you only run the risk of seeing this error "once" (ie: at the start of the streaming session). But what he forgets is that you cannot send regular trajectories to the driver any more without stopping the streaming. And at that point you'd be back to where you started. Unless you implement another node which executes trajectories by sending points to the streaming topic (but at this point you're essentially reimplementing the driver).

If you could make sure in_motion is false when you start planning the next motion that would help.

The wireshark capture would also help.

Also: if you could share your own versions of the packages you linked to that would help. Right now I don't have a clear picture of what you changed or where. That makes it difficult to help you.

-I don't have the interactive markers, which I was hoping was a separate issue... but I am able to plan and execute random poses through RViz just fine. -I added a check for the inMotion flag, and am also viewing the topic live as I execute. It seems the flag is set to 0 before it receives an execute command, flips to 1, and then flips back to 0 right after the Validation Failed message appears. -I have run a test with the inMotion check as a gate for the execution to start. The error persisted, as the behavior aforementioned (initially 0 as we expect, execution starts, then error occurs) would not catch this. -Output

... logging to /home/tanim/.ros/log/25294030-7eae-11ea-81d1-30243203b731/roslaunch-tanim-ThinkPad-P52s-8242.log
Checking log directory for disk usage. This may take awhile.
Press Ctrl-C to interrupt
Done checking log file disk usage. Usage is <1GB.

started roslaunch server http://tanim-ThinkPad-P52s:33823/

SUMMARY
========

PARAMETERS
 * /controller_joint_names: ['joint_1_s', 'jo...
 * /move_group/allow_trajectory_execution: True
 * /move_group/capabilities: 
 * /move_group/controller_list: [{'action_ns': 'j...
 * /move_group/disable_capabilities: 
 * /move_group/gp8/default_planner_config: None
 * /move_group/gp8/longest_valid_segment_fraction: 0.005
 * /move_group/gp8/planner_configs: ['SBL', 'EST', 'L...
 * /move_group/gp8/projection_evaluator: joints(joint_1_s,...
 * /move_group/gp8_yaw/default_planner_config: 
 * /move_group/gp8_yaw/planner_configs: ['SBL', 'EST', 'L...
 * /move_group/jiggle_fraction: 0.05
 * /move_group/max_range: 5.0
 * /move_group/max_safe_path_cost: 1
 * /move_group/moveit_controller_manager: moveit_simple_con...
 * /move_group/moveit_manage_controllers: True
 * /move_group/octomap_resolution: 0.025
 * /move_group/planner_configs/BFMT/balanced: 0
 * /move_group/planner_configs/BFMT/cache_cc: 1
 * /move_group/planner_configs/BFMT/extended_fmt: 1
 * /move_group/planner_configs/BFMT/heuristics: 1
 * /move_group/planner_configs/BFMT/nearest_k: 1
 * /move_group/planner_configs/BFMT/num_samples: 1000
 * /move_group/planner_configs/BFMT/optimality: 1
 * /move_group/planner_configs/BFMT/radius_multiplier: 1.0
 * /move_group/planner_configs/BFMT/type: geometric::BFMT
 * /move_group/planner_configs/BKPIECE/border_fraction: 0.9
 * /move_group/planner_configs/BKPIECE/failed_expansion_score_factor: 0.5
 * /move_group/planner_configs/BKPIECE/min_valid_path_fraction: 0.5
 * /move_group/planner_configs/BKPIECE/range: 0.0
 * /move_group/planner_configs/BKPIECE/type: geometric::BKPIECE
 * /move_group/planner_configs/BiEST/range: 0.0
 * /move_group/planner_configs/BiEST/type: geometric::BiEST
 * /move_group/planner_configs/BiTRRT/cost_threshold: 1e300
 * /move_group/planner_configs/BiTRRT/frountier_node_ratio: 0.1
 * /move_group/planner_configs/BiTRRT/frountier_threshold: 0.0
 * /move_group/planner_configs/BiTRRT/init_temperature: 100
 * /move_group/planner_configs/BiTRRT/range: 0.0
 * /move_group/planner_configs/BiTRRT/temp_change_factor: 0.1
 * /move_group/planner_configs/BiTRRT/type: geometric::BiTRRT
 * /move_group/planner_configs/EST/goal_bias: 0.05
 * /move_group/planner_configs/EST/range: 0.0
 * /move_group/planner_configs/EST/type: geometric::EST
 * /move_group/planner_configs/FMT/cache_cc: 1
 * /move_group/planner_configs/FMT/extended_fmt: 1
 * /move_group/planner_configs/FMT/heuristics: 0
 * /move_group/planner_configs/FMT/nearest_k: 1
 * /move_group/planner_configs/FMT/num_samples: 1000
 * /move_group/planner_configs/FMT/radius_multiplier: 1.1
 * /move_group/planner_configs/FMT/type: geometric::FMT
 * /move_group/planner_configs/KPIECE/border_fraction: 0.9
 * /move_group/planner_configs/KPIECE/failed_expansion_score_factor: 0.5
 * /move_group/planner_configs/KPIECE/goal_bias: 0.05
 * /move_group/planner_configs/KPIECE/min_valid_path_fraction: 0.5
 * /move_group/planner_configs/KPIECE/range: 0.0
 * /move_group/planner_configs/KPIECE/type: geometric::KPIECE
 * /move_group/planner_configs/LBKPIECE/border_fraction: 0.9
 * /move_group/planner_configs/LBKPIECE/min_valid_path_fraction: 0.5
 * /move_group/planner_configs/LBKPIECE/range: 0.0
 * /move_group/planner_configs/LBKPIECE/type: geometric::LBKPIECE
 * /move_group/planner_configs/LBTRRT/epsilon: 0.4
 * /move_group/planner_configs/LBTRRT/goal_bias: 0.05
 * /move_group/planner_configs/LBTRRT/range: 0.0
 * /move_group/planner_configs/LBTRRT/type: geometric::LBTRRT
 * /move_group/planner_configs/LazyPRM/range: 0.0
 * /move_group/planner_configs/LazyPRM/type: geometric::LazyPRM
 * /move_group/planner_configs/LazyPRMstar/type: geometric::LazyPR...
 * /move_group/planner_configs/PDST/type: geometric::PDST
 * /move_group/planner_configs/PRM/max_nearest_neighbors: 10
 * /move_group/planner_configs/PRM/type: geometric::PRM
 * /move_group/planner_configs/PRMstar/type: geometric::PRMstar
 * /move_group/planner_configs/ProjEST/goal_bias: 0.05
 * /move_group/planner_configs/ProjEST/range: 0.0
 * /move_group/planner_configs/ProjEST/type: geometric::ProjEST
 * /move_group/planner_configs/RRT/goal_bias: 0.05
 * /move_group/planner_configs/RRT/range: 0.0
 * /move_group/planner_configs/RRT/type: geometric::RRT
 * /move_group/planner_configs/RRTConnect/range: 0.0
 * /move_group/planner_configs/RRTConnect/type: geometric::RRTCon...
 * /move_group/planner_configs/RRTstar/delay_collision_checking: 1
 * /move_group/planner_configs/RRTstar/goal_bias: 0.05
 * /move_group/planner_configs/RRTstar/range: 0.0
 * /move_group/planner_configs/RRTstar/type: geometric::RRTstar
 * /move_group/planner_configs/SBL/range: 0.0
 * /move_group/planner_configs/SBL/type: geometric::SBL
 * /move_group/planner_configs/SPARS/dense_delta_fraction: 0.001
 * /move_group/planner_configs/SPARS/max_failures: 1000
 * /move_group/planner_configs/SPARS/sparse_delta_fraction: 0.25
 * /move_group/planner_configs/SPARS/stretch_factor: 3.0
 * /move_group/planner_configs/SPARS/type: geometric::SPARS
 * /move_group/planner_configs/SPARStwo/dense_delta_fraction: 0.001
 * /move_group/planner_configs/SPARStwo/max_failures: 5000
 * /move_group/planner_configs/SPARStwo/sparse_delta_fraction: 0.25
 * /move_group/planner_configs/SPARStwo/stretch_factor: 3.0
 * /move_group/planner_configs/SPARStwo/type: geometric::SPARStwo
 * /move_group/planner_configs/STRIDE/degree: 16
 * /move_group/planner_configs/STRIDE/estimated_dimension: 0.0
 * /move_group/planner_configs/STRIDE/goal_bias: 0.05
 * /move_group/planner_configs/STRIDE/max_degree: 18
 * /move_group/planner_configs/STRIDE/max_pts_per_leaf: 6
 * /move_group/planner_configs/STRIDE/min_degree: 12
 * /move_group/planner_configs/STRIDE/min_valid_path_fraction: 0.2
 * /move_group/planner_configs/STRIDE/range: 0.0
 * /move_group/planner_configs/STRIDE/type: geometric::STRIDE
 * /move_group/planner_configs/STRIDE/use_projected_distance: 0
 * /move_group/planner_configs/TRRT/frountierNodeRatio: 0.1
 * /move_group/planner_configs/TRRT/frountier_threshold: 0.0
 * /move_group/planner_configs/TRRT/goal_bias: 0.05
 * /move_group/planner_configs/TRRT/init_temperature: 10e-6
 * /move_group/planner_configs/TRRT/k_constant: 0.0
 * /move_group/planner_configs/TRRT/max_states_failed: 10
 * /move_group/planner_configs/TRRT/min_temperature: 10e-10
 * /move_group/planner_configs/TRRT/range: 0.0
 * /move_group/planner_configs/TRRT/temp_change_factor: 2.0
 * /move_group/planner_configs/TRRT/type: geometric::TRRT
 * /move_group/planning_plugin: ompl_interface/OM...
 * /move_group/planning_scene_monitor/publish_geometry_updates: True
 * /move_group/planning_scene_monitor/publish_planning_scene: True
 * /move_group/planning_scene_monitor/publish_state_updates: True
 * /move_group/planning_scene_monitor/publish_transforms_updates: True
 * /move_group/request_adapters: default_planner_r...
 * /move_group/sensors: [{'point_subsampl...
 * /move_group/start_state_max_bounds_error: 0.1
 * /move_group/trajectory_execution/allowed_execution_duration_scaling: 1.2
 * /move_group/trajectory_execution/allowed_goal_duration_margin: 0.5
 * /move_group/trajectory_execution/allowed_start_tolerance: 0.01
 * /robot_description: <?xml version="1....
 * /robot_description_kinematics/gp8/kinematics_solver: kdl_kinematics_pl...
 * /robot_description_kinematics/gp8/kinematics_solver_attempts: 3
 * /robot_description_kinematics/gp8/kinematics_solver_search_resolution: 0.005
 * /robot_description_kinematics/gp8/kinematics_solver_timeout: 0.005
 * /robot_description_planning/joint_limits/joint_1_s/has_acceleration_limits: False
 * /robot_description_planning/joint_limits/joint_1_s/has_velocity_limits: True
 * /robot_description_planning/joint_limits/joint_1_s/max_acceleration: 0
 * /robot_description_planning/joint_limits/joint_1_s/max_velocity: 7.9412
 * /robot_description_planning/joint_limits/joint_2_l/has_acceleration_limits: False
 * /robot_description_planning/joint_limits/joint_2_l/has_velocity_limits: True
 * /robot_description_planning/joint_limits/joint_2_l/max_acceleration: 0
 * /robot_description_planning/joint_limits/joint_2_l/max_velocity: 6.7495
 * /robot_description_planning/joint_limits/joint_3_u/has_acceleration_limits: False
 * /robot_description_planning/joint_limits/joint_3_u/has_velocity_limits: True
 * /robot_description_planning/joint_limits/joint_3_u/max_acceleration: 0
 * /robot_description_planning/joint_limits/joint_3_u/max_velocity: 9.0757
 * /robot_description_planning/joint_limits/joint_4_r/has_acceleration_limits: False
 * /robot_description_planning/joint_limits/joint_4_r/has_velocity_limits: True
 * /robot_description_planning/joint_limits/joint_4_r/max_acceleration: 0
 * /robot_description_planning/joint_limits/joint_4_r/max_velocity: 9.5993
 * /robot_description_planning/joint_limits/joint_5_b/has_acceleration_limits: False
 * /robot_description_planning/joint_limits/joint_5_b/has_velocity_limits: True
 * /robot_description_planning/joint_limits/joint_5_b/max_acceleration: 0
 * /robot_description_planning/joint_limits/joint_5_b/max_velocity: 9.5993
 * /robot_description_planning/joint_limits/joint_6_t/has_acceleration_limits: False
 * /robot_description_planning/joint_limits/joint_6_t/has_velocity_limits: True
 * /robot_description_planning/joint_limits/joint_6_t/max_acceleration: 0
 * /robot_description_planning/joint_limits/joint_6_t/max_velocity: 17.4845
 * /robot_description_semantic: <?xml version="1....
 * /robot_ip_address: 192.168.1.31
 * /rosdistro: kinetic
 * /rosversion: 1.12.14
 * /rviz_tanim_ThinkPad_P52s_8242_8412461733129110792/gp8/kinematics_solver: kdl_kinematics_pl...
 * /rviz_tanim_ThinkPad_P52s_8242_8412461733129110792/gp8/kinematics_solver_attempts: 3
 * /rviz_tanim_ThinkPad_P52s_8242_8412461733129110792/gp8/kinematics_solver_search_resolution: 0.005
 * /rviz_tanim_ThinkPad_P52s_8242_8412461733129110792/gp8/kinematics_solver_timeout: 0.005

NODES
  /
    joint_state (motoman_driver/robot_state)
    joint_trajectory_action (industrial_robot_client/joint_trajectory_action)
    motion_streaming_interface (motoman_driver/motion_streaming_interface)
    move_group (moveit_ros_move_group/move_group)
    robot_state_publisher (robot_state_publisher/robot_state_publisher)
    rviz_tanim_ThinkPad_P52s_8242_8412461733129110792 (rviz/rviz)

auto-starting new master
process[master]: started with pid [8252]
ROS_MASTER_URI=http://localhost:11311

setting /run_id to 25294030-7eae-11ea-81d1-30243203b731
process[rosout-1]: started with pid [8265]
started core service [/rosout]
process[joint_state-2]: started with pid [8282]
process[motion_streaming_interface-3]: started with pid [8283]
[ERROR] [1586909700.847978910] [/joint_state] [ros.motoman_driver]: Failed to find topic_list parameter
process[joint_trajectory_action-4]: started with pid [8296]
[ERROR] [1586909700.859455562] [/motion_streaming_interface] [ros.motoman_driver]: Failed to find topic_list parameter
process[robot_state_publisher-5]: started with pid [8312]
process[move_group-6]: started with pid [8336]
process[rviz_tanim_ThinkPad_P52s_8242_8412461733129110792-7]: started with pid [8369]
[ INFO] [1586909700.934684755] [/move_group] [ros.moveit_core.robot_model]: Loading robot model 'motoman_gp8'...
[ INFO] [1586909701.002357396] [${node}] [ros.rviz]: rviz version 1.12.17
[ INFO] [1586909701.002409130] [${node}] [ros.rviz]: compiled against Qt version 5.5.1
[ INFO] [1586909701.002424251] [${node}] [ros.rviz]: compiled against OGRE version 1.9.0 (Ghadamon)
[ INFO] [1586909701.036117184] [/move_group] [ros.moveit_core.robot_model]: Loading robot model 'motoman_gp8'...
[ WARN] [1586909701.053005442] [/move_group] [ros.kdl_parser]: 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] [1586909701.150412955] [/move_group] [ros.moveit_ros_planning.planning_scene_monitor]: Publishing maintained planning scene on 'monitored_planning_scene'
[ INFO] [1586909701.153937116] [/move_group] [ros.moveit_ros_move_group]: MoveGroup debug mode is OFF
Starting context monitors...
[ INFO] [1586909701.153997970] [/move_group] [ros.moveit_ros_planning.planning_scene_monitor]: Starting scene monitor
[ INFO] [1586909701.157238103] [/move_group] [ros.moveit_ros_planning.planning_scene_monitor]: Listening to '/planning_scene'
[ INFO] [1586909701.157286423] [/move_group] [ros.moveit_ros_planning.planning_scene_monitor]: Starting world geometry monitor
[ INFO] [1586909701.160488472] [/move_group] [ros.moveit_ros_planning.planning_scene_monitor]: Listening to '/collision_object' using message notifier with target frame '/base_link '
[ INFO] [1586909701.163577302] [/move_group] [ros.moveit_ros_planning.planning_scene_monitor]: Listening to '/planning_scene_world' for planning scene world geometry
[ INFO] [1586909701.315633011] [/rviz_tanim_ThinkPad_P52s_8242_8412461733129110792] [ros.rviz]: Stereo is NOT SUPPORTED
[ INFO] [1586909701.315793900] [/rviz_tanim_ThinkPad_P52s_8242_8412461733129110792] [ros.rviz]: OpenGl version: 3 (GLSL 1.3).
[ INFO] [1586909701.555536755] [/move_group] [ros.moveit_ros_perception]: Listening to '/head_mount_kinect/depth_registered/points' using message filter with target frame '/base_link '
[ INFO] [1586909701.564179526] [/move_group] [ros.moveit_ros_planning.planning_scene_monitor]: Listening to '/attached_collision_object' for attached collision objects
Context monitors started.
[ INFO] [1586909701.623760983] [/move_group] [ros.moveit_planners_ompl]: Initializing OMPL interface using ROS parameters
[ERROR] [1586909701.632931261] [/move_group] [ros.moveit_planners_ompl]: Could not find the planner configuration 'None' on the param server
[ INFO] [1586909701.688504504] [/move_group] [ros.moveit_ros_planning]: Using planning interface 'OMPL'
[ INFO] [1586909701.692558564] [/move_group] [ros.moveit_ros_planning]: Param 'default_workspace_bounds' was not set. Using default value: 10
[ INFO] [1586909701.693260811] [/move_group] [ros.moveit_ros_planning]: Param 'start_state_max_bounds_error' was set to 0.1
[ INFO] [1586909701.693995436] [/move_group] [ros.moveit_ros_planning]: Param 'start_state_max_dt' was not set. Using default value: 0.5
[ INFO] [1586909701.694639727] [/move_group] [ros.moveit_ros_planning]: Param 'start_state_max_dt' was not set. Using default value: 0.5
[ INFO] [1586909701.695244247] [/move_group] [ros.moveit_ros_planning]: Param 'jiggle_fraction' was set to 0.05
[ INFO] [1586909701.695928799] [/move_group] [ros.moveit_ros_planning]: Param 'max_sampling_attempts' was not set. Using default value: 100
[ INFO] [1586909701.696017707] [/move_group] [ros.moveit_ros_planning]: Using planning request adapter 'Add Time Parameterization'
[ INFO] [1586909701.696041493] [/move_group] [ros.moveit_ros_planning]: Using planning request adapter 'Fix Workspace Bounds'
[ INFO] [1586909701.696066155] [/move_group] [ros.moveit_ros_planning]: Using planning request adapter 'Fix Start State Bounds'
[ INFO] [1586909701.696086524] [/move_group] [ros.moveit_ros_planning]: Using planning request adapter 'Fix Start State In Collision'
[ INFO] [1586909701.696110545] [/move_group] [ros.moveit_ros_planning]: Using planning request adapter 'Fix Start State Path Constraints'
[ INFO] [1586909701.696131526] [/move_group] [ros.moveit_ros_planning]: Using planning request adapter 'Add Time Parameterization'
[ INFO] [1586909702.001400702] [/move_group] [ros.moveit_simple_controller_manager.manager]: Added FollowJointTrajectory controller for 
[ INFO] [1586909702.001777716] [/move_group] [ros.moveit_simple_controller_manager.manager]: Returned 1 controllers in list
[ INFO] [1586909702.059501955] [/move_group] [ros.moveit_ros_planning.trajectory_execution_manager]: Trajectory execution is managing controllers
Loading 'move_group/ApplyPlanningSceneService'...
Loading 'move_group/ClearOctomapService'...
Loading 'move_group/MoveGroupCartesianPathService'...
Loading 'move_group/MoveGroupExecuteTrajectoryAction'...
Loading 'move_group/MoveGroupGetPlanningSceneService'...
Loading 'move_group/MoveGroupKinematicsService'...
Loading 'move_group/MoveGroupMoveAction'...
Loading 'move_group/MoveGroupPickPlaceAction'...
Loading 'move_group/MoveGroupPlanService'...
Loading 'move_group/MoveGroupQueryPlannersService'...
Loading 'move_group/MoveGroupStateValidationService'...
[ INFO] [1586909702.185601006] [/move_group] [ros.moveit_ros_move_group]: 

********************************************************
* MoveGroup using: 
*     - ApplyPlanningSceneService
*     - ClearOctomapService
*     - CartesianPathService
*     - ExecuteTrajectoryAction
*     - GetPlanningSceneService
*     - KinematicsService
*     - MoveAction
*     - PickPlaceAction
*     - MotionPlanService
*     - QueryPlannersService
*     - StateValidationService
********************************************************

[ INFO] [1586909702.185669021] [/move_group] [ros.moveit_ros_move_group]: MoveGroup context using planning plugin ompl_interface/OMPLPlanner
[ INFO] [1586909702.185708958] [/move_group] [ros.moveit_ros_move_group]: MoveGroup context initialization complete

You can start planning now!

[ INFO] [1586909704.713202580] [/rviz_tanim_ThinkPad_P52s_8242_8412461733129110792] [ros.moveit_core.robot_model]: Loading robot model 'motoman_gp8'...
[ INFO] [1586909704.801269577] [/rviz_tanim_ThinkPad_P52s_8242_8412461733129110792] [ros.moveit_core.robot_model]: Loading robot model 'motoman_gp8'...
[ WARN] [1586909704.824956751] [/rviz_tanim_ThinkPad_P52s_8242_8412461733129110792] [ros.kdl_parser]: 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] [1586909704.929313639] [/rviz_tanim_ThinkPad_P52s_8242_8412461733129110792] [ros.moveit_ros_planning.planning_scene_monitor]: Starting scene monitor
[ INFO] [1586909704.939556184] [/rviz_tanim_ThinkPad_P52s_8242_8412461733129110792] [ros.moveit_ros_planning.planning_scene_monitor]: Listening to '/move_group/monitored_planning_scene'
[ WARN] [1586909705.156366757] [/rviz_tanim_ThinkPad_P52s_8242_8412461733129110792] [ros.kdl_parser]: 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.
[ WARN] [1586909705.156586293] [/rviz_tanim_ThinkPad_P52s_8242_8412461733129110792] [ros.kdl_parser]: 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] [1586909705.158343711] [/rviz_tanim_ThinkPad_P52s_8242_8412461733129110792] [ros.moveit_ros_visualization]: Constructing new MoveGroup connection for group 'gp8' in namespace ''
[ INFO] [1586909706.348344279] [/rviz_tanim_ThinkPad_P52s_8242_8412461733129110792] [ros.moveit_ros_planning_interface.move_group_interface]: Ready to take commands for planning group gp8.
[ INFO] [1586909706.348419121] [/rviz_tanim_ThinkPad_P52s_8242_8412461733129110792] [ros.moveit_ros_planning_interface.move_group_interface]: Looking around: no
[ INFO] [1586909706.348447666] [/rviz_tanim_ThinkPad_P52s_8242_8412461733129110792] [ros.moveit_ros_planning_interface.move_group_interface]: Replanning: no
[ INFO] [1586909728.041526232] [/move_group] [ros.moveit_ros_move_group]: Planning request received for MoveGroup action. Forwarding to planning pipeline.
[ INFO] [1586909728.045240029] [/move_group] [ros.moveit_planners_ompl.model_based_planning_context]: Planner configuration 'gp8' will use planner 'geometric::RRTConnect'. Additional configuration parameters will be set when the planner is constructed.
[ INFO] [1586909728.046644545] [/move_group] [ros.moveit_planners_ompl.ompl]: RRTConnect: Starting planning with 1 states already in datastructure
[ INFO] [1586909728.059022722] [/move_group] [ros.moveit_planners_ompl.ompl]: RRTConnect: Created 4 states (2 start + 2 goal)
[ INFO] [1586909728.059261388] [/move_group] [ros.moveit_planners_ompl.ompl]: Solution found in 0.012818 seconds
[ INFO] [1586909728.071459232] [/move_group] [ros.moveit_planners_ompl.ompl]: SimpleSetup: Path simplification took 0.011762 seconds and changed from 3 to 2 states
[ INFO] [1586909728.120813210] [/move_group] [ros.moveit_ros_move_group]: Combined planning and execution request received for MoveGroup action. Forwarding to planning and execution pipeline.
[ INFO] [1586909728.121518071] [/move_group] [ros.moveit_ros_planning.plan_execution]: Planning attempt 1 of at most 1
[ INFO] [1586909728.122885322] [/move_group] [ros.moveit_planners_ompl.model_based_planning_context]: Planner configuration 'gp8' will use planner 'geometric::RRTConnect'. Additional configuration parameters will be set when the planner is constructed.
[ INFO] [1586909728.123211096] [/move_group] [ros.moveit_planners_ompl.ompl]: RRTConnect: Starting planning with 1 states already in datastructure
[ INFO] [1586909728.137532493] [/move_group] [ros.moveit_planners_ompl.ompl]: RRTConnect: Created 5 states (2 start + 3 goal)
[ INFO] [1586909728.137652603] [/move_group] [ros.moveit_planners_ompl.ompl]: Solution found in 0.014603 seconds
[ INFO] [1586909728.150934028] [/move_group] [ros.moveit_planners_ompl.ompl]: SimpleSetup: Path simplification took 0.013059 seconds and changed from 4 to 2 states
[ INFO] [1586909732.589365784] [/move_group] [ros.moveit_ros_planning.trajectory_execution_manager]: Completed trajectory execution with status SUCCEEDED ...
[ INFO] [1586909732.880327491] [/move_group] [ros.moveit_ros_move_group]: Planning request received for MoveGroup action. Forwarding to planning pipeline.
[ WARN] [1586909732.881443586] [/move_group] [ros.moveit_core.kinematic_constraints]: Orientation constraint for link 'link_6_t' is probably incorrect: -0.000015, -0.712915, -0.000028, 0.350000. Assuming identity instead.
[ WARN] [1586909732.882001671] [/move_group] [ros.moveit_core.kinematic_constraints]: Orientation constraint for link 'link_6_t' is probably incorrect: -0.000015, -0.712915, -0.000028, 0.350000. Assuming identity instead.
[ INFO] [1586909732.882922596] [/move_group] [ros.moveit_planners_ompl.model_based_planning_context]: Planner configuration 'gp8' will use planner 'geometric::RRTConnect'. Additional configuration parameters will be set when the planner is constructed.
[ INFO] [1586909732.883356553] [/move_group] [ros.moveit_planners_ompl.ompl]: RRTConnect: Starting planning with 1 states already in datastructure
[ INFO] [1586909732.908807248] [/move_group] [ros.moveit_planners_ompl.ompl]: RRTConnect: Created 4 states (2 start + 2 goal)
[ INFO] [1586909732.908929820] [/move_group] [ros.moveit_planners_ompl.ompl]: Solution found in 0.025692 seconds
[ INFO] [1586909732.929500709] [/move_group] [ros.moveit_planners_ompl.ompl]: SimpleSetup: Path simplification took 0.020469 seconds and changed from 3 to 2 states
[ INFO] [1586909732.932867646] [/move_group] [ros.moveit_ros_move_group.ExecuteTrajectoryAction]: Execution request received
[ INFO] [1586909735.956924424] [/move_group] [ros.moveit_ros_planning.trajectory_execution_manager]: Completed trajectory execution with status SUCCEEDED ...
[ INFO] [1586909735.957284643] [/move_group] [ros.moveit_ros_move_group.ExecuteTrajectoryAction]: Execution completed: SUCCEEDED
[ INFO] [1586909736.063241978] [/move_group] [ros.moveit_ros_move_group]: Planning request received for MoveGroup action. Forwarding to planning pipeline.
[ WARN] [1586909736.064060542] [/move_group] [ros.moveit_core.kinematic_constraints]: Orientation constraint for link 'link_6_t' is probably incorrect: 0.300238, 0.500000, 1.000000, 0.717375. Assuming identity instead.
[ WARN] [1586909736.064286981] [/move_group] [ros.moveit_core.kinematic_constraints]: Orientation constraint for link 'link_6_t' is probably incorrect: 0.300238, 0.500000, 1.000000, 0.717375. Assuming identity instead.
[ INFO] [1586909736.064611510] [/move_group] [ros.moveit_planners_ompl.model_based_planning_context]: Planner configuration 'gp8' will use planner 'geometric::RRTConnect'. Additional configuration parameters will be set when the planner is constructed.
[ INFO] [1586909736.065082775] [/move_group] [ros.moveit_planners_ompl.ompl]: RRTConnect: Starting planning with 1 states already in datastructure
[ INFO] [1586909736.148319982] [/move_group] [ros.moveit_planners_ompl.ompl]: RRTConnect: Created 5 states (2 start + 3 goal)
[ INFO] [1586909736.148363393] [/move_group] [ros.moveit_planners_ompl.ompl]: Solution found in 0.083495 seconds
[ INFO] [1586909736.169957954] [/move_group] [ros.moveit_planners_ompl.ompl]: SimpleSetup: Path simplification took 0.012698 seconds and changed from 4 to 2 states
[ INFO] [1586909736.179988160] [/move_group] [ros.moveit_ros_move_group.ExecuteTrajectoryAction]: Execution request received
[ INFO] [1586909740.415661351] [/move_group] [ros.moveit_ros_planning.trajectory_execution_manager]: Completed trajectory execution with status SUCCEEDED ...
[ INFO] [1586909740.416120569] [/move_group] [ros.moveit_ros_move_group.ExecuteTrajectoryAction]: Execution completed: SUCCEEDED
[ INFO] [1586909740.546665110] [/move_group] [ros.moveit_ros_move_group]: Planning request received for MoveGroup action. Forwarding to planning pipeline.
[ INFO] [1586909740.547540873] [/move_group] [ros.moveit_planners_ompl.model_based_planning_context]: Planner configuration 'gp8' will use planner 'geometric::RRTConnect'. Additional configuration parameters will be set when the planner is constructed.
[ INFO] [1586909740.547845070] [/move_group] [ros.moveit_planners_ompl.ompl]: RRTConnect: Starting planning with 1 states already in datastructure
[ INFO] [1586909740.581315075] [/move_group] [ros.moveit_planners_ompl.ompl]: RRTConnect: Created 5 states (2 start + 3 goal)
[ INFO] [1586909740.581408520] [/move_group] [ros.moveit_planners_ompl.ompl]: Solution found in 0.033668 seconds
[ INFO] [1586909740.601466184] [/move_group] [ros.moveit_planners_ompl.ompl]: SimpleSetup: Path simplification took 0.019959 seconds and changed from 4 to 2 states
[ INFO] [1586909740.610784755] [/move_group] [ros.moveit_ros_move_group.ExecuteTrajectoryAction]: Execution request received
[ERROR] [1586909740.627931672] [/motion_streaming_interface] [ros.motoman_driver]: Validation failed: Trajectory doesn't start at current position.
[ERROR] [1586909746.076565021] [/move_group] [ros.moveit_ros_planning.trajectory_execution_manager]: Controller is taking too long to execute trajectory (the expected upper bound for the trajectory execution was 5.449322 seconds). Stopping trajectory.
[ INFO] [1586909746.076980042] [/move_group] [ros.moveit_simple_controller_manager.ActionBasedController]: Cancelling execution for 
[ INFO] [1586909746.077398550] [/move_group] [ros.moveit_ros_planning.trajectory_execution_manager]: Completed trajectory execution with status TIMED_OUT ...
[ INFO] [1586909746.077749015] [/move_group] [ros.moveit_ros_move_group.ExecuteTrajectoryAction]: Execution completed: TIMED_OUT
[ INFO] [1586909746.183255639] [/move_group] [ros.moveit_ros_move_group]: Planning request received for MoveGroup action. Forwarding to planning pipeline.
[ INFO] [1586909746.184755979] [/move_group] [ros.moveit_planners_ompl.model_based_planning_context]: Planner configuration 'gp8' will use planner 'geometric::RRTConnect'. Additional configuration parameters will be set when the planner is constructed.
[ INFO] [1586909746.185365340] [/move_group] [ros.moveit_planners_ompl.ompl]: RRTConnect: Starting planning with 1 states already in datastructure
[ INFO] [1586909746.210463678] [/move_group] [ros.moveit_planners_ompl.ompl]: RRTConnect: Created 4 states (2 start + 2 goal)
[ INFO] [1586909746.210578009] [/move_group] [ros.moveit_planners_ompl.ompl]: Solution found in 0.025435 seconds
[ INFO] [1586909746.224548478] [/move_group] [ros.moveit_planners_ompl.ompl]: SimpleSetup: Path simplification took 0.013711 seconds and changed from 3 to 2 states
[ INFO] [1586909746.229857645] [/move_group] [ros.moveit_ros_move_group.ExecuteTrajectoryAction]: Execution request received
[ INFO] [1586909749.071465919] [/move_group] [ros.moveit_ros_planning.trajectory_execution_manager]: Completed trajectory execution with status SUCCEEDED ...
[ INFO] [1586909749.071614210] [/move_group] [ros.moveit_ros_move_group.ExecuteTrajectoryAction]: Execution completed: SUCCEEDED

I have also attached the Wireshark capture, please let me know if this is not the format that is helpful. I am trying to look into how to translate the data of the packets. GP8_Wireshark_Capture.pcapng.tar.gz

On a similar note, is there a preferred method of sharing my packages over compressing and attaching the folder containing them?

I should mention I'm not able to share a github repo of my code because it is on our work repo, which I am not able to publicly post.

I don't have the interactive markers, which I was hoping was a separate issue... but I am able to plan and execute random poses through RViz just fine.

This comment makes me believe there is actually not a problem with the driver (other than the ones we already know about), but with your particular setup.

That doesn't mean it's not a problem, but it does change the scope of your support request.

Please open a new issue clearly describing what is going on, and refer to this one.

My first suggestion would be to go back to basics and use the bare motoman_gp8_support package with a basic MoveIt configuration and see whether that works. If it does -- which the comment I quoted above seems to imply -- then at least the driver and that part of the infrastructure works.

Let's not post more comments here as it starts to look like it seems your issue is only tangentially connected to this one.

I should mention I'm not able to share a github repo of my code because it is on our work repo, which I am not able to publicly post.

well this will make it (very) difficult for me to figure out what is going on. At the very least, an MWE would be needed.

I've just checked your wireshark capture but it does not seem to contain a message exchange for a failed attempt at trajectory execution.

Is this the correct capture @tanimfresh?

Hello,

I took some time to start a fresh work space and restart the process. This time I was not getting the OP error, so I am inclined to believe I must have made an incorrect edit along the way in my original workspace. I'm not able to pinpoint one specific change that caused the error for me, as despite trying to edit my initial setup piece by piece to replicate my fresh workspace I have not been able to remove the error from my initial setup.

One interesting point I noticed is that I did start seeing the same error in the new workspace when I tried to scale my motion plans to a set duration (by scaling the velocity, acc, and time_from_start of the planned trajectory). I saw a new error mentioning trajectory splicing was not implemented yet. After seeing this error, the OP error would appear more frequently on subsequent launch/execution of the system. Only after I rebooted the controller did the error stop appearing, and after adding the "inMotion" check I no longer see the trajectory splicing or OP error. Again, I tried to take these lessons to my initial workspace with no luck.

Thank you for all of your efforts and assistance.

I saw a new error mentioning trajectory splicing was not implemented yet. After seeing this error

this suggests your code submitted new trajectory goals before the previous one had finished executing.

But good to hear you got things to work in the end.

And finally: the fact you got it to work does not mean the issue described in the OP (and subsequent comments here) is fixed. It just means there are known work-arounds available.

Yes, after adding the inmotion check back I was good to go.

I agree, not solved, but a good troubleshooting step for those who may be reading this.

We had the same issue on a Motoman MH50 with a DX100 controller. It seems that the tolerance value start_pos_tol_ in motoman_driver/src/joint_trajectory_streamer.cpp is too conservative with $10^{-4} \ \mathrm{rad}$. In our case, the problem was resolved by increasing this value to $10^{-3} \ \mathrm{rad} = 0.057^\circ$, which is still rather small.

ros-industrial / motoman

driver: persistent (and incorrect) "Trajectory start position doesn't match current robot position" #111