Hi all,
Can KUKA smooth trajectory between:
routine1()
routine2()
CONTINUE doesn't help
Hi all,
Can KUKA smooth trajectory between:
routine1()
routine2()
CONTINUE doesn't help
Hi all,
I have MA1440 DX200. It has limit of T-axis (joint 6) +/-210 degrees. I want to increase it to +/- 350 deg. Am I right that T-axis physically has endless rotation?
I can't do it from Software limits or using Maintenance Mode. I also tried to change PARAMETER->S1CxG 405 and 413 fields but after that I had PULSE MECHANICAL LIMIT.
How can I do it?
what is the load?
Torch ~5 kg + load at 3-rd link
So is it near a singularity or near the edge of its envelope?
Not near to singularity...and speed is small. This KUKA doesn't has big deviation at singularity.
apparently it is two linear movements
Green is ideal (program, from src). But red - real trajectory. Why 2 linear?
Display MoreJust to be sure about your data: how did you record the positions exactly? Oscilloscope alias Trace? Which channel? $Pos_act? AXIS_act?
Is the robot equipped with absolute accuracy?
How do the recorded positions relate to the joint positions?
Fubini
$AXIS_ACT and then calculating forward kinematics at external computer. Send to external computer via EthernetKrl.
No absolute accuracy...unfortunately.
We are calculating whole traj at external computer. Then calculate joints and send to KUKA. Green points is FKP of this joints. Red points - FKP of joints received from KUKA by reading $AXIS_ACT.
This problem is very rare. Robot can weld 24h many days and suddenly at one trajectory occurs this problem. I didn't write but robot also slows down during this motion.
Hi all,
Sometimes robot KUKA KR8 R2100 has strange linear trajectory. I recorded real poses from controller (red points at picture, there is high density of points because of small speed). Green points are program trajectory in src.
It is LIN motion but looks like PTP. How can it be? It's rare case, 99% similar trajectories (with different coordinates) are good (linear).
TCP, load data are right. C_DIS = 0.5 mm but smoothing doesn't affect it because deviation is between points.
Linear commands:LIN FORWARD(joints[0], error_id) C_DIS
LIN FORWARD(joints[1], error_id) C_DIS
...
Joints are calculated by external computer. Green points are equal to joints after forward kinematics calculation.
Right tool is set to variable $TOOL.
Scale is 1cm (right bottom corner). Smallest distance between program (green) points is ~1 mm. I am not sure but may be rebooting of controller helps for a time.
Yes, tool is right. Deviation is because of robot dynamics
Hi all,
I have troubles with linear trajectory while welding. Sometimes robot has big deviation from program path. There're 2 lines at picture:
- program (ideal) traj - white line + white points.
- real traj - red line.
Deviation at picture is huge (about 4 mm). Velocity is very small ~6 mm/sec. Tool is right. It isn't near to singularity.
Robot has reorientation but not large (joint rotation not critical). Path is good without reorientation. But I need this reorientation.
I add to ARM Control right load data for S-head and U-arm. Tool load data also is correct. Smoothing is very small (~0.1 mm).
How can I improve path accuracy? May be by changing some internal parameters? May be YASKAWA has a flag - reducing velocity for saving accuracy? Robot is MA1440 (DX200). It is new (1 year old).
Controller is in Managment mode but still no Arm Control:
Hi all,
How can I set load data for link 3? Controller is DX200
I have 2 robots YASKAWA: MA1440 (ground mounting) and MA2010 (ceiling). Controllers DX200.
Both robots make similar linear movements but do it differently. Movements are near wrist singularity (but not through singular position).
MA1440 does it right way. It slightly slows down (reduces linear velocity) and do right linear motion without deviation from the trajectory.
But MA2010 saves the speed and has deviation from linear trajectory.
Is it possible that there is a flag (variable) to change robot behaviour? For example variable in system settings for switching modes: save speed or accuracy.
Load data is correct.
I think that Fubini gave the answer. But I should understand how to write formulas for it.
midpoint - I get current coordinates from robot in the ~middle of path between 2 points.
I can't post actual program code because we generate trajectory outside the robot. We check collisions, limits, singularities, etc. with small step and send trajectory to robot receiving it by EthernetKrl. We generate path with small step (1 mm or 0.1 deg) but send to robot only significant key points because there are a lot of points. Code at KRL is like this:
...
SREAD(bytes[], state, offset, "%f %f %f %f %f %f", joints[i].A1, joints[i].A2, joints[i].A3, joints[i].A4, joints[i].A5, joints[i].A6)
...
LIN FORWARD(joints[i], error_id)
Everything is good, we weld huge beams. But our generated trajectory isn't almost identical with trajectory at KUKA because of different math law of changing orientation.
Good way is to send more points with small step to robot but it takes more time.
The question is:
Robot moves with LIN motion from pose P1 (X=500, Y=500, Z=500, A=20, B=40, C=60) to pose P2 (X=600, Y=600, Z=600, A=60, B=80, C=100) without smoothing. What is the law of changing orientation (ABC angles)? It isn't slerp (spherical linear interpolation).
Can You describe how You measured that? And what do You mean by "long complex 90 deg rotation"? Desribe the motion a bit clearer.
Is the TCP correct?
Is the robot mastered correct?
Do you think that KUKA should use slerp? May be I have been mistaken...
But I found only info for XYZ in docs:
"In the case of a linear motion, the KR C... calculates a straight line from the current position (the last point programmed in the program) to the position specified in the motion command."
And no information about kind of interpolation of orientation. But I don't have KUKA confidential docs, only public. And there no info about it.
I use quaternions and slerp from ROS package (it is library for robots) and also checked it from https://en.wikipedia.org/wiki/Slerp. And slerp is correct.
Robot is mastered. TCP is correct.
I send robot from start pose to goal (only 2 poses) with LIN motion. Distance between them is ~3m and ~90 deg (complex rotation A+B+C angles). No smoothing. Velocity is 150 mm/sec.
I get ~midpoint from robot while motion to goal pose. And also I calculated all trajectory outside the robot (C++ program). Linearity of XYZ is the best. But orientation interpolation is similiar to slerp but not identical (max difference for my case is 8 degrees).
Hi all!
I have welding KUKA KR8 R2100 and I am generating the motions outside from the robot. I've done experiments and understand that KUKA doesn't use SLERP for interpolation of orientation in LIN motions. It's something similiar but while long complex 90 deg rotation it has 8 deg difference.
Of course I can generate more intermediate points and minimize the error. But it's interesting what interpolation of orientation algorithm is used by KUKA and why it is not a slerp.
Hi all!
BUFFSIZE in EthernetKRL 3.0 has max size = 65,534 bytes. I want to send large msg with size >64 kB. The easyiest way is to increase this limit. Is it possible?
From docs:
Should be FINE (no smoothing) in the target point
Hi all!
I usually have error "Deviation at target point". I use standard triangle weavings from ArcTech Basic. What is cause of this error?
I don't have integer number of sinus waves. For example I have seam 101 mm, but sinus weave is 5 mm length. 101/5 = 20.2 waves
Can I fix it by changing frequency? For example slightly increase / decrease it and sinus wave length become 5.05 mm because 101/5.05 = 20 waves?
Is it the cause of problem?
why do you think that?
Because gravity affects J1 of wall mounted robot. But not affect (has much smaller affect) J1 of floor or ceiling mounted.
Quotefor example elasticity compensation etc can be switched on/off etc.
Can I find this parameter in $robcor.dat or $machine.dat? Or it is only for HA robots? Is it affect position (static) accuracy?
Hi all,
I have KUKA KR8 R2100 ARC HW mounted at wall (90 deg, it's configured correctly in WorkVisual).
I have some problems with accuracy (absolute accuracy, not repeatability). Recently I've checked mastering and realized that it's not const for J1. It depends on J2 and J3 angles. I rotated J2 and J3 and mastering for J1 changed. The max difference that I've found is 0.04 deg.
I didn't checked but I think that the same problem happens for J2 and J3.
Of course I've done final mastering for J1 when J2 and J3 are also in positions for mastering. But I understood that gravity has effect on robot accuracy. The total error may be ... 3 mm at bad position. May be larger because mastering position for J1 is only ~20 deg. Gravity error will be larger for J1 = 90 deg.
Does KUKA have gravity compensation for standard robot? Or it's included only in additional option (ABS, HA)?
I think that gravity compensation can use only known parameters: kinematics, weights of links, centers of mass, mount angle. There are no required to do accurate measurements with laser tracker.
I think that for floor or ceiling mounted robots mastering for J1 will be the same for different J2, J3.