Xarm 6 Lite - J4 frequently throws overspeed error

[scottrpaterson]

When using Studio and Python J4 frequently throws an overspeed error, even when moving very slowly.

The only way I have found to overcome this issue, is to only use set_servo_angle commands.

[penglongxiang]

For lite 6 when link4 and link5 are almost aligned, it will be easy to cause singularity. Would you please share the initial joint angles and following Cartesian command which causes J4 overspeed?

[scottrpaterson]

Please see these videos for how easy it is to throw an overspeed error. Speed is currently set at 1%.

Here is the robot in an example pose: https://user-images.githubusercontent.com/11578353/192592998-664097cd-50be-4d8e-acc8-35706d1a67ad.MOV

And here is the control panel: https://user-images.githubusercontent.com/11578353/192593175-03944d40-43c5-4036-82da-f72bce483b8a.mov

[penglongxiang]

Thanks for the illustration, in your case it is because the robot is at its reaching limit. The joint command might overspeed at this singularity point. If move in the opposite direction (x-) would it also report this error?

[scottrpaterson]

We have the xArm 6 robot (non lite) also and this error never happens in any pose unless you go really fast (800+).

Perhaps this can be fixed with a software update? I wish it would just throw a kinematics planning area or have a smaller working area. This bug makes it really hard to use.

[scottrpaterson]

Please fix this issue. This happens even with simple small moves. It happens with all 3 Lite 6's but not at all with the non-lite xArm 6.

With this error the robots are completely unusable.

https://i.imgur.com/eIaYAE5.mp4

[scottrpaterson]

This only happens with arm.set_position_aa or arm.set_position

Using set_servo_angle does not cause an error.

[scottrpaterson]

Here is a simple test:

1. Go to Zero Position
2. Go to arm.set_position(x=300, y=0, z=200, roll=0, pitch=0, yaw=0, is_radian=True)

This will throw a "Speed Exceeds Limit" error.

[penglongxiang]

Hi, thank you for the feedback. According to what the video shows, it is still another singularity issue, the Inverse Kinematics algorithm tend to solve a high joint velocity when 2 or more joint rotation axis almost align (in this case, joint4 and joint6), this will be more likely to happen when TCP is in this kind of orientation. There are two ways to try out:

1. adjust the working area, to avoi axis 4 and 6 getting aligned, for example, to make the TCP move on one side of the arm (+y or -y area) and avoid going accross the middle.
2. Since the sigularity mostly apprears within the straight line trajectory, if straight line trajectory is not mandatory, you can try get_inverse_kinematics API to solve for the target joints of your desired Cartesian position, then use set_servo_angle to move there.

[scottrpaterson]

1. I also have the xArm 6 robot - why have I never had this happen once with that robot?
2. Is there a way to raise the speed limit default? Or stop j4 from moving as much?
3. I will try "get_inverse_kinematics -> set_servo_angle" tomorrow.

[scottrpaterson]

@penglongxiang Please see this video:

https://user-images.githubusercontent.com/11578353/199578286-9cd6bde5-9ee4-4eb2-bb39-e332c2e59148.mp4

J4 and J6 are not aligned in this video. Moving in any direction causes the issue (in both base and tool coordinate mode). The robot throws an overspeed error without even attempting to move. How is a singularity causing this issue?

[penglongxiang]

Hi this is yet another kind of singularity. Refer to the explanation from UR, here it is similar as INNER WORKSPACE LIMIT when moving linearly across the area close to base center. You can read this whole article and get a feeling about different kinds of singularity of a robot arm and how to tackle them, even though they have different architecture. BTW, as suggested in the "how to avoid" of WRIST ALIGNMENT SINGULARITY, you may also consider offsetting the tool, so that the flange does not need to point to the front, which is more easily to suffer from singularities.

If you do have to move linearly across the singularity, sometimes using a small linear speed/acceleration can make it through without joint over-speed.

[penglongxiang]

• I also have the xArm 6 robot - why have I never had this happen once with that robot?
• Is there a way to raise the speed limit default? Or stop j4 from moving as much?

1. xArm6 has different architecture from lite6, one more joint offset. Actually it will also suffer from those singularities.
2. We will see what can be done to improve the situation, also we have to comply with the hardware limits and safety consideration.

[scottrpaterson]

@penglongxiang

Yes, please see what can be done. The Lite 6 is not usable for real world production use right now.

Can you use a different IK planning algorithm? Or can you write code to work around all of these singularity points?

[penglongxiang]

Hi, the singularity is a hard mathematical limitation so the optimization may not have too much improvement, singularities won’t get eliminated if they are still inside the commanded linear trajectory. Other robot arms will also have those issues in linear motion. If we use approximate solutions (if any) to avoid the singularity, trajectory will deviate from the straight line.

Previously I have already made a few suggestions: call a single IK to find the target joint angles if linear motion is not necessary; Offsetting the tool to make end-flange pointing downward instead of forward; Use small speed/acceleration when moving in potential singularity areas.

Please do try above workarounds while we are seeing what can be optimized. Thanks.

[scottrpaterson]

I have tried all of your suggestions already today. With limited success.

Personally, I'm fine with deviating from a straight line trajectory, if I could avoid some of these singularity issues.

