ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question
0

The data about the current position of the robot (UR5) changes with a lower frequency than that with which the pose is commanded

asked 2021-01-28 08:05:29 -0500

UliaM gravatar image

I want to evaluate how good the UR5 follows the commanded trajectory. The cartesian motion controller: link text is used in this specific task. I created a .txt file in which I defined the exact poses that the UR5 must have to describe a square. Each pose is given as an input to the controller with a frequency of 120 Hz. To evaluate the effective robot pose I created a TransformListener object and, with a frequency of 120 Hz, I queried the listener for a specific transformation, as follow:

geometry_msgs::TransformStamped transformStamped;
try{
    transformStamped = tfBuffer.lookupTransform("base", "tool0", ros::Time(0));
}
catch (tf2::TransformException &ex) {
    ROS_WARN("%s",ex.what());
    ros::Duration(1.0).sleep();
    continue;
}
reached_pose.publish(transformStamped);

This information is published on the topic /reached_pose (created for this scope) with a frequency of 120 Hz.

I use the rosbag package to record two pieces of information:

  • The commanded poses from the /my_cartesian_motion_controller/target_frame topic
  • The reached poses from the /reached_pose topic

Plotting the results, I noticed that the poses commanded to the UR5 and the poses reached by the robot are published on the topics with a correct frequency of 120 Hz. Hovewer, the information about the present state of the robot remains the same for 5/6 samples despite the commanded pose changes. Seems that the listener returns the latest available transform in the buffer, but the buffer is updated with a frequency of 20 Hz.

In order to publish a tf for each of the received joint_states, I set the parameter "ignore_timestamp" of "robot_state_publisher" to "true"; in this way the "publish_frequency" and the timestamp of joint_states are ignored. The situation is the same. joint_state works at 125 Hz.

What could be the problem?

Thanks!

edit retag flag offensive close merge delete

2 Answers

Sort by ยป oldest newest most voted
0

answered 2021-02-01 15:21:04 -0500

UliaM gravatar image

updated 2021-02-01 15:31:57 -0500

Hi, thanks for your response.

I have already checked the tf tree and verified that there aren't limiting factors: the highest latency link is published with a frequency of 110 Hz. I have also increased the buffer size, but I have the same problem.

Can I do something else to solve the problem?

Hovewer, the information about the present state of the robot remains the same for 5/6 samples despite the commanded pose changes. Seems that the listener returns the latest available transform in the buffer, but the buffer is updated with a frequency of 20 Hz.

I modified the code in order to save past data, as following:

geometry_msgs::TransformStamped transformStamped;
try{
     ros::Time past = ros::Time::now() - ros::Duration(5.0);
    transformStamped = tfBuffer.lookupTransform("base", "tool0", past);
}
catch (tf2::TransformException &ex) {
    ROS_WARN("%s",ex.what());
    ros::Duration(1.0).sleep();
    continue;
}

Why I can't observe the 5/6 samples repetition in this case?

Thanks!

edit flag offensive delete link more

Comments

Please use comments to follow up, not a new answer. If you want more help you'll need to provide more information to the point of a reproducible example. The tf tree is the state of the buffer which is what the lookupTransform is querying so I suspect that you're overlooking something. There may be synchronization issues or timestamp validity issues to look at.

tfoote gravatar image tfoote  ( 2021-02-01 15:36:01 -0500 )edit
0

answered 2021-02-01 11:50:49 -0500

tfoote gravatar image

When you ask for time zero. It is translated to be requested as the latest common time that's available as a transform. This means that it is going to give you the most recent transform available at a common time that spans the tree between the frames requested. What you are seeing is that the results will only updated when the highest latency link is published. The system cannot include new information until there's a consistent timestamp across all links. So to improve this you need to check what your limiting factor is.

The best way to look at this is to check the tf tree using the tool view_frames as mentioned in this tutorial: http://wiki.ros.org/tf2/Tutorials/Deb...

In that tool you'll want to find the link which is your limiting factor.

edit flag offensive delete link more

Question Tools

2 followers

Stats

Asked: 2021-01-28 05:28:03 -0500

Seen: 266 times

Last updated: Feb 01 '21