streamer crashing when sending trajectory

[wsnewman]

The joint trajectory streamer is crashing with error code 11 when we try to manually send a joint trajectory via a rostopic pub.

On the recommendation of gvdhoorn, we are posting an issue based on this ROS Answers post.

Here are our steps to recreate the problem:

1. We load the robot model:

$roslaunch motoman_mh50_support load_mh50.launch''

Link to the above code's source

2. we run a launch file for the streamer:
   $roslaunch motoman_mh50_support robot_interface_streaming_mh50.launch robot_ip:=192.168.1.31 controller:=dx200

At this step, we get an error message on console:

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

3. we manually send a joint trajectory message:

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

And this error message results:

[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

We have since fixed this issue by editing joint streaming node

and changing:

motionInterface.init("", FS100_motion_port, false);

to
motionInterface.init("", FS100_motion_port, true);

[gavanderhoorn]

It would be great if you could provide a gdb backtrace when it's actually crashing.

Be sure to build with CMAKE_BUILD_TYPE=Debug, or else the symbols will not be there.

[gavanderhoorn]

As to the fix suggested: I'm not sure that should be required. The idea is that no changes to the node source are necessary to configure the driver for use with different robot configurations. If there are, that would be a sign of something not being implemented correctly.

[wsnewman]

Looks like the "version0" T/F bool was intended to be passed down to this node from launch. However, the node has "false" hard coded. Our temporary fix was to change "false" to "true" hard coded and recompile. But that is not a general solution--just a hint at the source of the problem. Anyway, after making this change, we could follow the tutorial and use the python test function, e.g.: rosrun motoman_driver move_to_joint.py "[0,0,0,0,0,0]" , as well as a raw: rostopic pub /joint_path_command trajectory_msgs/JointTrajectory ... to get the robot moving.

…

On Tue, Jul 3, 2018 at 10:19 AM, G.A. vd. Hoorn ***@***.***> wrote: As to the fix suggested: I'm not sure that should be required. The idea is that no changes to the node source are necessary to configure the driver for use with different robot configurations. If there are, that would be a sign of something not being implemented correctly. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#228 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AKAK2ASQvbxv8yzVx8hyekr2OmMuioXKks5uC32IgaJpZM4VBCW1> .

-- Wyatt Newman, Ph.D., P.E. Professor, EECS Dept Case Western Reserve University Cleveland, OH 44106 216-368-6432 wyatt.newman@case.edu

[gavanderhoorn]

version0 is no longer used, the method signature is there for bw-compatibility reasons.

Configuration of the driver is done using various yaml files, and based on the content version0 is set.

Can you share your configuration? Did you create a configuration with the topic_list parameter set?

A backtrace would still be very welcome.

[wsnewman]

Setting this parameter actually caused us different errors. Namely, a complaint about expecting DynamicJointTrajectory messages, when we were using JointTrajectory messages.

Is this parameter meant to always be set? We spoke to a friend who has been through this process, and he suggested that it is just for the multi-robot case. Documentation is a little sparse on this topic, though.

[gavanderhoorn]

There are two sides to the driver:

1. single group
2. multi-group

the former will accept JointTrajectory msgs, the latter only DynamicJointTrajectory msgs.

As most people will always use the joint_trajectory_action node to interface with the driver, they are never exposed to this difference. The action server accepts FollowJointTrajectory goals which it then sends to the correct topics exposed by the driver, after converting trajectories to the correct type.

If you want to bypass the JTA node, then you'll have to send the correct type of message. There is no way around that.

Could you perhaps clarify a bit why you don't want to use the action server?

We spoke to a friend who has been through this process, and he suggested that it is just for the multi-robot case.

that is technically true, but it would work with single motion-group setups as well.

[wsnewman]

In bringing up a robot for the first time, it is convenient to use incremental steps. I liked the tutorial's explanation of how to do a low-level test with rosrun motoman_driver move_to_joint.py ... However, this no longer works, which was frustrating. But we managed to reverse-engineer the barrier and get through it. I likely will end up using the action server. But there was no corresponding action-client test function (and no tutorial) to help us bring up a new robot via the action server. I suggest it would be useful to update move_to_joint.py and update the tutorial. We did waste substantial time trying to get this to run. We are probably not the only ones who will get frustrated by this. However, we have motion now. So we're good. We do appreciate your responses. Perhaps others will appreciate this thread.

…

On Tue, Jul 3, 2018 at 10:44 AM, G.A. vd. Hoorn ***@***.***> wrote: There are two sides to the driver: 1. single group 2. multi-group the former will accept JointTrajectory msgs, the latter only DynamicJointTrajectory msgs. As most people will always use the joint_trajectory_action node to interface with the driver, they are never exposed to this difference. The action server accepts FollowJointTrajectory goals which it then sends to the correct topics exposed by the driver, after converting trajectories to the correct type. If you want to bypass the JTA node, then you'll have to send the correct type of message. There is no way around that. Could you perhaps clarify a bit why you don't want to use the action server? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#228 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AKAK2IqglfAgpTP8tBMTM6b98nhtkkI0ks5uC4NWgaJpZM4VBCW1> .

-- Wyatt Newman, Ph.D., P.E. Professor, EECS Dept Case Western Reserve University Cleveland, OH 44106 216-368-6432 wyatt.newman@case.edu

[gavanderhoorn]

We did waste substantial time trying to get this to run. We are probably not the only ones who will get frustrated by this.

In general I would suggest to report this sort of issue earlier. We are all here to help, but if we don't know you are encountering problems, we cannot help you. We also cannot fix things.

As to your suggestion: that is certainly a good idea.

I likely will end up using the action server.

In a way, not using the action server is actually discouraged. Even though there are separate nodes, they're really only typically used in combination.

[gavanderhoorn]

Tracking the suggestion to add an action client example in #229.

[gavanderhoorn]

It would still be very nice if you could add a backtrace to this issue, so we can debug the issue with the driver crashing with your configuration.

[Berti006]

I think I have a similar problem, but changing the line

motionInterface.init("", FS100_motion_port, false);

to "true" did not help. If I do:

roslaunch motoman_driver robot_interface_streaming_dx200.launch robot_ip:=192.168.255.1`

I get back:

ROS_MASTER_URI=http://localhost:11311
process[joint_state-1]: started with pid [7992]
process[motion_streaming_interface-2]: started with pid [7993]
process[joint_trajectory_action-3]: started with pid [7998]
[ERROR] [1531831711.240224032]: Failed to find topic_list parameter
[ERROR] [1531831711.258239340]: Failed to find topic_list parameter

Any suggestions why that happens? I strictly followed the motoman_driver- Usage tutorial. Funny thing is, it worked a few weeks ago.. I just reinstalled ros-kinetic.

Perhaps @gavanderhoorn you have a clue?

[wsnewman]

Perhaps you fixed this already. As you noted, we modified the motion streaming interface to set the `version0` boolean to `"true"` In addition, we modified the higher-level launch file (for DX200, in our case) robot_interface_streaming.launch to comment out start-up of the action server (which looks for a topic_list on the parameter server). I modified as follows: <!-- joint_trajectory_action: provides actionlib interface for high-level robot control --> <!-- WSN: eliminate action server.... <node if="$(arg version0)" name="joint_trajectory_action" pkg="industrial_robot_client" type="joint_trajectory_action" /> <node unless="$(arg version0)" name="joint_trajectory_action" pkg="motoman_driver" type="motoman_driver_joint_trajectory_action" /> --> I realize this is hideous and breaks code re-use and standardization. But we had to move forward quickly, and this hack got us running. I hope you have similar success.

[gavanderhoorn]

Changing the code should not be necessary, and if it is, then something is wrong (and it should be fixed). Without a backtrace, I couldn't start to diagnose the problem reported by @wsnewman however.

I don't believe you get a crash @Berti006, is that correct?

I'll be able to take a look at all of this next week, right now I'm on travel. If you can make your configuration available @Berti006 that would help. Personally I always create an application-specific configuration package that contains the joint names to use and a wrapper launch file that loads everything (ie: the correct robot_interface_streaming_...launch file). Do you have something like that?

[Berti006]

If I use the latest version I also get a crash when sending:
rosrun motoman_driver move_to_joint.py "[-0.5, -1.4, -1.0, 0.3, -0.8, 1.0]"
results in:

[ERROR] [1531987897.956109]: Start and End position joint_names mismatch
[ERROR] [1531987897.957380]: Unable to move to commanded position. Aborting.
Traceback (most recent call last):
  File "~/catkin_ws/src/motoman-kinetic-devel/motoman_driver/src/move_to_joint.py", line 133, in <module>
    main(sys.argv[1:])
  File "~/catkin_ws/src/motoman-kinetic-devel/motoman_driver/src/move_to_joint.py", line 127, in main
    move_to_joint(end_pos, duration)
  File "~/catkin_ws/src/motoman-kinetic-devel/motoman_driver/src/move_to_joint.py", line 69, in move_to_joint
    traj = build_traj(get_cur_pos(), end_pos, duration)
  File "~/catkin_ws/src/motoman-kinetic-devel/motoman_driver/src/move_to_joint.py", line 25, in build_traj
    raise
TypeError: exceptions must be old-style classes or derived from BaseException, not NoneType

I tried to change the joint_names ( rosparam set controller_joint_names "[J1, J2, J3, J4, J5, J6]")
but it did not solve the problem. (everything follows the tutorial)

I also followed the tutorial to get the basic functionalities up and running. That's why I also use the robot_interface_streaming_dx200.launch file
Please keep in mind that I already had everything running about 1-2 months ago, perhaps something changed and leads now to this error.

But from your previous answer I think it might be better to use the joint_trajectory_action node. I also focused to much on the beginners tutorial (which means I also encourage building up another tutorial ;) )

Thanks for your help ;)