UR motion imprecise in force_mode

Technical Questions
1

We are using the UR3 in force_mode to not immediately panic when hitting an obstacle but rather to react accordingly. Since the speed limits (which are position deviation limits when no axis is selected to be compliant) have a higher priority than the robot’s own position deviation limits.
So if we just want to move, we operate in force_mode with wrench set to 0s, selection vector of 0s, sensible speed_limits etc. and send speedj commands.

Now what happens is, that compared to pure speedj execution, the motion is way, way, less precise. The robot is moving like it already had its 7th pint at a bar with a scary determination of going two digits.

So what can we do to make the robot as precise as it is in non-force_mode? Or is that better with later software versions?

My version is 3.3.3.292 with a UR3.

2

This is definitely not the recommended way to use force mode.
Can you share your program, so we can check it on latest software version. Is it just speedj in force mode with xyz axes set to compliant with 0N force?

3

I know it is not the recommended behaviour but there is no other way to do what we want.

This is basically the script that is executed on the robot. All data is set via RTDE including the velocity data and the force_mode parameters. However the force_mode data is currently set to what you see below and only the velocity data is changed over time.

  enable_external_ft_sensor(True, sensor_mass = 0.2, sensor_measuring_offset = [0.0, 0.0, 0.0], sensor_cog = [0.0, 0.0, 0.0175])
  rtde_set_watchdog("external_force_torque", 125, "ignore")
  thread Force_properties_calculation_thread_1():
    while(True):
      task_frame = p[0,0,0,0,0,0]
      wrench = [0,0,0,0,0,0]
      speed_limits = [100,100,100,100,100,100]
      selection = read_input_integer_register(0)
      selection_vec = [0, 0, 0, 0, 0, 0]
      force_type = 2
      force_mode(task_frame, selection_vec, wrench, 2, speed_limits)
      sync()
    end
  end
  global thread_handler_1 = run Force_properties_calculation_thread_1()
  while(True):
    velocity = [...get from rtde...]
    speedj(velocity, 5, 0.05)
    sync()
  end
  textmsg("Stopping main loop...")
  kill thread_handler_1
  end_force_mode()
end
4

I tried simple program with speedj, and speedl functions with, and without wrapping with force mode. I did run it on UR5 and UR10 only. I couldn’t see any obvious deviations from straight path, but I have noticed occasional hiccups.
Force mode has an accumulator for difference between actual force, and requested force. Difference would be negative if something is blocking TCP (also increased friction). You could try to monitor reported TCP force to see these influences.

I chose speedl for this experiment as it has slightly more complex path in joint space.
All tested with latest software.

  $ 1 "BeforeStart"
  $ 2 "speed≔.1"
  global speed=.1
  $ 3 "MoveJ"
  $ 4 "Waypoint_1"
  movej([-0.056016577110518995, -1.2270959035265347, 2.0182861604043283, -0.7768392630611869, 1.568907380104065, -2.515951739709976E-4], a=1.3962634015954636, v=1.0471975511965976)
  while (True):
    $ 5 "Robot Program"
    sync()
    force_mode(p[0.0,0.0,0.0,0.0,0.0,0.0], [0, 0, 0, 0, 0, 0], [0.0, 0.0, 0.0, 0.0, 0.0, 0.0], 2, [0.1, 0.1, 0.1, 1.7453292519943295, 1.7453292519943295, 1.7453292519943295])
    $ 7 "Force"
    $ 8 "Loop"
    while (True):
      $ 9 "Script: servolmove.script_bak"
      local tcp_pos = get_actual_tcp_pose()
      if(tcp_pos[2] > 0.5 and speed > 0) :
        speed = -speed
      elif(tcp_pos[2] < -0.5 and speed < 0) :
        speed = -speed
      end
      speedl([0, 0, speed, 0, 0, 0], 100, 0.008)
    end
    end_force_mode()
    stopl(5.0)
  end

One more comment: results are undefined if you change force mode parameters while force mode is active. It seems that you are thinking about doing that inside Force_properties_calculation_thread_1().

1 Like
5

Hi, bumping this old thread because we are facing a similar issue. We are running a UR10 CB3.9 using force mode for a similar reason. We want to tolerate unexpected interaction forces and handle them using admittance control (our own FT sensor mounted on the tool plate).

Without using force mode we consistently receive protective stops. When we enable force mode, we set all axes to be non-compliant. This avoids the protective stop problem, but we notice a significant decrease in trajectory tracking performance. I am wondering if you have any recommendations?

6

We ended up abandoning forcemode. And by reacting quick enough on impacts using our own hand guiding (admittance control) we don’t get any protective stops.

1 Like