I am trying to run some calibration tests for IMU and Vive VR motion tracking on the xArm. The Vive headset (and independent IMU) are mounted on a mannequin head. Because I really don’t want to destroy the headset with impacts or have it fall off the end effector, I would rather have the head facing ‘upwards’. This is where I am running into issues.
1) When using reports how is the velocity of the end effector calculated? I have used the locations and timestamps from the report to derive distance/time and there are some points where I am seeing discrepancies of up to several orders of magnitude as compared to the claimed x,y,z velocity.
2) When reports are generated what frame of reference are roll/pitch/yaw measured from?
3) I have only been successful in using the arm.set_position() command to run with the final links toolhead parallel to 'ground' . Is there a way to use the set_position() command to run with it facing upwards parallel to the ground?
4) Will doing the inverse kinematics myself and using set_servos() allow motion paths which keep the 'head' upright?
5) I have been running into some problems with the set_collision_tool_model(). It seems that rather than planning motion paths that keep the head at an adequate radius, instead it simply stops motion paths that get too close entirely and generates an error. Is there a way to instead fence off a specific region around the center that the toolhead should route around or will this also require explicitly doing inverse kinematics to avoid?
6) What does the set_collision_rebound(True) actually do? It does not seem to redirect on a collision. Instead it just generates an error and stops all motion.
7) What does the set_allow_approx_motion(True) command do? It does not seem to make a difference on allowing the robot to come up with a viable path.
8) What does the bypassing singularities toggle in the ufactory studio do? It also does not make any observable difference.
9) Is there a way to automate error handling and clearing in the python sdk? Currently I have a subfunction that pauses my script. I then follow a sequence of :
a. go to the ufactory Studio interface,
b. clear error
c. Press enter to resume script
d. Subfunction then runs following commands:
arm.clean_warn()
arm.clean_error()
arm.motion_enable(True)
arm.set_mode(0)
arm.set_state(0)
arm.set_tcp_jerk (10000)
arm.set_joint_jerk (500)
arm.set_allow_approx_motion(True) #
What I would like to do is have a callback to recognize the errors themselves to give more granularity. For example:
• 21: Kinematic Error:
§ automatically pause for n seconds,
§ Run a command to 'align hand'
§ clear error
§ go to next path instructed
• 23: Joints Angle Exceed Limit:
§ Pause for n seconds
§ Return to the last valid point in joints limit
§ Move to next programmed position
• 24: Speed Exceeds Limit:
§ Try:
□ adjust speed down, clear error, retry motion, adjust speed back to default
§ Except:
□ Add more points to path, clear error, and retry motion
1.How do you control the arm? Which mode do you use? How did you calculate it? Please send us the reported velocity and your calculation result.
2. It refers to base coordinates.
3/4. Do you use xArm5/xarm6/xarm7? Please share the SN.
5. It only add the model of the end effector for self collision detection, and report an error when it is about to self-collision, you ned to implement obstacle avoidance yourself.
6. It will bounce slightly and then stop the arm.
7/8. It allows to avoid overspeed near some singularities using approximate solutions. Actually ‘bypassing singularities’ is equal to set_allow_approx_motion(True).
9. You can get the error code via get_err_warn_code and handle it yourself. But some errors can’t not be cleared by the script, for example code 23- ‘joint angle exceed limit’, you have to unlock the joint and move the joint within the limit.
For control of the arm the points programmed were in cartesian coordinates using the set_position() command and/or arm.set_servo() command depending on which was appropriate for the individual motion path. A report was streamed from the IP socket and written to a log via a subprocess call. The report included timestamps, locations, and velocities. I compared these to hand calculated velocities at each step where v_t = (position(t) - position(t-1))/(time(t)- time(t-1))
Perfect. I had assumed that to be the case but had to confirm.
I am using the xArm5. The model is XF1203. I do not have the serial number handy and won’t physically be on site till next week.
is there a programmatic way to set an area inside the reach of the arm that the arm will avoid, or is it purely a matter of hard coding the kinematics.
So essentially a safety measure to give space for the devices
So it will avoid some areas of known difficulty, but no guarantee it will avoid all of them. Gotcha.
Is there a list of which codes can be cleared automatically by a script vs which ones cannot? That way I can populate function to clear those automatically and tell me to go to the uFactory Studio for the rest.
The below images plot the measured velocities based on positions (cartesian) / time, the measured values from the report sent by xArm, and the commanded values sent from control box. Samples of linear velocity on the z axis
1, I assume you use port 30000 for data reports. We can reproduce the problem, sometimes the calculated velocities are quite different from the reported one. There may be some delay between the timestamps and actual locations, while the speed we reported is calculated in real time inside our controller, which should be more accurate.
We tried to optimize and indeed made some improvements, but we need more tests, we will evaluate if we can improve it in the new firmware. We recommend you use the reported velocity, if you want to calculate it yourself, you can do some filtering.
3, For xArm5, due to configuration limitations, the toolhead must parallel to ground during linear motion.
4. No, some third-party libs allow you to add objects to space and plan the trajectory, please research it yourself.
7. We listed the error handling in our user manual, please check Appendix 1, just for your reference.
Hi Minna,
Thanks for the prompt response.
1Thanks for the clarification. I will use the speed calculated on the controller going forward.
3 I am aware of that. However I have noticed that when the toolhead is parallel to the ground but facing upwards it generates many C21 and C23 errors even for small motions. Is facing the ground as well as parallel a specific constraint?
4 Do you have any examples of these libraries in python which have been tested with the xArm5? The issues I am facing with using the xArm already have me somewhat behind me schedule. It would save considerable time and get me back on schedule if there was a ‘known good’ library to work with.
7 I am aware of information in Appendix 1 and have read through it a few times. Pages 216-222 are where I got the commands I am using in my fixArm() function (appended to end of message). However I am a bit confused as to how controller errors are handled. In theory some of the controller errors could be could be handled by functions Python if there was a way to capture their codes programmatically. The most common errors I am seeing are (C21, C22, C24, and Large Motor Position Deviation). What I propose to do if these errors can be captured is:
C21: In my experience this normally is thrown when the generated path moves the arm to a position where it is not parallel with ground. I then have to align the hand in uStudio. What I would like to do is:
Capture error
Run fixArm()
Command to align hand with ground (does this exist in Python toolkit?)
Continue script
C22: Joints Angle Exceed Limit (does this correlate to error -8 in the python env?):
Capture error
Delay n seconds (random positions are actually preferable for calibrating IMU)
Run fixArm()
Goto last valid position (is this a thing that can be pulled programmatically, or would I need to simply go to the last step prior to the error?)
Continue script
C24: Speed Exceeds Limit:
Capture Error:
try:
a. Clear Error
b. Adjust the speed parameter down by 100 m/s
c. Retry motion
except:
a. Add another segment between current position and end point
b. Retry Path
c. Set speed parameters back to default
Large Motor Position Deviation:
As I understand it this is a gripper error. I am not actually running a gripper. Is there a root cause for this error that can be handled programmatically or some ground rules for my code that would help avoid generating this error?
8 What do C,J, D, K represent in the figure you attached to your reply? And what is do the before vs after plots represent? The after plot looks like perhaps some filtering algorithm was applied to smooth the spikes observed on J?
Thanks,
ldankovi
…function for fixing/ initiallizing arm…
def fixArm(arm, params=params, code=0, mode=0, running=True):
‘’‘Function is called to either initialize the arm, or to clear errors and reinitialize.
inputs:
arm: arm object in xARm
params: params to be passed as needed
code: Optional: if there is an error code it is passed here
mode: Optional: what mode is arm in. We will set default to zero
running: Boolean: If True we clear errors on arm. If false we don’t have errors and are just initializing the arm
‘’’
if running:
print(‘Clearing errors on the arm’)
if code not in [-1,1,2,9]:
cont=input("Error requires manual intervention in STUDIO. Please fix and press enter to continue ")
else:
arm.clean_warn()
arm.clean_error()
else:
arm.set_allow_approx_motion(True) # allows for us to adapt motions to constraint
arm.motion_enable(True) # enable/reenable motion
arm.set_mode(mode) # sets type of motion. In general type 0 applies to this script
arm.set_state(0) # sets state. 0 allows arm to run
arm.set_tcp_jerk (params[‘tcp_jerk’])
arm.set_joint_jerk (params[‘joint_jerk’], is_radian = False) # Changed to false for sanity reasons
return
7,
C21: You can calculate J4 joint angle via: J4 = -(J2+J3) and set it, this way the end is aligned.
C23：-8 may not correspond to C23. For this error, you can’t solve it via script, you need to unlock the joint and move it within the joint limit.
C24: If it is indeed overspeed, please reduce the speed. If it is a singularity, I suggest you turn on the ‘bypassing singularities’ option.
S23: large motor position deviation, it has nothing to do with the gripper. Maybe the speed is too fast and the motor can not follow very well, you can provide the initial and target position to us, we will check.
8,The blue line is the reported velocity, the read line is the calculated velocity. We didn’t use the filtering algorithm, we optimized the logic of data report, but we need to do more tests, please use the reported velocity.
Hi Minna,
3) thanks for confirming
4) I have been through these examples many times in developing my Python scripts. Which example are you referring to? The most applicable one seems to be xArm-Python-SDK/example/wrapper/common/6002-set_fense_mode.py at master · xArm-Developer/xArm-Python-SDK · GitHub but I am unclear whether the arm.set_reduced_tcp_boundary() command will a) cause the arm to calculate paths that avoid the boundary on its own, or b) simply stop the arm should the reduced boundary be entered. If it is case b what error message might I expect?
7) a) for errors C21, C22, C23, C24, s23 is there a mapping to which error code would be returned in the Python environment? The codes listed on page 214 of v2.0 of the manual do not seem to correspond directly to the controller errors from page 209-212.
C21. part of my motion code calculates and sets this angle prior to each motion for safety.
C23: is there a specific error code in python that will indicate this error has occurred?
C24,S23: a) Assuming it is overspeed, that implies that somewhere along the motion path one of the joints is going above the recommended maximum speed. I know on page 172 of the manual v2.0 this is mentioned as a possibility. Is there any parameter that can be sent to path planning commands to ensure that joints remain under the maximum joint speeds while still moving at maximum safe velocities? b) In V 2.0 of the manual you recommend an acceleration of 20x the maximum velocity for smooth motion. There does not appear to be guidance for the jerk parameter. Can setting jerk too high cause some of the C24, S23 errors I am seeing? c) I will try to reproduce the error on Wednesday and get back to you with parameters.
4, b)It will simply stop the arm, An error C35 will be reported.
7, get_err_warn_code will return the error code listed in controller error code docs, get_gripper_err_code will return the code listed in gripper error code docs, they are different.
The code listed on Page 214 is the error of the gripper.
C23: API code -7: joint angle limit
C24: a) No b)it’s up to your application. Anyway, please provide a specific example to us, we will check.
