High speed position tracking

[ddliu365]

Hi, folks,

I want to use ur robot to track high frequency goals.

I just run the example on the robot with this launch file https://github.com/UniversalRobots/Universal_Robots_ROS2_Driver/blob/fabfb3fd63674f0665ba34f8f0780ff9f6e3a9ba/ur_bringup/launch/test_joint_trajectory_controller.launch.py.

For longer time intervals, it works well.

But if I would like to control the robot with smaller time interval, say 500Hz, i.e., reduce the time interval from 6 seconds to 0.002s, it cannot work.

I believe one issue may be caused by the python script in this example.

Do we have some examples implemented for high sampling frequency position control if I know the dense joint trajectories instead of sparse way points?

[destogl]

If you have already suitable trajectory, then you can use forwarding controllers. Of course, if you are sending values on such high frequency, they have to be achievable by the hardware.

Nevertheless, sending goals with 500Hz over topic is very optimistic. You probably have to develop your own controller that generates the goals and uses Joint Trajectory Controller as a following controller to do interpolation, i.e., generate physically accessible goals by the robot. (if not done in your controller).

[ddliu365]

thanks. Do we have an example for forwarding controller either speed or position?

I found Joint Trajectory Controller significantly deviates from my desired goals even I reduced the speed.

Dynamically feasible trajectory is generated from a simulator which considered the maximum velocity, maximum torque and collision issue.

Is there any constraint which I don't realize? I used the maximum torque from URDF and maximum velocity from URDF and user manual. It seems joint trajectory controller significantly reduce the performance. If the control frequency is larger than 10Hz, the output trajectory is not likely to follow the desired goals.

[ddliu365]

@destogl

I did implement the forward position controller but found the controller is not stable in a control frequency of 500Hz. The robot suffered non-smoothness of execution. I don't have the online controller running in ros and just send the joint commands based on an offline trajectory planner. Is it possible to run the offline trajectory in a high-frequency sampling rate robustly? For example, can we run the trajectory commands on the robot using the .urp file internally? or can we pass the whole trajectory to the controller running on the robot to avoid communication between the host and ur robot?

Thanks.

[fmauch]

@ddliu365 The latter is at the moment not possible for ROS2. When using the forward controller bear in mind that the input to that controller is going over topic communication, which is not real-time control. I think, this is what @destogl meant with "Nevertheless, sending goals with 500Hz over topic is very optimistic."

Once feasible path to follow could be using a velocity-based trajectory controller, as this internally has a lower delay between the command and the actual execution. Also, wenn using a forwarding controller, velocity-based control might produce better results in terms of jerkiness. Here, any delay in communication will obviously result in deviations from the desired path.

[ddliu365]

Yes, I will try the velocity controller and post the feedback.

For ROS1, I saw the feature description marked with "Realtime-enabled communication structure to robustly cope with the 2ms cycle time of the e-Serie".

Do you think I can try to use ros1 driver to enable 2ms control frequency? If so, could you explain the driver difference between ROS1 and ROS2?

[fmauch]

The ROS2 driver also uses the 2ms control frequency on an e-series robot. The problem is not the control frequency, but the delay between ROS commands and commands sent to the joints.

[ddliu365]

Humm, I am wondering why ROS1 can handle the delay well

[ddliu365]

At the hardware level, is there anything I need to take care of? such as shielded ethernet cables, etc.?

[fmauch]

Communication wise the ROS1 driver and the ROS2 driver are the same, as they use the same library. On a hardware level it would be best to use a direct connection (without a shared network switch) between the robot and the ROS pc.

[urfeex]

Since the interfacing issues have been discussed above I am going to close this.

Latency-wise there have been improvements in the meantime (and are still going on, e.g. in #1760). In general, when providing targets at a high frequency, the JTC isn't the right interface to use.

Feel free to comment / reopen if there are any new aspects to this.