Posts by kazoo

For remote control or visual servo application, I’d like to stream the target position every 10-50 milliseconds from my Linux PC, and each update would only change the destination around 1-100 millimeter. By doing this, I’d like to create a smooth motion. I want to realize both in Cartesian space control and in Joint space control, but let’s discuss Cartesian space first.

My problem is that the robot movement is very jittery. I’m using RTDE (real-time data exchange) and running the same urp file which you can find here: https://www.universal-robots.com/how-tos-and-fa…de-guide-22229/
The motion I tried to create was simple: just moving up 200 millimeters toward +Z direction, then moving down 200 millimeters toward -Z direction. I was sending the target update (absolute target position in robot’s Base Frame) every 50 msec, and I was changing 10 millimeters for every update. However, the movement was very jittery or the repetition of small “start and stop” movement. The original urp file uses “MoveL” command, so I tried to tune the parameters (by changing from “Stop at this point” to “Blend with radius”), but it didn’t work.

When I implemented the similar functionality on ABB, I could use EGM (Externally Guided Motion), which you can stream the point, and the robot follows the point it gets every update. Alternatively, when I implemented for DensoWave or Mitsubishi, I could use “Cancel” or “Skip” command for each “Move” command to override the old target. I’m wondering if there are any commands/options that I can use for Universal Robots.

Are there any ways/commands to realize above smooth real-time target-update movement?

1. You don't necessarily need to use RTDE (you can send the request every time through RealTime Client), but I think it's better to use RTDE because it doesn't require the time to process the command.

2. You can download some sample codes at the bottom of this manual: https://www.universal-robots.com/how-tos-and-fa…de-guide-22229/

These are motion parameters set to `SmartServoLIN`'s `setMaxTranslationVelocity` and `setMaxAcceleration`.

I'm using IIWA's SmartServoLIN mode and I have a trouble with the sudden stop. When the robot tries to reach far, it sometimes stops. The message on Teaching Pedant is as follows:
"Application was stopped due to the following error:
com.kuka.roboticsAPI.executionModel.CommandInvalidException: Error while executing
com.kuka.roboticsAPI.motionModel.SmartServoLIN@... on device LBR_iiwa_14_R820_1. Speed limit detected at
com.kuka.roboticsAPI.controllerModel.sunrise.SunriseExecutionService$ErrorHandlerRunner.run
...."

Currently, I set the parameters such as translational velocity (around 1000-2000 mm/s), acceleration (around 1000 mm/s2), rotational velocity and acceleration. I can make these small to avoid the sudden stop, but at the same time, I don't want to make the robot movement slow if not necessary.

It seems SmartServoLIN cannot handle its joint speed limit or something by itself. Are there any ways to avoid the sudden stop when the robot arm tries to reach far?

Sorry, I submitted KR robot's question to IIWA's board...

I plan to buy Kuka robot for the first time. When I get the quote, MEMD is listed as an option and I'm wondering I need to buy this or not. It looks the special tool. Can I do the mastering process without having this (for ABB robot, I usually do by hand like this:

Kuka's representative says "You can master a robot without an MEMD but your robot movements with not be as accurate afterward." Does this mean there is a quality’s difference between hand mastering and MEMD? In my application, I don’t need sub-millimeter accuracy. I can do hand mastering per a year / a half year, but if I need to do more, I may need to consider MEMD.

The reason I asked about changing speed/acceleration and restriction is that it seems SmartServoLIN's movement is relatively slow. I wonder how I can improve the speed by changing the speed/acceleration during several motions among waypoints.

Hi kiiwa, thank you for replying. I was using SmartServoLIN for my remote control application. However, I needed to move from point A to B in some situation before and after I used SmartServoLIN.

