xArm-Developer / xArm-Python-SDK

Python SDK for UFACTORY robots, 850, xArm5/6/7, and Lite6.
https://www.ufactory.cc
BSD 3-Clause "New" or "Revised" License
178 stars 110 forks source link

Robot sometimes ignores `set_position` #59

Open joshuafishman opened 1 year ago

joshuafishman commented 1 year ago

set_position generally works really well, but occasionally the robot seems to completely ignore a command: it won't throw any errors that we can see, but it also won't move. This only happens with the first motion in a segment (specifically, moving back up after picking up an object) and only rarely: we haven't been able to isolate other contributing factors. This has never occurred with similar motions using set_servo_angle and inverse kinematics.

The final cartesian motion in the attached logs should show an example. We appreciate any advice you can give!

XI130308B22L34_2023-01-17_08-16-11.tar.gz

joshuafishman commented 1 year ago

Here's another example XI130307A22L20_2023-01-20_08-26-52.tar.gz

joshuafishman commented 1 year ago

I think I've isolated at least 1 example of issue: in the below, if the sleeps are <.1sec the arm doesn't move.

import time
import numpy as np

from xarm import XArmAPI

api = XArmAPI(port="192.168.250.232")

api.motion_enable(True)
api.set_cartesian_velo_continuous(True)
api.set_mode(0)
api.set_state(0)

time.sleep(0.1) # IF THESE ARE ANY SMALLER THE ARM DOESN'T MOVE

joints = np.array(api.get_servo_angle(is_radian=True)[1][:6])

code, (x, y, z, roll, pitch, yaw) = api.get_forward_kinematics(
    joints, input_is_radian=True, return_is_radian=True
)

api.set_position(
    x=x,
    y=y,
    z=z - 100,
    roll=roll,
    pitch=pitch,
    yaw=yaw,
    speed=100,
    mvacc=1000,
    is_radian=True
)

time.sleep(.1)

api.set_position(
    x=x,
    y=y,
    z=z + 100,
    roll=roll,
    pitch=pitch,
    yaw=yaw,
    speed=100,
    mvacc=1000,
    is_radian=True
)

time.sleep(.1)

api.set_position(
    x=x,
    y=y,
    z=z,
    roll=roll,
    pitch=pitch,
    yaw=yaw,
    speed=100,
    mvacc=1000,
    is_radian=True
)

I'm pretty confident this isn't the only circumstance in which this bug manifests. Any assistance would be greatly appreciated!

joshuafishman commented 1 year ago

Evidence that this is specifically a bug with set_position: in the below, the arm will only execute the set_servo_angles:

import time
import numpy as np

from xarm import XArmAPI

api = XArmAPI(port="192.168.250.232")

api.motion_enable(True)
api.set_cartesian_velo_continuous(True)
api.set_mode(0)
api.set_state(0)

time.sleep(0.1)

joints = np.array(api.get_servo_angle(is_radian=True)[1][:6])

code, (x, y, z, roll, pitch, yaw) = api.get_forward_kinematics(
    joints, input_is_radian=True, return_is_radian=True
)

api.set_servo_angle(angle=joints+.1, is_radian=True)

time.sleep(0.09)

api.set_servo_angle(angle=joints, is_radian=True)

time.sleep(0.09)

api.set_position(
    x=x,
    y=y,
    z=z - 100,
    roll=roll,
    pitch=pitch,
    yaw=yaw,
    speed=100,
    mvacc=1000,
    is_radian=True
)
penglongxiang commented 1 year ago

hi, Thanks for reporting the issue. After testing on my side, I believe the bug is related to api.set_cartesian_velo_continuous(True) , if removing this configuration or setting it to False, there will be no difference no matter what the sleeping time is.

Currently, you may need to specify radius=0 in set_position() along with theset_cartesian_velo_continuous(True) configuration. We will fix it in next firmware update so that radius=0 would no longer be a requirement.

penglongxiang commented 1 year ago

A kind reminder for the set_cartesian_velo_continuous(True) setting:

After the fix, if removing the sleeping time (or it is sufficiently small) between instructions, the linear speed will not decelerate between set_position() commands. So be careful not to use a large speed if the path has sharp turnings in between. Set it back to False when the continuous speed is no longer needed.

joshuafishman commented 1 year ago

Great! set_radius=0 seems to have solved the problem for now, but we'll keep an eye out to make sure (and for any resulting jerkiness).

penglongxiang commented 1 year ago

Hi @joshuafishman, this bug has been fixed in latest firmware version 1.12.9. After the update, you would not have to use radius=0 anymore. The sleep() in between could also be removed if not necessary.