While jogging only in Z axis the real UR5 robot in speed_unit mode, the trajectory of TCP doesn't keep straight in a line.

[stevensu1838]

Hi all, Have any of you encountered the following problems before while using the real robot？

When I move the robot 5 up and down by only sending velocity commands in Z, the TCP of UR5 doesn't keep going up and down in a straight line. However, it moves a bit in X direction as well.

When I move the robot 5 from side to side by only sending velocity commands in Y, the TCP of UR5 doesn't keep going in a straight line especially when the TCP goes further away from the base.

When I and go back to the teach pendant and move the TCP with the arrows in the page below, I don't see this issue at all.

Any suggestion will be appreciated.

My yaml：

gazebo: false # Whether the robot is started in a Gazebo simulation environment
collision_check: false # Check collisions?
command_in_type: "speed_units" # "unitless"> in the range [-1:1], as if from joystick. "speed_units"> cmds are in m/s and rad/s Steven changed this from "unitless" to "speed_units" 
scale: # Only used if command_in_type=="unitless"
  linear:  0.002  # Max linear velocity. Meters per publish_period. Units is [m/s] 0.002
  rotational:  0.0025  # Max angular velocity. Rads per publish_period. Units is [rad/s]
  joint: 0.006  # Max joint angular/linear velocity. Rads or Meters per publish period. Units is [rad/s] or [m/s]. 0.005
cartesian_command_in_topic:  jog_arm_server/delta_jog_cmds # Topic for xyz commands 0.006
joint_command_in_topic: jog_arm_server/joint_delta_jog_cmds # Topic for angle commands
command_frame:  base_link  # TF frame that incoming cmds are given in
incoming_command_timeout:  5  # Stop jogging if X seconds elapse without a new cmd
joint_topic:  joint_states
move_group_name:  manipulator  # Often 'manipulator' or 'arm'
lower_singularity_threshold:  30  # Start decelerating when the condition number hits this (close to singularity)
hard_stop_singularity_threshold: 45 # Stop when the condition number hits this
lower_collision_proximity_threshold: 0.1 # Start decelerating when a collision is this far [m] value was 45
hard_stop_collision_proximity_threshold: 0.005 # Stop when a collision is this far [m]
planning_frame: base_link  # The MoveIt! planning frame. Often 'base_link'
low_pass_filter_coeff: 6.  # Larger --> trust the filtered data more, trust the measurements less.
publish_period: 0.005  # 1/Nominal publish rate [seconds]
publish_delay: 0.001  # delay between calculation and execution start of command
# Publish boolean warnings to this topic
warning_topic: jog_arm_server/warning
joint_limit_margin: 0.1 # added as a buffer to joint limits [radians]. If moving quickly, make this larger.
command_out_topic: ur_driver/joint_speed
# What type of topic does your robot driver expect?
# Currently supported are std_msgs/Float64MultiArray (for ros_control JointGroupVelocityController)
# or trajectory_msgs/JointTrajectory (for Universal Robots and other non-ros_control robots)
command_out_type: trajectory_msgs/JointTrajectory
# Can save some bandwidth as most robots only require positions or velocities
publish_joint_positions: false
publish_joint_velocities: true
publish_joint_accelerations: false # Steven jogar

[AndyZe]

You could try a smaller low_pass_filter_coeffucient. It trades smoothness for accuracy.

[AndyZe]

I would like to replace that with a better algorithm if I ever find time.

[AndyZe]

Just curious -- are you changing directions abruptly or is your input a steady velocity?

And when you say it gets worse farther from the base -- how far from the base are you talking about? Almost fully extended? Half a meter?

[stevensu1838]

Hi Andy, Thanks a lot for your reply. I made the following video clip to explain to you the problem clearly. https://drive.google.com/file/d/1awvNQAo2OLpoMhCaioMYIDxfREc7ZyWn/view?usp=sharing I set all the other values 0 except for the value in Z direction in the spacenav_to_twist.cpp Since I am using a spacemouse, should the command_frame be base_link, ee_link or spacenav? Thanks a lot

[stevensu1838]

Hi Andy, Please find the linked the video to check it out what happens in the y-direction. https://drive.google.com/file/d/12tRz7Fq496RwmhX54DxyEzqJYUu7J4dQ/view?usp=sharing Could this be caused by the hardware(the robot)? I kind of reply on your package to do my research. Thanks you so much for your help.

I am changing directions between Y+ and Y- when I jog the arm a few seconds. And the input from space mouse is smaller than 1 but not a steady value. It is in speed unit mode.

And when I say it gets worse farther from the base, it is not as far as almost fully extended. It is within half a meter.

[stevensu1838]

Hi Andy, Haven't got the opportunity to try this on another UR5. So I'd love to offer you more info on this UR5 I am using. First, in the clip below, you can see the jogging in Y direction. It works ok when the TCP is driven around this area within working space. https://drive.google.com/file/d/1yDklMRvXS-bsvJlocxL5I3rMcXcxUq0v/view?usp=sharing I thought if I started jogging in any direction around this area, the TCP would go straight lines. So I tried jogging in Z after the video shown above. But I was wrong. The arm doesn't just go straight up and down, I was just sending velocity commands in Z, though https://drive.google.com/file/d/1zXw1BN-5B9rNQW4Axr6kzQc4VComD1BZ/view?usp=sharing https://drive.google.com/file/d/1-y6v3DDA07snF6FGdyZPl18yLX1Ydlu7/view?usp=sharing

I tried both

roslaunch ur_modern_driver ur5_bringup.launch robot_ip:=ROBOT_IP_ADDRESS roslaunch ur_modern_driver ur5_ros_control.launch robot_ip:=ROBOT_IP_ADDRESS Same result.

For welding, I have to make sure the TCP go straight. Can you help?

Thanks a lot

[stevensu1838]

Hi Andy, I reinstalled ur_mordern_driver and jog_arm and this problem disappeared somehow. Please do not waste your time on this issue. When I figured out why I would keep this it updated. Thank you so much from the bottom of my heart.

Steven

[AndyZe]

That's strange but I'm glad you found a solution.