Closed tborgesd closed 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()))
@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:
And I've also got a few times where the robot continued to move up until it reached its limit:
@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?
@vimior The SDK is: SDK_VERSION: 1.11.6 Firmware: v1.8.10 Robotic Arm Hardware Version: XI1302 Robotic Arm Model: xArm6
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 ,
@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
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,
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.
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
andrelative=True
.This is what how you can reproduce the bug:
set_position
usingrelative=True
The code I used to reproduce is:
And this is the result I got:
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?