I’m trying to perform movements using the servoj command, with very bad results so far. And I don’t really understand the reason of the results. This is what I’ve done.
First fo all, I’m using a UR5e robot with PolyScope 5.8 installed on it.
First, I program a simple Polyscope program in which and squared movement is done using moveP and 4 waypoints. This movement is done at 50mm/s.
While performing the movement, I connect a PC to the robot using RTDE protocol in order to obtain joint position samples at 500Hz frequency.
Later on, I’m trying to reproduce this movement using servoJ commands. The program is very simple, it moves to the initial pose using a MoveJ movement and, once arrived, new joint positions are sent to the robot through RTDE protocol at a frequency of 500Hz, using the ones I previously recorded. The movement is reproduced using:
servoj(new_joint_goal, 0.05, 2000)
I’ve played around with the parameters in that function, but the result is always similar. The arm moves really slow, and, after around 1 second, the joint error has increased too much like if the arm was not able to arrive to each new goal, and the arm makes a weird sound which I don’t like at all. If I don’t stop it soon enough, normally a too high current error pops.
I understand the how the gain value works. Lookahead time is a bit less clear to me but anyway, I get this behaviour no matter which parameters I use.
After that, I decided I would slow down when I send new goals, so, instead of a new goal every new RTDE protocol cycle, I’d slow the to one every 4 or 10 cycles. This slows the appearance of the problem, but does not solve it. Anyway, the problem cannot be that I’m asking the arm to move too fast, since it was able to perform the movement before using moveP, and 50mm/s is definitively not fast for the arm.
Then, I tried something else, in the PC, I have compared the last sent joints goal to the actual joint positions of the arm, and I would only send a new goal if the total error was smaller than a certain value. As before, this allows the program to work for a longer time, but the same error appears.
Finally, if I use the same program to reproduce the goals, but using moveJ instead of servoJ, the movement is performed but the arm makes a lot of start-stop movements, while I’m looking for a smooth reproduction of the path.
I would appreciate any ideas on what is going on or on what to try.
I have the feeling that each new goal I send might be too close to the actual joint pose, and therefore the error is not large enough even is I use a gain=3000, but I would expect this would not be a problem since I send new goals every cycle.
I see you’re sampling at 500Hz, and trying to play back using the ‘a’ and ‘v’ parameters. Is this correct? The script manual says that that those parameters are currently not used. Also, even if they were being used, you have them backwards. as per servoj(q,a,v…etc). I would recommend setting using the ‘t’ parameter and setting it to 0.002s as per your sample rate. and then tweak lookahead time to control how much it’s smoothing your pattern and then tweak gain if you get any weird oscillating.
Let me know if that works for you.
Thanks a lot for answering.
I didn’t use the ‘a’ or ‘v’ parameters, at least not voluntarily.
This is the call I have in the code:
servoj(new_q, lookahead_time=0.05, gain=2000)
Anyway, I’ll try to set all the values just in case.
Also, because I had the feeling that the joint position error between servoj commands was too low, I decided to send one joint position every 10 stored values. This works if I run the code against the simulator instead of the robot, although the path in Cartesian coordinates is affected. However, when I tried against the robot, it still does not move and I have the same sound.
Maybe just test it with the q parameter and nothing else, the high gain might be making it angry.
I tried both using only the new joint positions:
And filling all the possible parameters, the result is
servoj(new_q, 0, 0, 0.002, 0.05, 2000)
And I still get the same result in both cases.
Is there anything else in your loop besides the servoj command?
Maybe try cutting out the RTDE part first to see whether it’s the RTDE comms or your servoing program that’s the issue? You could run a test where you just add a very small value to one of the joint angles each cycle (i.e. new_q = new_q + 0.0001) to see if it behaves itself.
I tried as you said, just moving only the first joint and I get the same result.
Once the first moveJ movement sets the robot in the
first pose, there are just 2 lines: the increase of the joint value, and the servoj command.
I recorded the test, you can see it here.
This program works fine on a UR5e robot here. If I uncomment the sync however then I get a similar issue to you… you don’t have anything else in there that could be adding a delay to the loop?
You nailed it!
I had a sync call related to the test I did before with the moveJ command.
However, to be honest, even if I was aware of it I’d have told you I had only " the increase of the joint value, and the servoj command", because I though the sync call was not harmful. So my bad.
Thanks a lot for the help.
Yeah it’s a bit counter-intuitive that your sync command is getting your movement out of sync here Glad you found the issue!