What determines the successful end of a trajectory

asked 2019-08-09 14:42:08 -0500

bakerhillpins
76 ●4 ●6 ●10

updated 2022-01-22 16:10:02 -0500

Evgeny
26 ●6

Ok, Time to ask for help: (Using ROS in Windows/melodic)

I'm working on creating a ROS-i robot support package based upon reading their FAQ/Tutorials (http://wiki.ros.org/Industrial/Tutorials). I've got the support package and the basic moveit/Rviz package running. I'm working on the driver package, specifically getting it to talk to the hardware/robot and follow a trajectory. I've, for the most part, used the Fanuc robots (http://wiki.ros.org/fanuc_driver) as an example when I didn't understand a concept and that's helped a lot. The Status/State and Trajectory servers of the driver seem to be working quite well and the robot is executing the planned trajectory as as series of Joint Trajectory Point messages. Problem is I always get the "taking too Long" error:

[/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 32.060151 seconds). Stopping trajectory.'

At first this problem was simply due (I assume) to the fact that I had a joint velocity specified in my URDF/joint_velocities.yaml that were way too aggressive for the robot. However, I've adjusted the joint velocities and now the movement completes well within the expected time (Note the 32 seconds limit). Problem is that I am still getting the error message. I've been trying to validate my low level driver implementation which is based upon the examples in the industrial_core package. I've searched extensively and can't come up with anything that succinctly describes the exact message passing progression expected for the ROS-i Joint_Trajectory_Streamer component (or any other one for that matter) that's feeding the messages to my driver so I am unsure if I've implemented it fully.

Beyond that, Searching on the error hasn't been fruitful either. I've learned how to disable in the launch file (which I don't want to do but it did work when utilized) and other sources including the Fanuc Trouble shooting pages only ever suggest issues with slow robots. (http://gavanderhoorn.github.io/fanuc-...) Unfortunately, the solutions only discuss skipping the timeout check or adjusting your velocities.

I'm probably using poor search terms and or just looking past the answer when digging through trajectory_execution_manager information. I have attempted to peruse the code but that's getting confusing and I think I'm just fried because I don't understand what the robot needs to provide when to satisfy it's needs at the end of a trajectory.

I'm wondering if anyone can tell me specifically what the trajectory_execution_manager is looking for to determine that the robot has successfully completed the published trajectory? And by extension, what should my Robot driver be supplying that ultimately is published back to the trajectory_execution_manager to satisfy that.

answered 2019-08-15 12:42:13 -0500

bakerhillpins
76 ●4 ●6 ●10

I was able to figure out what the system was looking for after a lot of thrashing. Man I wish all the ROS documentation wasn't quite so scattered because it makes it amazingly frustrating to figure out what is going on.

The error listed above (Controller is taking too long to execute trajectory) is kind of a red herring in that it's being reported by the trajectory_execution_manager. It seems like that's the node that's important in all of this but it really has nothing to do with it other than timing the operation out. It's buried down in a lot of abstraction and if there was something that builds the relationships in documentation I couldn't put it together. I think it's all layered behind some Action and Goal handles that I never could really resolve across all the packages. Regardless, I ended up spending more time upping my ROS logging fu using rqt_console and basically searching through packages for output strings.

That lead me to the joint_trajectory_action node and I was able to determine after code inspection that it was using theconstraints/goal_threshold parameter to window the end position of the controller. Setting this param in the parameter server to a value that fit our robot allowed it to finish properly.

Now that type of parameter is not all that unusual for a motion control system and I was looking for something like that early on but unfortunately there isn't any Wiki page for the ROS-i industrial_robot_client that discusses the joint_trajectory_action node that I found. The parameters described at the ROS Wiki only relate to the PR2 apparently, but at the time I didn't make that connection. My recollection was that all of the industrial_robot_client code was ported over from ROS code that originated from the PR2. But I'm not going to try to find that which gave me that impression again.

So in the end it appears that there are 2 things that the system (the ROS-i moveit package format anyway) uses to determine that the trajectory is done or not. A total trajectory time, and a window for the end position of the joints.

edit flag offensive delete link

Comments

You've almost reached the correct conclusion (and I'm sorry you had such a difficult time arriving at it): the joint_trajectory_action exposes a FollowJointTrajectory action server, which when sent a JointTrajectory will try to execute that trajectory using the state and trajectory relays. It uses tolerances on all joints to determine whether it has completed execution of the trajectory.

That is the first part.

MoveIt has the execution manager, which you found. It has it's own infrastructure for tracking execution status and it will act whenever it detects a tracking error (in time, as well as in space iirc).

It's this last one that you ran into ("controller taking too long" is MoveIt saying: the FollowJointTrajectory action server I've sent the trajectory to is taking too long to report completion, at least according to the timing information that MoveIt has).

That's the second part.

So ...(more)

gvdhoorn ( 2019-08-17 04:58:39 -0500 )edit

Finally:

I'm working on creating a ROS-i robot support package based upon reading their FAQ/Tutorials (http://wiki.ros.org/Industrial/Tutorials).

as the approach that was taken for the older drivers (ie: using Simple Message et al) is not something that is still often being used, those tutorials have gotten a bit stale. They should be updated, or at least their status should be made more clear.

I'm working on the driver package, specifically getting it to talk to the hardware/robot and follow a trajectory

out of curiousity: may I ask what robot/controller you're working with?

gvdhoorn ( 2019-08-17 05:00:55 -0500 )edit

You've almost reached the correct conclusion

I'm trying to understand what's different between our answers. You've supplied extra info about the action server but in the end the joint_trajectory_action is testing tolerance (one value applied to all joints) and the trajectory_execution_manager is timing it out? You mention it's also windowing the position/path followed but I don't see that happening or am missing the tolerance parameter for that node?

as the approach that was taken for the older drivers (ie: using Simple Message et al) is not something that is still often being used, those tutorials have gotten a bit stale.

So that's unfortunate and confusing because that's what ROS-i seems to be promoting no? What's considered the correct implementation?

out of curiousity: may I ask what robot/controller you're working with?

We are using the Dobot Magician. Since there ...(more)

bakerhillpins ( 2019-08-21 14:45:44 -0500 )edit

add a comment

What determines the successful end of a trajectory

1 Answer

Comments

Question Tools

Stats

Related questions

What determines the successful end of a trajectory edit

1 Answer

Comments

Question Tools

Stats

Related questions

What determines the successful end of a trajectory