UR10 Jerky Movements with the Universal_Robots_ROS_Drivers

asked 2021-01-12 15:42:38 -0500

StewartHemm74
46 ●12 ●17 ●21

updated 2021-01-13 07:21:09 -0500

To Whom It May Concern,

I'm trying to use the ur10 CB series with polyscope version 3.12, Universal_Robots_ROS_Driver, ROS-Kinetic, Ubuntu 16.04. I do not want to use moveit to control the hardware. I want to use my own optimal controller to send joint velocity commands to the UR10. I have changed the ur10_bringup.launch file so that the joint_group_vel_controller is started.

ur10_bringup.launch file:

<?xml version="1.0"?>
<launch>
    <arg name="debug" default="false" />
    <arg name="robot_ip"/>
    <arg name="reverse_port" default="50001"/>
    <arg name="script_sender_port" default="50002"/>
    <arg name="tf_prefix" default="" doc="tf_prefix used for the robot."/>
    <arg name="controllers" default="joint_state_controller scaled_pos_joint_traj_controller 
        speed_scaling_state_controller force_torque_sensor_controller"/>
    <arg name="stopped_controllers" default="pos_joint_traj_controller joint_group_vel_controller"/>
    <arg name="controller_config_file" default="$(find ur_robot_driver)/config/ur10_controllers.yaml"/>
    <arg name="robot_description_file" default="$(find ur_description)/launch/ur10_upload.launch"/>
    <arg name="kinematics_config" default="$(find ur_description)/config/ur10_default.yaml"/>
    <arg name="limited" default="false"/>
    <arg name="headless_mode" default="false"/>

    <include file="$(find ur_robot_driver)/launch/ur_common.launch" pass_all_args="true">
    <arg name="use_tool_communication" value="false"/>
</include>

I've confirmed my control rate is publishing commands to the joint_group_vel_controller/command at ~125HZ. First, why are script_sender_port & reverse_port default values 50002 & 50001 respectively? In the official remote control Universal Robots support articles (https://www.universal-robots.com/arti... ), it states to use ports 30* for reading & writing data. It never mentions any values in the 50* range, so where did the 50001 & 50002 values come from?

Lastly, I've confirmed my optimal controller can properly interpret joint position & velocity commands in Gazebo. The ur10 will move in the simulation whenever a command is sent, and there are no jerky/vibrating motions. When, I test on actual hardware the joint velocity commands are smooth, however the joint positions commands cause the non-smooth motion to occur. Should I look at optimizing my PID gains? Do you have any recomendation on where to look to optimize these values for a ur10, or a baseline to start at?

I would apperciate any support trying to get smoother motion.

edit retag flag offensive close merge delete

add a comment

2 Answers

Sort by » oldest newest most voted

answered 2021-01-13 03:54:20 -0500

gvdhoorn
86574 ●283 ●1432 ●1054 http://cor.tudelft.nl/

updated 2021-01-13 07:48:04 -0500

First:

