Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

streamer crashing when sending trajectory #228

Open
wsnewman opened this issue Jul 3, 2018 · 14 comments
Open

streamer crashing when sending trajectory #228

wsnewman opened this issue Jul 3, 2018 · 14 comments
Labels

Comments

@wsnewman
Copy link

wsnewman commented Jul 3, 2018

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

  1. 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

  1. 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
Copy link
Member

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
Copy link
Member

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.

@gavanderhoorn gavanderhoorn added bug more-info-needed Waiting on additional information from poster labels Jul 3, 2018
@wsnewman
Copy link
Author

wsnewman commented Jul 3, 2018 via email

@gavanderhoorn
Copy link
Member

gavanderhoorn commented Jul 3, 2018

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
Copy link
Author

wsnewman commented Jul 3, 2018

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
Copy link
Member

gavanderhoorn commented Jul 3, 2018

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
Copy link
Author

wsnewman commented Jul 3, 2018 via email

@gavanderhoorn
Copy link
Member

gavanderhoorn commented Jul 3, 2018

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
Copy link
Member

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

@gavanderhoorn gavanderhoorn removed the more-info-needed Waiting on additional information from poster label Jul 3, 2018
@gavanderhoorn
Copy link
Member

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
Copy link

Berti006 commented Jul 17, 2018

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
Copy link
Author

wsnewman commented Jul 19, 2018 via email

@gavanderhoorn
Copy link
Member

gavanderhoorn commented Jul 19, 2018

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
Copy link

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 ;)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Development

No branches or pull requests

3 participants