Thank you for looking into this.

[scottrpaterson]

@penglongxiang Any update on this? We need this working better very soon.

[penglongxiang]

We are working on the beta function of Cartesian point-to-point motion by joint motion. It will be released in next firmware update. It could be nice if you can provide some end-to-end Cartesian Coordinates which failed to execute in your application, we can use them to test the feasibility for you in advance.

[penglongxiang]

Hi @scottrpaterson, we would like to provide a beta firmware for you to test. Not only the above joint motion to Cartesian target function, but also approximation at singularity in straight line motion is supported. If you are willing to try, please contact support@ufactory.cc and mention my name, we will assist you then.

[penglongxiang]

This is our test on your previous situation (with same starting joint positions). One additional setting with SDK is required to allow path approximation. In that case, TCP trajectory will deviate a little to avoid joint overspeed in the neiborhood of singularity, but it will be free from C24 error.

https://user-images.githubusercontent.com/6412261/204986150-4e8b1e17-0ce2-4b3c-a90d-8e2168795518.mp4

[scottrpaterson]

@penglongxiang Amazing! Can't wait to test this out. Just sent you an email.

[scottrpaterson]

I just tested the new beta firmware. Wow! This is amazing! Great job! It's so much better now.

I'm going to continue to do more testing.

[scottrpaterson]

@penglongxiang I am getting this error now which I was not getting before the update:

Traceback (most recent call last):
  File "robot_object_tracking.py", line 458, in <module>
    move_to_position_aa(71.38915025991876, 86.65377207617415, 266.2070342300362, 0, -10, 0,True,True,speed,True)
  File "robot_object_tracking.py", line 194, in move_to_position_aa
    arm.set_position_aa(axis_angle_pose=[x, y, z, pitch, yaw, roll], relative=relative, wait=wait, motion_type='2', speed=speed, is_tool_coord=tool)
  File "C:\Users\Scott Paterson\AppData\Local\Programs\Python\Python38\lib\site-packages\xarm_python_sdk-1.11.2-py3.8.egg\xarm\wrapper\xarm_api.py", line 2441, in set_position_aa
    return self._arm.set_position_aa(axis_angle_pose, speed=speed, mvacc=mvacc, mvtime=mvtime,
  File "C:\Users\Scott Paterson\AppData\Local\Programs\Python\Python38\lib\site-packages\xarm_python_sdk-1.11.2-py3.8.egg\xarm\x3\decorator.py", line 73, in decorator
    return func(self, *args, **kwargs)
  File "C:\Users\Scott Paterson\AppData\Local\Programs\Python\Python38\lib\site-packages\xarm_python_sdk-1.11.2-py3.8.egg\xarm\x3\decorator.py", line 81, in decorator
    return func(self, *args, **kwargs)
  File "C:\Users\Scott Paterson\AppData\Local\Programs\Python\Python38\lib\site-packages\xarm_python_sdk-1.11.2-py3.8.egg\xarm\x3\decorator.py", line 56, in decorator
    return func(self, *args, **kwargs)
  File "C:\Users\Scott Paterson\AppData\Local\Programs\Python\Python38\lib\site-packages\xarm_python_sdk-1.11.2-py3.8.egg\xarm\x3\xarm.py", line 284, in set_position_aa
    ret = self.arm_cmd.move_relative(tcp_pos, spd, acc, mvt, radius, False, True, only_check_type)
  File "C:\Users\Scott Paterson\AppData\Local\Programs\Python\Python38\lib\site-packages\xarm_python_sdk-1.11.2-py3.8.egg\xarm\core\wrapper\uxbus_cmd.py", line 398, in move_relative
    return self.set_nfp32_with_bytes(XCONF.UxbusReg.MOVE_RELATIVE, float_data, 11, byte_data)
  File "C:\Users\Scott Paterson\AppData\Local\Programs\Python\Python38\lib\site-packages\xarm_python_sdk-1.11.2-py3.8.egg\xarm\core\wrapper\uxbus_cmd.py", line 21, in decorator
    return func(*args, **kwargs)
  File "C:\Users\Scott Paterson\AppData\Local\Programs\Python\Python38\lib\site-packages\xarm_python_sdk-1.11.2-py3.8.egg\xarm\core\wrapper\uxbus_cmd.py", line 130, in set_nfp32_with_bytes
    hexdata = convert.fp32s_to_bytes(datas, num)
  File "C:\Users\Scott Paterson\AppData\Local\Programs\Python\Python38\lib\site-packages\xarm_python_sdk-1.11.2-py3.8.egg\xarm\core\utils\convert.py", line 48, in fp32s_to_bytes
    ret += fp32_to_bytes(data[i])
  File "C:\Users\Scott Paterson\AppData\Local\Programs\Python\Python38\lib\site-packages\xarm_python_sdk-1.11.2-py3.8.egg\xarm\core\utils\convert.py", line 16, in fp32_to_bytes
    return bytes(struct.pack('>f' if is_big_endian else '<f', data))
struct.error: required argument is not a float

[vimior]

@scottrpaterson Sorry, there is a problem with the v1.11.2 SDK and firmware greater than v1.11.100, please update to v1.11.4 SDK.