Home Programming

Discussion

Left ArrowBack to discussions page
kaykay Posts: 2 Recruit
For remote control or visual servo application, I’d like to stream the target position every 10-50 milliseconds from my Linux PC, and each update would only change the destination around 1-100 millimeter. By doing this, I’d like to create a smooth motion. I want to realize both in Cartesian space control and in Joint space control, but let’s discuss Cartesian space first.

My problem is that the robot movement is very jittery. I’m using RTDE (real-time data exchange) and running the same urp file which you can find here: https://www.universal-robots.com/how-tos-and-faqs/how-to/ur-how-tos/real-time-data-exchange-rtde-guide-22229/
The motion I tried to create was simple: just moving up 200 millimeters toward +Z direction, then moving down 200 millimeters toward -Z direction. I was sending the target update (absolute target position in robot’s Base Frame) every 50 msec, and I was changing 10 millimeters for every update. However, the movement was very jittery or the repetition of small “start and stop” movement. The original urp file uses “MoveL” command, so I tried to tune the parameters (by changing from “Stop at this point” to “Blend with radius”), but it didn’t work. 

When I implemented the similar functionality on ABB, I could use EGM (Externally Guided Motion), which you can stream the point, and the robot follows the point it gets every update. Alternatively, when I implemented for DensoWave or Mitsubishi, I could use “Cancel” or “Skip” command for each “Move” command to override the old target. I’m wondering if there are any commands/options that I can use for Universal Robots.

Are there any ways/commands to realize above smooth real-time target-update movement?

Comments

  • matthewd92matthewd92 Founding Pro, Tactile Sensor Beta Testers Posts: 1,020 Handy
    Best way I have found is to use servoj or servol commands, this will allow for very smooth motion however, you need to stream the data at 8ms intervals and give the precise distance you are trying to go. Also, those commands are looking for joint positions, not tcp pose. There are several threads on here about using servo commands and some pretty good examples of smooth motion with control off the robot. 

    Have you tried reduciing the size of your move?  You are basically stopping execution with each update. What is the linear speed you are trying to move in?  Also, realize using a move command that each iteration is accelerating and decelerating to a stop. The longer each move is the higher the speed reached will be and the more you will notice the jitter. 

    We do do a lot of search methods with the UR where we are using FT sensor for feel and searching down or following a screw or rivet. We are looping every 8 ms and are generally stepping down 0.1 to 0.5 mm with each iteration.  If we bump that up to even 1-2 mm we begin to see jittery operation because of the start/stop nature of the move
  • kaykay Posts: 2 Recruit

    HI @matthewd92, thank you so much for your comment. I modified the code so that it wouldn't stop the execution with each update. For movel, I was using the default linear speed (=250mm/s). 

    I started to experiment with servo commands. There are two servo commands available as UR API: servoc (not servol) for cartesian control and servoj for joint control. Weirdly, `servoc` doesn't have arguments like `lookahead_time` and `gain`, so it's very similar to general `movel` or `movec` commands. Here are those definitions:

    • servoc(pose, a=1.2, v=0.25, r=0) 

    • servoj(q, a, v, t=0.008, lookahead_time=0.1, gain=300) 

    After I looked the past discussion in the forum, I thought there are two ways to work on this: 1. to use `servoc(target_pose_in_base_frame)` and 2. to use `servoj(get_inverse_kin(target_pose_in_base_frame))`. I quickly tried both. I sent the target update every 8msec and tried the delta size both 1-2mm and 0.1-0.5mm as you suggested.

    When tried 1. to use `servoc(target_pose_in_base_frame)`, the movement was smooth, but when the robot got the point to change the direction of the movement (e.g. +z to -z direction), the robot stopped because of the safety limit. I think the reason for this is because I was using the default acceleration and velocity. I'll probably need to change acceleration and velocity dynamically, but if you know the good way to handle this, please let me know.

    When tried 2. to use `servoj(get_inverse_kin(target_pose_in_base_frame))`, I didn't see any safety stop, but I noticed that the robot was always vibrating, which created the noise. I lowered the gain to 100 (min limit) and increased the lookahead_time to 0.2 (max limit), which relieved the symptom, but I still see this jittering issue. 

    If you have a recommendation which way to proceed or how to improve the issues I wrote above, please let me know. 

  • carlmalone100carlmalone100 Posts: 1 Recruit
    Hi @kay ,


    I am pretty sure you have solved this issue seeing how it was posted last year but,
    I was facing this exact issue and it took me a while to find any information regarding it/finding a solution for it


    Using movel works if you want to move the robot in a TCP in a certain direction in x, y, z but it currently does not work in real time. 
    Speedl on the other hand works like a charm. 

    I am currently controlling the UR3 with 2 joystick and its very smooth.

    I'll leave an example code for reference.

    def toBytes()
        return bytes(str.encode())

    def speedl()
        s.send(toBytes(
        "def myProg():" + "\n"
        +"speedl([0.0, 0.0,0.0261, 0.0, 0.0,0.0],1.0, 1.0)  + "\n""
        +"end" + "\n"))

    0.0261 radiants is equal to 1.5mm (0.0261/3.14 * 180) meaning that the robot's tool should move up 1.5mm. 

    I send this every 0.02 seconds and I have no issue so far. 


    This worked for me but I am not sure if this is the correct way of doing this. 
    Please use the same method I used at your discretion.




  • Br0tBr0t Unconfirmed Posts: 1 Recruit
    Hoi guys, i had the same problem for quite some time and solved it by uploading a program to the robot and sending new poses via RTDE. Here's the github: https://github.com/Mandelbr0t/UniversalRobot-RealtimeControl

Sign In or Register to comment.
Left ArrowBack to discussions page