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
163 stars 105 forks source link

Inconsistent movement when using relative=True after setting TCP offset and load #68

Closed tborgesd closed 1 year ago

tborgesd commented 1 year ago

I've encountered a bug where the robot moves to different positions after the TCP offset and TCP load are set. I was able to reproduce it for when I use set_position and relative=True.

This is what how you can reproduce the bug:

  1. set TCP load
  2. set TCP offset
  3. enable motion
  4. set mode '0'
  5. set state '0'
  6. call set_position using relative=True

The code I used to reproduce is:

tool_weight = 1
tool_center_of_gravity = [0,0,0,0,0,0]`
tool_offset = [0,0,0,0,0,0]
xarm.set_tcp_load(tool_weight, tool_center_of_gravity)
xarm.set_tcp_offset(tool_offset)

xarm.motion_enable(True)
xarm.set_mode(0)
xarm.set_state(0)

print("current pos is: " + str(xarm.position))

position = [0,0,100,0,0,0]
speed = 200
code = xarm.set_position(*position, wait=True, speed = speed, relative=True)

print("final pos is: " + str(xarm.position))`

And this is the result I got: error rel move

As you can see, the 'Z' is supposed to be 235.99 but it moved to 608.03

I've also experienced an change in the axes in the exact same scenario, but I couldn't reproduce it yet.

This doesn't happen that often, it usually performs the movement as specified in the coordinates.

I'm not sure why this happens, perhaps you could shed a light and point what I'm doing wrong?

vimior commented 1 year ago

@tborgesd Is there a non-zero offset before you run this code? The mechanical arm is at the same position. If the set offset is different, the position displayed by the mechanical arm (arm.position) is also different. In addition, arm.position is updated by reporting, and the default reporting frequency is 5HZ, so there will be a certain delay.

# init motion
arm.motion_enable(True)
arm.set_mode(0)
arm.set_state(0)

tcp_offset_1 = [0, 0, 100, 0, 0, 0]
tcp_offset_2 = [0, 0, 0, 0, 0, 0]
position = [0, 0, 100, 0, 0, 0]
speed = 200

# init tcp offset
arm.set_tcp_offset(tcp_offset_1)
arm.set_state(0)
# print position
print('first_pos: {}'.format(arm.get_position()))

# set tcp offset
arm.set_tcp_offset(tcp_offset_2)
arm.set_state(0)
print('curr_pos: {}'.format(arm.get_position()))

code = arm.set_position(*position, wait=True, speed=speed, relative=True)
print('final_pos: {}'.format(arm.get_position()))
tborgesd commented 1 year ago

@vimior,

To answer your questions: There's no offset prior to that portion of code. That was a simple code to reproduce the bug. I do understand that setting the TCP offset will change the coordinates reported by the SDK, I actually use it often to perform movements based on the TCP coordinates as my setup has multiple TCPs. I've tried your code and I got the same error. As I said, it's not consistent, so it took me around 30 tries to reproduce it again.

I've just modified your code a little bit to include my arm IP address and also setting the TCP load and COG (as my in use case I absolutely need to do this together with the TCP offset)

This was the code I used:

from xarm.wrapper import XArmAPI

IP = '192.168.1.223'
arm = XArmAPI(IP)

arm.motion_enable(True)
arm.set_mode(0)
arm.set_state(0)

tcp_offset_1 = [0, 0, 100, 0, 0, 0]
tool_center_of_gravity = [0,0,0,0,0,0]
tool_weight = 1

tcp_offset_2 = [0, 0, 0, 0, 0, 0]
position = [0, 0, 100, 0, 0, 0]
speed = 200

# init tcp offset
arm.set_tcp_offset(tcp_offset_1)
arm.set_tcp_load(tool_weight, tool_center_of_gravity)
arm.set_state(0)
# print position
print('first_pos: {}'.format(arm.get_position()))

# set tcp offset
arm.set_tcp_offset(tcp_offset_2)
arm.set_tcp_load(tool_weight, tool_center_of_gravity)
arm.set_state(0)
print('curr_pos: {}'.format(arm.get_position()))

code = arm.set_position(*position, wait=True, speed=speed, relative=True)
print('final_pos: {}'.format(arm.get_position()))

In the screenshot below you can see the same movement bug:

error vimior code_5

And I've also got a few times where the robot continued to move up until it reached its limit:

error vimior code_7

vimior commented 1 year ago

@tborgesd Ok, let's try to reproduce it, what is the SDK version and firmware version you are using, and what is the model of the robotic arm?

tborgesd commented 1 year ago

@vimior The SDK is: SDK_VERSION: 1.11.6 Firmware: v1.8.10 Robotic Arm Hardware Version: XI1302 Robotic Arm Model: xArm6

MinnaZhong commented 1 year ago

Hi tborgesd,

Please update the firmware to the latest V2.0.1 version, we optimized this relative feature in V1.9. Please refer to the user manual Appendix 4 to know how to do the update, thank you. https://www.ufactory.cc/download/

Best ,

tborgesd commented 1 year ago

@MinnaZhong My proxy settings do not allow the uFactory Studio to connect to the internet so it cannot even check for updates, is there another method I can use to update the firmware? Thank you

MinnaZhong commented 1 year ago

Hi, @tborgesd

Please download the xarm-tool-gui in the below link to do the offline update, for more details please download the user manual from our official website and refer to Appendix 4. https://drive.google.com/drive/folders/1WOcMMRXo0XACg48d3BR2Ki-kUKioCyGm?usp=share_link

Best,

tborgesd commented 1 year ago

Thanks @MinnaZhong and @vimior, it seems that the problem is solved now. I've updated the firmware and GUI and I haven't been able to reproduce my bug since then.