motoman industrial ROS streamer crashing when sending trajectory

asked 2018-06-29 10:49:18 -0600

wsnewman gravatar image

We are attempting to command a Motoman MH50 robot with ROS industrial. We were able to command the robot to arbitrary positions with a (Windows) test GUI from Motoman, so it appears our low-level communications is working. However, the ROS interface from Linux is not working. When sending trajectory commands, the streamer crashes (and leaves no log messages).

Here is our process:

1) we start up the Motoman controller with the INIT_ROS job running.

2) we run a launch file to load the robot model:

$roslaunch motoman_mh50_support load_mh50.launch

link to the package containing this file

3) we run a launch file for the streamer:

$roslaunch motoman_mh50_support robot_interface_streaming_mh50.launch robot_ip:= controller:=dx200

We get errors saying

"[ERROR] [1530281183.991488318]: Failed to find topic_list parameter"

But we think this is a red herring.

So far (other than the topic_list error), all seems OK, and we can do

$rostopic echo joint_states.

However, we still can't get the streamer to accept trajectory commands. We tried:

rostopic pub /joint_path_command trajectory_msgs/JointTrajectory \
"{joint_names: ['joint_1_s', 'joint_2_l', 'joint_3_u', 'joint_4_r', 'joint_5_b', 'joint_6_t'], \
points: [ \
{time_from_start: {secs: 0.1}, \
positions: [0.0, 0.0, -8.751316272537224e-06, 0.0, -1.917476038215682e-05, 0.0],
velocities: [0,0,0,0,0,0]},\
{time_from_start: {secs: 1}, \
positions: [0, 0, 0, 0, 1, 0],
velocities: [0,0,0,0,0,0]}\
]}" -1

but the streamer crashes with the message:

[motion_streaming_interface-2] process has died [pid 18220, exit code -11, cmd /home/wyatt/ros_ws/devel/lib/motoman_driver/motion_streaming_interface __name:=motion_streaming_interface __log:=/home/wyatt/.ros/log/ca41b9da-7ba4-11e8-8b21-d4bed9452afe/motion_streaming_interface-2.log].
log file: /home/wyatt/.ros/log/ca41b9da-7ba4-11e8-8b21-d4bed9452afe/motion_streaming_interface-2*.log

unfortunately, the referenced log file is empty, so no clues there.

We also tried using the python program:

$rosrun motoman_driver "[0,0,0,0,0,0]"


We had to edit this to make the joint names consistent with the URDF, controller_joint_names parameter and the names echoed from /joint_states. We also created a new parameter, /joint_names, with the same joint names, since the python code seems to require this. Anyway, the python code runs, after these changes, and it publishes what seems to be a viable trajectory command, an echo of which is:

$rostopic echo /joint_path_command


  seq: 1
    secs: 0
    nsecs:         0
  frame_id: ''
joint_names: ['joint_1_s', 'joint_2_l', 'joint_3_u', 'joint_4_r', 'joint_5_b', 'joint_6_t']
    positions: [0.0, 0.0, -8.751316272537224e-06, 0.0, -1.917476038215682e-05, 0.0]
    velocities: [0.0, 0.0, 0.0, 0.0, 0.0, 0.0]
    accelerations: []
    effort: []
      secs: 0
      nsecs:         0
    positions: [0.0, 0.0, 0.0, 0.0, 0.0, 0.0]
    velocities: [0.0, 0.0, 0.0, 0.0, 0.0, 0.0]
    accelerations: []
    effort: []
      secs: 10
      nsecs:         0

However, this causes streamer to crash with:

 [motion_streaming_interface-2] process has died [pid 21021, exit code -11, cmd /home/wyatt/ros_ws/devel/lib/motoman_driver/motion_streaming_interface __name:=motion_streaming_interface __log:=/home/wyatt/.ros/log/47b9f908-7bab-11e8-a2bb-03f9c8d8cfb7/motion_streaming_interface-2.log].
log file: /home/wyatt/.ros/log/47b9f908-7bab-11e8-a2bb-03f9c8d8cfb7/motion_streaming_interface-2*.log

Does anybody know why or what we can do?

edit retag flag offensive close merge delete


The fact that it crashes is not very nice. -11 is basically SEGFAULT, so something is not right.

Please report this as an issue over at ros-industrial/motoman. We'll diagnose this there.

Please include the output of roslaunch --screen ...

gvdhoorn gravatar imagegvdhoorn ( 2018-06-29 11:35:22 -0600 )edit

Btw: the trajectories you show are somewhat strange. The first makes joint_b rotate 1 rad in 1 sec, the second basically goes from almost 0 to 0 in 10 sec.

I would also recommend to go through the joint_trajection_action, instead of directly publising JointTrajectories, but it ..

gvdhoorn gravatar imagegvdhoorn ( 2018-06-29 11:40:58 -0600 )edit

.. it supported.

The JointTrajectoryAction server performs some additional checks that now fall under your responsiblity if you publish to motion_streaming_interface topics directly.

gvdhoorn gravatar imagegvdhoorn ( 2018-06-29 11:41:39 -0600 )edit

Can you comment on the appropriate use of @gvdhoorn? We are currently working on an action client to test your advice, but would be interested in using this script as a diagnostic tool if possible.

KBradner gravatar imageKBradner ( 2018-06-29 11:59:55 -0600 )edit

The trajectories we tested were unusual just because we wanted a safe but arbitrary motion to validate our ability to make commands from Ros to the dx200. If there is an easier way to accomplish this, we would be happy to know about it.

KBradner gravatar imageKBradner ( 2018-06-29 12:03:52 -0600 )edit

re: action client: you could take a look at the script in ros-industrial/universal_robot. But it's a standard action client. Just make sure to include the current JointState of the robot as the first point.

gvdhoorn gravatar imagegvdhoorn ( 2018-06-29 12:08:09 -0600 )edit

And again: please report this as an issue on the tracker, and include the output of a roslaunch with the --screen parameter and a gdb backtrace. Be sure to compile with Debug build type.

And you should be able to compile kinetic-devel on Indigo.

gvdhoorn gravatar imagegvdhoorn ( 2018-06-29 12:09:08 -0600 )edit

We will get that issue up shortly. The actual development PC is not on wifi at the moment. In the meantime, we just tried making up a topic list parameter to get rid of that complaint from the launch file. Could the -11issue be that joint_trajectory_action.cpp's loop after it checks for a topic list

KBradner gravatar imageKBradner ( 2018-06-29 12:30:06 -0600 )edit