The robot works well with no error (high precision) when I control it through the teach pendant from point A to point B and back to point A. BUT, when I do the same thing through ROS (moveit package downloaded from fmauch) I found that some errors have been generated, the precision lost. Any tips to solve this problem?
Did you extract your robot’s calibration as shown here ?
Without this you will not achieve high precision controlling your robot with ROS.
Dear Mauch, Thanks for replying. I have extracted the calibration and changed the arg name of “kinematics_config” to the yaml file which was extracted from previous step following the instruction, but the precision is still relatively low (about 0-5mm). This is the feedback I got from extracting the calibration, does it look right to you?
… logging to /home/cheavporchea/.ros/log/bb720f64-5e9f-11eb-a731-002b67b404ab/roslaunch-cheavporchea-ThinkPad-E14-6267.log
Checking log directory for disk usage. This may take a while.
Press Ctrl-C to interrupt
Done checking log file disk usage. Usage is <1GB.
started roslaunch server http://cheavporchea-ThinkPad-E14:33977/
SUMMARY
PARAMETERS
- /calibration_correction/output_filename: /home/cheavporche…
- /calibration_correction/robot_ip: 192.168.1.5
- /rosdistro: melodic
- /rosversion: 1.14.10
NODES
/
calibration_correction (ur_calibration/calibration_correction)
auto-starting new master
process[master]: started with pid [6277]
ROS_MASTER_URI=http://localhost:11311
setting /run_id to bb720f64-5e9f-11eb-a731-002b67b404ab
process[rosout-1]: started with pid [6288]
started core service [/rosout]
process[calibration_correction-2]: started with pid [6292]
[DEBUG]: Starting up producer
[WARNING]: No realtime capabilities found. Consider using a realtime system for better performance
[WARNING]: Failed to read from stream, reconnecting in 1 seconds…
[DEBUG]: Invalid robot package type recieved: 24
[DEBUG]: Invalid robot package type recieved: 23
[DEBUG]: Invalid robot package type recieved: 25
[DEBUG]: Invalid robot package type recieved: 5
[INFO]: checksum: [2435471686 2436226516 289977158 2435159020 2434903170 2434556926 ]
dh_theta: [2.20637797140183e-07 0.281896264503289 5.1498507942956 0.851441668582393 -1.03758142740336e-06 -4.03405263283384e-07 ]
dh_a: [0.000164104779381354 -0.588002389038612 -0.376336564427717 1.76204048586357e-05 -1.23706644687387e-05 0 ]
dh_d: [0.180991501662328 73.1375094671283 176.060251403317 -249.023964327078 0.119953791034914 0.115668144853251 ]
dh_alpha: [1.57091149924835 0.00232834950933609 -0.00172410720524722 1.57062976375797 -1.57268630269435 0 ]
calibration_status: 2
[DEBUG]: Destructing pipeline
[DEBUG]: Stopping pipeline!
[DEBUG]: Pipeline consumer ended!
[DEBUG]: Pipeline producer ended!
[ INFO] [1611532572.651437243]: Writing calibration data to “/home/cheavporchea/new_ur_calibration.yaml”
[ WARN] [1611532572.652332159]: Output file /home/cheavporchea/new_ur_calibration.yaml already exists. Overwriting.
[ INFO] [1611532572.652781625]: Wrote output.
[ INFO] [1611532572.652875052]: Calibration correction done
[calibration_correction-2] process has finished cleanly
log file: /home/cheavporchea/.ros/log/bb720f64-5e9f-11eb-a731-002b67b404ab/calibration_correction-2*.log
Again, thank for your replying.
Paul
This looks correct. Make sure that you load the kinematic parameters from /home/cheavporchea/new_ur_calibration.yaml e.g. by using roslaunch ur_robot_driver <robot_type>_bringup.launch robot_ip:=192.168.1.5 kinematics_config:=/home/cheavporchea/new_ur_calibration.yaml
With this, you can run rosrun tf2_tools echo.py tool0 tool0_controller which should yield a transformation of 0 as it will show the transformation from the URDF model tool0 to the one reported by the controller. For this to be 0, the tool configuration on the teach panel has to be set to all 0! Otherwise you will see the tool transformation as setup on the teach pendant.
I’ve followed your instruction. The feedback from echo.py looks good as shown below. However, the errors still appears in every loops randomly (0-5mm). It won’t happen when I control from the teach panel.
At time 1611704657.68, (current time 1611704657.73)
- Translation: [0.000, 0.000, 0.000]
- Rotation: in Quaternion [0.000, -0.000, 0.000, -1.000]
in RPY (radian) [-0.000, 0.000, -0.000]
in RPY (degree) [-0.007, 0.001, -0.001]
At time 1611704658.7, (current time 1611704658.73) - Translation: [0.000, 0.000, 0.000]
- Rotation: in Quaternion [0.000, -0.000, 0.000, -1.000]
in RPY (radian) [-0.000, 0.000, -0.000]
in RPY (degree) [-0.005, 0.004, -0.001]
Hi Mauch, what else I should do to increase the precision of the robotic arm when I control it through ROS? After the above instruction, the errors still appear randomly (0-5mm). I have mounted a realsense camera on it, the inertia of the arm might be slightly changed. Does it affect the precision?
What do you mean by the error? What are you trying to achieve, what are you doing? I thought you meant the error between the tool0_controller and the tool0 frame which you confirmed that it is 0.
Hi Mauch
Thank you so much for replying and sorry for the unclear description.
What I am doing is that:
I tried to control the UR10e through ROS to move from A to B and then back to A. and we monitored the pose (x,y,z,rx,ry,rz) of the end-effector on the teach pendant and the camera.
The problem I have faced is that:
The precision of the robotic arm is not enough for the job when we control it through ROS. For example, we move the end-effector from A to B by a translation of 100mm in x-direction and back to A. What we got from the teach pendant was A(0,0,0,0,0,0) to B(0.0991, 0.0022 ,0.0014 ,0.005, -0.002, 0.001) and A (0.0021, -0.0012, 0.005, 0.003, 0.004, -0.003)
The end-effector cannot precisely reach the target that we had set. the range of error (bias) is about -5 to 5 mm. Values of the errors are random (For example: -2mm, -1mm, 4mm, 3mm). BUT, the precision is pretty high (<0.5mm) when we control it through the teach pendant.
What we are trying to achieve:
Control the arm through ROS to do a pose with high precision (error<1mm).
What we have tried:
Calibration by generating the yaml file, and use it following the above instruction.
Set the parameter of kinematics_solver_search_resolution to 0.0005
Trying different kinematics_solver (KDL and TRAC_IK)
Add decimal places in the variables (pose_A.pose.position.x = pose_B.pose.position.y + 0.10000
For this, it would be interesting to narrow it down to either the kinematics solver or the joint-based execution. If it’s the joint-based execution there is a serious flaw that should be further pursued inside a Github issue.
If you move from one joint configuration to another and back to the first, you should definitely reach it precisely.
Could you please post the commands that you send to the driver’s goal / command topic (whichever you are using).
The problem is solved. Thank Mauch.
It’s all my bad I didn’t set the goal_tolerance properly in the script.
Thanks for your patience and reply.