Understanding of scaled joint trajectory controller

[a1ibekov]

Hello,

Let's say we want to control a UR10e robot using the scaled_joint_trajectory_controller in ROS2 Humble. Here's an outline of how it should work:

• Generate a trajectory that includes position, velocity, acceleration, and time_from_start values.

• Store these values in a goal trajectory variable, which is then sent to the robot via the scaled_joint_trajectory_controller.

• Since the robot operates at a high frequency (500 Hz), the scaled_joint_trajectory_controller interpolates the trajectory into smaller increments, creating position commands approximately 0.002 seconds apart that are then sent to the robot.

• At any given moment, the robot receives one position value along with the corresponding time by which it should reach that position.

• The robot's internal controller calculates the appropriate torque and acceleration commands to smoothly move the joints to the target position.

My question is: How does the robot know not to stop at each given position? I have seen examples where we only send position commands to the robot. So we don't send an explicit velocity command and therefore I'm a bit confused about how continuous motion is maintained. Also, please let me know if I've misunderstood any of the points above. Thank you!

[urfeex]

Yes to all of your points, that understanding is correct.

Continuous motion is achieved by peeking into the future. The robot will always be running behind a little bit, leaving it a goal position that it will not reach in the current control cycle. This obviously leads to a small delay between commanding positions and that position being reached. This is why we actually cannot decrease the trajectory tolerances to almost 0 in the controller configuration.

To further reduce this delay, one could switch towards velocity-based control as with that the problem you mentioned does not exist. There, the problem of open-loop vs. closed-loop exists. When using open-loop, the robot's actual position will not be taken into account when sending the motion commands. When using closed-loop control, one has to tune PID gains for each robot model which we haven't done so far.

I hope, that answers the question you had initially?

[a1ibekov]

I see. Thank you very much for the explanation!

So, as I understood, at each conrol cycle, robot plans its movement to the current given position command simultaneously keeping in mind the next one. This way it doesn't stop and keeps moving. But when it reaches the final position and there is no "next" position in the queue, it now knows that it should stop there.

I am asking these questions, because recently I encountered a problem while testing UR10e. Here is the error message that I get in the launchpad:

This problem mostly occurs when I change the speed scaling factor while using the scaled_joint_trajectory_controller. However, it is not consistent, meaning it can occur at any time during the movement, so I can't really reproduce it.

I believe what is happening is:

• When I send the position and time command to the robot, it tries to reach it but, for some reason, fails to achieve it within the given time (possibly due to changing speed scaling factor, friction or something else).
• This causes the robot's current position to deviate from the target.
• When I send the next position command, the distance between the current and target positions is too large.
• As a result, the robot’s controller computes very high velocity values to reach the target position within 0.002s. This high velocity exceedes the limit and causes this problem.

Please correct me if I am wrong. I would like to know if there is a way to solve this problem. Thanks!

[urfeex]

Your initial question goes deeper than the issue you are trying to resolve. The check raising this popup is done at an earlier stage. The "looking at future points" part happens inside the move functions. Please open an issue with as much information on how to reproduce this as possible.

This error can have two sources:

1. Commands sent to the robot contain large jumps. With the JTC this should never be the case.
2. The real robot is running away from what the controller tries to command.

Both cases would lead to the robot trying to get to the target pose as fast as possible, which is why we added this check as a failsafe mechanism. If it is triggered during normal operation that is undesired behavior and should get fixed.

[a1ibekov]

Got it. I will make a seperate issue on this problem. Thank you!