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,267 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: 2 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

  • Fadi_RaidFadi_Raid Posts: 3 Apprentice
    Br0t said:
    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

    Hi , I am trying to control UR5 robot in real-time. I am sending servoj commands to port 30003 RTDE using the default setup and the robot freezes after the first movement.

    Can you please guide me on how to use the program you provided in the link and upload it to the robot?



  • matthewd92matthewd92 Founding Pro, Tactile Sensor Beta Testers Posts: 1,267 Handy
    edited September 2020
    Are you using port 30003 or 30004?  30003 is not the RTDE port. 
  • Fadi_RaidFadi_Raid Posts: 3 Apprentice
    Are you using port 30003 or 30004?  30003 is not the RTDE port. 
    Hi Matthew, thanks for the reply

    Yes my bad it is not RTDE it is port 30003 real-time. Now the robot moves from point to point but the movement is still jittery. 
    I heard of the of ROS driver here that can be installed into the robot to make the movement smooth, yet I don't know how to install it. 

    Following this discussion here it is mentioned that it can be used to make the movement smoother when sending position in real-time and you can use Python or C without getting into ROS completely.

    I am using an old UR5 with CB2 running 1.8.4035.

  • matthewd92matthewd92 Founding Pro, Tactile Sensor Beta Testers Posts: 1,267 Handy
    I will have to leave the ROS question to someone more knowledgeable than myself about ROS.  
  • Br0tBr0t Unconfirmed Posts: 2 Recruit
    edited October 2020

    Im not sure which port is the correct one and you might have to update the code to the UR Firmware version you are using. But im sure that if you manage to upload the program and send new inputs to the input registers the code should work. Servoj gave me the same problem you are describing.
    First call init_realtime_control (upload the UR program) and then call set_realtime_pose (update the registers for each pose) repeatedly.
    The code is tested with UR5 and Firmware 3.2 and 3.4.

    Good Luck!






  • Fadi_RaidFadi_Raid Posts: 3 Apprentice
    edited October 2020
    Br0t said:

    Im not sure which port is the correct one and you might have to update the code to the UR Firmware version you are using. But im sure that if you manage to upload the program and send new inputs to the input registers the code should work. Servoj gave me the same problem you are describing.
    First call init_realtime_control (upload the UR program) and then call set_realtime_pose (update the registers for each pose) repeatedly.
    The code is tested with UR5 and Firmware 3.2 and 3.4.

    Good Luck!







    Thanks for replying.
    I am using C++ since I am controlling the robot using stereo camera and C++ offers better performance. Can I use this library while sending socket commands in C++?
    I managed to get better results by having 2 threads one for capturing and other for sending instructions to the robot. However, a slight jitter is still there. I would like to try you library but I am still unaware on how to load it into the robot. My firmware is quite old, version 1.8.25319.

    Thank you again

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