Have you used PtP and SmartServoLIN in the same program (If not, I should look whether it's possible or not)?

Another question comes up in mind is about the speed and the acceleration. If I create several waypoints (to make a circle trajectory from A to B) for SmartServoLIN, are the speed and the acceleration same as PtP's one-stop motion? Or, is it possible that SmartServoLIN restricts the speed and/or the acceleration? I'm trying to understand the downside of SmartServoLIN.

No answer?

Are there any functions on IIWA 14 to control/teach the robot by physically guiding through it? ABB's YuMi has the function called "lead-through" mode (

Do you mean SmartServoLIN can't move in the same way?

In the manual (KUKA_SunriseConnectivity_Servoing), it says PTP and LIN use "Polynomial" for the planning, while SmartServo and SmartServoLIN use "3rd-order polynomial". Is this related to this issue?

I'm using iiwa14 and have a problem. I'd like to move the robot from x,y = A(0, -500) to B(500, 0). When I ran SmartServoLIN and tried to move the robot's tool center point from point A to B, the robot stopped during the operation because the robot entered the area it couldn't reach (the value of axis 4 was nearly the limitation at that time). I thought the SmartServoLIN could handle this simple path planning (just avoiding the area it can't reach), but it didn't and it just crashed. Of course, I can manually set the waypoint, but I don't want to hardcode the waypoint.

Is there any way to avoid this issue and to move the robot from A to B safely? The attached file describes the situation.

I have a question about how to create a smooth movement by feeding a series of the target points on YuMi. I’m trying to move the TCP based on 3D mouse input. For IRB, it was easy because I could use EGM.

Currently, I’m sending the targets via TCP/IP communication by mostly using open_abb like code. Every PC running cycle, I send the following instruction to the robot. Params{1} - {7} is the position and the pose of the next target. I can change the frequency to send, and I tried 0.02, 0.1 and 0.2 sec (= 50Hz, 10Hz, 5Hz).
cartesianTarget :=[[params{1},params{2},params{3}],
[params{4},params{5},params{6},params{7}],
initialCartesianPose.robconf,
externalAxis];

MoveJ cartesianTarget, v100, z0, currentTool \WObj:=currentWobj ;
However, the movement created wasn’t what I wanted. The robot repeated small movement and stopped around every 0.2 - 0.5 sec and didn’t move smoothly (and had a lot of “50024 Corner path failure” warnings). I observed that the robot executed around 3 - 5 MoveJ intrusions and then stopped for every small movement cycle. The length between each target was around 10-20 mm in the most of the case, it was sometimes around 5mm, but still bigger than the size of zone area for fly-by point setting.

To understand how PP works and how close I can set each target point, I also conducted the following experiment. Based on a given number, the following code created many targets and moved the robot as it drew a circle. Of course, if I feed too big number like 1000, the robot won’t move smoothly because of the corner path failure or “50124 zone converted to fine point”. When I used 600 points, the robot still moved very smoothly. 600 points mean 0.6 degree per one movement from point to point (= around 1mm in this setting, which is bigger than z0 zoning setting) and each single movement takes around 0.01sec to complete.
FOR i FROM 1 TO (params{1}) DO
cartesianTarget :=[[300+100*Sin(360*i/params{1}),-300+100*Cos(360*i/params{1}),250],
[0,0,1,0],
initialCartesianPose.robconf,
externalAxis];
MoveJ cartesianTarget, v100, z0, currentTool \WObj:=currentWobj ;

ENDFOR

To me, the conditions such as a number of points, the length between the points were much strict in the second implementation, but it did work.
Then, here is my question; Why the first implementation didn’t make a smooth movement? How can I make a smooth movement based on it?

I plan to make a mouse or a gesture control robot like this (

For a 6-axes robot, I could implement it by using ABB’s EGM (Externally Guided Motion) option, which allows to send a Cartesian position and pose of TCP. However, when I started to work on YuMi, I noticed that EGM’s position guide control cannot be applied to the 7-axes robot (For YuMi, a joint control mode in EGM is only available).

Are there any recommendations to implement what I described above?
Also, I'm guessing that I need to implement IK class to get the correct joints' angles from a desirable TCP position. Maybe using OpenRAVE or OMPL? If you have any recommendation to calculate IK / Inverse Jacobian, please let me know too.

I have a question about YuMi’s movement. What should I set for `confdata` at robtarget?

The initial robot joint position is like the first picture (with Arm angle -164.85 as depicted in the second picture). Because 1st axis is 29.73, 4th axis is -131.89 and 6th axis is -149.08, I set cf1 to 0, cf4 to -2 and cf6 to -2. Also, for cfx, I tried to follow what the manual says (please see the third picture).

Then, the instructions to set the target and to move became like follows:
cartesianTarget :=[[params{1},params{2},params{3}],
[params{4},params{5},params{6},params{7}],
[0,-2,-2,0110],
externalAxis];
MoveL cartesianTarget, currentSpeed, currentZone, currentTool \WObj:=currentWobj ;

However, when I ran this, I got “Using old target definition” error (the fourth picture).
I also tried the simplest conf setting like [0,0,0,0], then the robot started to move its arm to positive direction (it went up to -90 degree or so) and got “Jog in wrong direction” error (the fifth picture).
Note that I tried everything on YuMi’s right arm. I'm using RobotWare 6.05 and tried to follow the new convention to express confdata.

The manual doesn’t show any example setting for YuMi. Could you let me know how I can solve this issue and how to set the confdata?

If you know other programming languages, it's faster to just try several sample codes in the manual. You can use RobotStudio's Virtual Controller if you don't want to break the robot.

I’m trying to use Multitasking on IRB. I’ve already tested on Virtual Controller and worked well.
Then, when I tried to apply it to the actual controller, I had an issue and I need support how to use Multitasking.

When I tried to add New Task from Configuration -> Controller -> Task, it doesn’t allow me to add another task.
I guess this is because of the lack of Multitasking option, so I tried to add that option from Installation Manager.
Unfortunately, it didn’t show anything about Multitasking option, so I couldn’t choose it.
I also tried to “add setting” file from the working Virtual Controller, however, it said, “Option(s) in settings file requires license or product”.

I’m sure I already have a premium license for the RobotStudio. Do I need to get another license (maybe for Robot Controller?) to use Multitasking option? If not, please let me know how I can use it.

Thank you so much! I'll look it!

I’d like to ask about the rotation (Rx, Ry, Ry or roll, pitch, yaw) . The following example is about EGM, but may be same as the normal movement.

When I use EGM’s Tool Frame mode, all 6D axes (x,y,z,Rx,Ry,Rz) follow the Tool Frame (Intrinsic Rotation), which behaves as same as the movement when using Tool Frame during Jogging.

My question is, how EGM’s Base Frame mode behaves for the rotation? When I use EGM as Base Frame mode, translation (x,y,z) movement is based on the Base Frame, so even the tool is tilted, the robot still moves based on the Base Frame, not on the Tool Frame. This is good.
However, when I send the rotation value (Rx,Ry,Rz), the robot rotates based on Tool Frame, not Base Frame, which is different behavior when compared with Jogging under Base Frame.

Is this intended behavior?

Have anyone tried to use the tool in Base Frame mode (not in Tool Frame mode) while using Externally Guided Motion (EGM)?
I’m trying to use Base Frame mode of EGM on IRB120 and having “Dynamic load too high” error. The robot tried to go up (+z) for a very short time (less than 1sec or 0.5msec) and stopped with the error.

What I tried was just to send the current position (translation position = 400, 0, 125, rotation = 0, 1, 0, 0) as a destination. The followings are a snippet of RAPID code I used. If you notice any mistakes, please let me know. When I used Tool Frame mode with the tool or Base Frame mode without the tool, they worked as expected.

TASK PERS tooldata myTool:=[TRUE,[[0,0,275],[1,0,0,0]],[1.0,[0,0,60],[1,0,0,0],0,0,0]];


MoveJ p1, v100, fine, myTool;


EGMActPose egmID1\Tool:= myTool, corr_frame_offs, EGM_FRAME_WORLD, myTool.tframe, EGM_FRAME_BASE \x:=egm_minmax_lin1 \y:=egm_minmax_lin1 \z:=egm_minmax_lin1 \rx:=egm_minmax_rot1 \ry:=egm_minmax_rot1 \rz:=egm_minmax_rot1 \LpFilter:=4, \MaxPosDeviation:=1000 \MaxSpeedDeviation:=1000; 


EGMRunPose egmID1, EGM_STOP_HOLD \x \y \z \Rx \Ry \Rz \CondTime:=300 \RampInTime:=0.05 \PosCorrGain:=1.0;