First, why are script_sender_port & reverse_port default values 50002 & 50001 respectively? In the official remote control Universal Robots support articles (https://www.universal-robots.com/arti... ), it states to use ports 30* for reading & writing data. It never mentions any values in the 50* range, so where did the 50001 & 50002 values come from?

Please refrain from doing this in future questions. The title of your question mentions jerky movement, but then you ask specific details about some of the networking infrastructure used. ROS Answers is a Q&A site, which works best with a 1-to-1 ratio of questions and answers. Including multiple questions in a single post doesn't work.

Having written that: tcp://:50001 and tcp://:50002 serve a very different purpose from the ports you refer to. They don't carry the same information and are specific to how the driver works. They are used for sending data to the controller, and must be opened on the ROS side, as URScript cannot listen on sockets, only connect.

I've confirmed my optimal controller can properly interpret joint position & velocity commands in Gazebo. The ur10 will move in the simulation whenever a command is sent, and there are no jerky/vibrating motions.

That's nice, but almost irrelevant. Gazebo doesn't simulate the controller, networking infrastructure nor URScript or the URCap. Dynamic behaviour of the robot will be only approximately comparable. Using Gazebo is a good first step, but I would not take the fact that things "work in there" as conclusive evidence everything is OK with your code.

When, I test on actual hardware the joint velocity commands are smooth, however the joint positions commands cause the non-smooth motion to occur. Should I look at optimizing my PID gains? Do you have any recomendation on where to look to optimize these values for a ur10, or a baseline to start at?

seeing as you're writing a controller, here are a few observations / comments:

please realise that you have ROS messaging between your node and the driver (I assume you implemented your controller in a node, as you mention the joint_group_vel_controller), this will increase jitter, depending on system and networking load
(time)synchronising a node and another node is non-trivial: how have you implemented this? Are you closing the loop using the /joint_states topic?
as you mention "I want to use my own optimal controller to send joint velocity commands to the UR10", I would actually recommend implementing your controller as a ros_control controller, instead of a separate node. That would remove jitter due to messaging and scheduling, and would run your controller at the exact frequency needed for your robot with minimal delay and jitter.

Finally: I'll repeat the recommendation @Rufus posted: if you haven't yet, please build and use a real-time capable kernel. Smooth control requires low-latency and minimum jitter, which a regular kernel will most likely not be able to support.

Edit:

I thought the PREEMPT_RT patched kernel was ...

(more)

edit flag offensive delete link

Comments

Thanks for responding,

I thought the PREEMPT_RT patched kernel was only needed for the UR E-series? Is there a guide for installing the real time kernels on a Linux machine? I've used the ReadMe from the UR_ROS, and that installation process causes my monitor to display large icons. I'm working with a CB series. Yes, I am using closed loop control, and reading the joints states from the topic mentioned above.

I would actually recommend implementing your controller as a ros_control controller, instead of a separate node. That would remove jitter due to messaging and scheduling, and would run your controller at the exact frequency needed for your robot with minimal delay and jitter."

Is there an example of adding custome controller ros control to serve as a baseline?

StewartHemm74 ( 2021-01-13 07:28:03 -0500 )edit

Is there a guide for installing the real time kernels on a Linux machine? I've used the ReadMe from the UR_ROS, and that installation process causes my monitor to display large icons.

this seems like it would be a different question.

I'd suggest posting an issue on the UR tracker if you have problems doing this. But it sounds like a problem with system configuration, not with anything UR specific, so perhaps a forum like Ask Ubuntu would be more appropriate.

gvdhoorn ( 2021-01-13 07:44:21 -0500 )edit

Thank you!

StewartHemm74 ( 2021-01-13 07:46:55 -0500 )edit

add a comment

answered 2021-01-12 20:00:09 -0500

Rufus
1083 ●45 ●102 ●89

Try running with PREEMPT_RT patched kernel

Realtime-enabled communication structure to robustly cope with the 2ms cycle time of the e-Series. To use this, compile and run it on a kernel with the PREEMPT_RT patch enabled. (See the Real-time setup guide on how to achieve this)

From https://github.com/UniversalRobots/Un...

edit flag offensive delete link

Comments

Thanks for responding,

I thought the patched kernel was only needed for running a program on the UR-Eseries. Is it necessary for the CB series? Also, how do I know which kernel is necessary on my Linux machine? I've never installed the RT kernels successfully on a machine, most of the time the kernel causes weird display issues on my monitors.

StewartHemm74 ( 2021-01-13 07:35:40 -0500 )edit

add a comment

UR10 Jerky Movements with the Universal_Robots_ROS_Drivers

2 Answers

Comments

Comments

Question Tools

Stats

Related questions

UR10 Jerky Movements with the Universal_Robots_ROS_Drivers edit

2 Answers

Comments

Comments

Question Tools

Stats

Related questions

UR10 Jerky Movements with the Universal_Robots_ROS_Drivers