Question about EGM tracking speed and accuracy

[Wojcik98]

I have been testing how fast can the EGM track received positions and how much the current position deviates from it. Tests were in pose mode, all parameters with default values except MaxSpeedDeviation which was 10'000 to not limit the movement. Trajectory used (x, y, z values):

• 450, 0, 700
• 450, 100, 700
• 450, 100, 600
• 500, 100, 600
• 500, -100, 600
• 450, -100, 700
• 450, 0, 700

I tested it with different speeds (or rather duration times using EGMTrajectoryInterface) and plotted the difference between desired and actual position (from libegm logging S_REF_POS_<coord> - R_FB_POS_<coord>).

The biggest error was over 15cm and for lower speeds the typical error was still over 3cm. Those are quite large considering EGM is supposed to be used for real-time control. Are those errors expected? I have tried to increase Default Proportional Position Gain to 12. It slightly reduced the error, but introduced overshoot and small oscillations. Setting gain to 20 further decreased the error and increased oscillations.

Is there a way to reduce those errors? Is it possible it is caused by wrong settings? Maybe controlling with velocities instead of position could be a better solution?

I am using RobotStudio with RobotWare 6.11.2019.

[marekcygan]

@jontje any chance that you could comment on the issue above? We are looking now into velocity control to check discrepancies there.

[jontje]

It's been awhile since I used the EGMTrajectoryInterface, but here are a few things you could investigate:

• When instantiating EGMTrajectoryInterface you can set a configuration similar to this:

  abb::egm::TrajectoryConfiguration config;
  config.spline_method = abb::egm::TrajectoryConfiguration::Quintic;
  config.base.use_velocity_outputs = true;
  abb::egm::EGMTrajectoryInterface egm_interface(io_service, 6511, config);

  The use_velocity_outputs flag should be helpful to minimize the trajectory error, and you could also try the different options for spline_method.

• Another thing you could try is to use raw EGM commands (they should be filtered by default), and this can be set in the robot controller's configurations via: RobotStudio --> Controller tab --> Configuration --> Motion --> External Motion Interface Data --> Set Level to Raw (i.e. for the configuration instance you are using).

• You can also monitor the EGM channel's utilization rate during the trajectory execution. I.e. with egm_interface.getStatus().utilization_rate(), and if this value is greater than 100, then the robot controller will automatically attempt to reduce the acceleration. This will affect how well the robot can track the trajectory, and if your EGM commands are too aggressive, then you could e.g. increase the trajectory's execution duration.

• Finally, if you have a tool then you should also set the correct tooldata in the RAPID code (more important for real robots).

I hope this can help!

[marekcygan]

@jontje we will definitely try those and get back to you, thanks!

[Wojcik98]

Thanks for suggestions @jontje! Disabling filtering removed majority of oscillations and slightly reduced error. We could then safely increase position gain to 20 which decreased the error even further with only small overshoot.

Enabling velocity outputs also significantly reduced error.

In the end the error was reduced from over 100mm to below 25mm, and it was caused mainly by latency between sending position and robot executing it. After shifting desired and measured trajectories by a few samples to account for latency the errors are even smaller. (plot below shows only y axis)

Thanks again for your help.

[jontje]

Thanks for suggestions @jontje!

No problem, I'm happy to help 😄

[mkatliar]

Hello,

I have some new questions about EGM.

We use EGM for joint trajectory following, and our trajectories are quite fast. We provide both joint position and velocity reference to EGM, and use the "Raw" correction level. Below are examples of how the same reference trajectory is followed for different proportional position gain values:

Figure 1. gain=10

Figure 2. gain=5

Figure 3. gain=1

Figure 4. gain=0

In all cases, trajectory tracking is far from perfect. For gain=0 we achieve very good velocity tracking, but the position trajectory is shifted. There seems to be a dead time of ~50ms (Figure 5), which results in the velocity commands at the beginning of the trajectory being ignored, and therefore offset in the position. Also, without position gain, the position is expected to drift anyway.

Figure 5. Dead time

Adding a small position gain results in a significant deviation from the reference trajectory, and very slow convergence to the final position after the motion has ended (Figure 3).

Do you guys have any idea on how we can improve the trajectory tracking? @jontje could you help?

I have also noticed that there is a time field in the EgmPlanned message:

message EgmPlanned              // Planned  position for robot (joints or cartesian) and additional axis (array of 6 values)
{                               // Is used for position streaming (source: controller) and position guidance (source: sensor)
    optional EgmJoints  joints = 1;
    optional EgmPose    cartesian = 2;
    optional EgmJoints  externalJoints = 3;
    optional EgmClock   time = 4;
}

but I could not find in the documentation what it is for. I guess it can be related to specifying the reference ahead in time and can be used to deal with the dead time / trajectory offset. Do you know how is this field used?