After the RmpFlow exceeds a certain position range, the end following task is not accurate

Hi everyone, I am trying to test RmpFlow using a cobotta_pro_900 robotic arm. I used a tutorial case where “end Effector” is “right-inner_finger”, but I encountered a strange problem where its execution was accurate when it approached “baseunlink” (or close to cobotta_pro_900 itself). But when he is far away, he will have a very large margin of error. It seems that calculations can only be carried out within a certain range.


I also tried Frank and customized a robotic arm (which has no axis restrictions and is completely free). Even if the robotic arm is very long, a similar situation occurred. It always accurately executes the “Follow Target” within a certain range. If it exceeds the range, it will be inaccurate and the range will be very small.
I want to know if there are any parameters or method adjustments. It is very important to me and I hope to receive everyone’s help.


joint_limit_buffers: [.01, .01, .01, .01, .01, .01]

# RMPflow has many modifiable parameters, but these serve as a great start.
# Most parameters will not need to be modified
        metric_scalar: 50.
        position_gain: 100.
        damping_gain: 50.
        robust_position_term_thresh: .5
        inertia: 1.
        p_gain: 100.
        d_gain: 10.
        ff_gain: .25
        weight: 50.
        final_handover_time_std_dev: .25
        weight: 2000.
        metric_scalar: 1000.
        metric_length_scale: .01
        metric_exploder_eps: 1e-3
        metric_velocity_gate_length_scale: .01
        accel_damper_gain: 200.
        accel_potential_gain: 1.
        accel_potential_exploder_length_scale: .1
        accel_potential_exploder_eps: 1e-2
        max_velocity: 4.
        velocity_damping_region: 1.5
        damping_gain: 1000.0
        metric_weight: 100.
        accel_p_gain: 30.
        accel_d_gain: 85.
        accel_norm_eps: .075
        metric_alpha_length_scale: .05
        min_metric_alpha: .01
        max_metric_scalar: 10000
        min_metric_scalar: 2500
        proximity_metric_boost_scalar: 20.
        proximity_metric_boost_length_scale: .02
        xi_estimator_gate_std_dev: 20000.
        accept_user_weights: false 
        accel_p_gain: 210.
        accel_d_gain: 60.
        metric_scalar: 10
        proximity_metric_boost_scalar: 3000.
        proximity_metric_boost_length_scale: .08
        xi_estimator_gate_std_dev: 20000.
        accept_user_weights: false
        damping_gain: 50.
        damping_std_dev: .04
        damping_robustness_eps: 1e-2
        damping_velocity_gate_length_scale: .01
        repulsion_gain: 800.
        repulsion_std_dev: .01
        metric_modulation_radius: .5
        metric_scalar: 10000.
        metric_exploder_std_dev: .02
        metric_exploder_eps: .001
        accel_d_gain: 30.
        metric_scalar: 50.
        inertia: 100.

    max_acceleration_norm: 50.
    projection_tolerance: .01
    verbose: false

# body_cylinders are used to promote self-collision avoidance between the robot and its base
# The example below defines the robot base to be a capsule defined by the absolute coordinates pt1 and pt2.
# The semantic name provided for each body_cylinder does not need to be present in the robot URDF.
     - name: base
       pt1: [0,0,.33]
       pt2: [0,0,0.]
       radius: .05

# body_collision_controllers defines spheres located at specified frames in the robot URDF
# These spheres will not be allowed to collide with the capsules enumerated under body_cylinders
# By design, most frames in industrial robots are kinematically unable to collide with the robot base.
# It is often only necessary to define body_collision_controllers near the end effector
     - name: right_inner_finger
       radius: .05

After a lot of testing, I need to modify rmpflow_config.yaml to temporarily solve this problem. I am not sure if my solution will encounter any other issues.