Hi, with a colleague, we are trying to perform some trajectories by sending joint velocities to be followed.
Our setup: The trajectories are sent via ROS, by using velocity_controllers/JointGroupVelocityController (from UR ROS controllers) which if I’m correct should simply forward the desired joint velocity to be executed by the script speedj inside the control box.
ROS is run on an industrial PC (B&R) with Ubuntu 18, currently without a real-time kernel (we are working to implement it in the next days). The industrial PC is directly connected via ethernet to the control box of the robot.
UR ROS drivers were updated last time 10/10/2022.
Problem description: The robot is not able to follow in a good way the velocities we are sending. This is especially evident when we try to achieve higher velocities, as you can see in the pic reported below, which describes the commanded velocity vs the measured one for the first joint.
Please note that a similar behaviour is observed for all the other joints and the problem is systematic, meaning that it occurs in the same way (the measured trajectory is following badly always in the same points) if we perform the same trajectory. This led us to think that real-time capabilities are certainly important (and as mentioned before we are going to implement the) but here the source seems to be something else, otherwise the tracking of the velocity should be problematic but in a randomic way.
Does anyone know what could be the source of the problem?
After a lot of time debugging we discovered that the problem was due to power limits of the control box, we changed the limits to max settings and managed to achieve the desired performances.