ABB YuMi increase speed

[robberthofmanfm]

Hi,

We are trying to figure out how to let our YuMi move at maximum speed.
Thanks to this comment #16 (comment) we were able to increase the speed from very slow to acceptable, as in video 1 at 1:03.
However, as can be seen in video 2 at 2:09 where the internal planner is used, the maximum speed of the ABB YuMi is much higher.

Our stack is YuMi, EGM, abb_robot_driver, ros_control, moveit, based off example 3. Except we're using velocity_controllers/JointTrajectoryController instead of velocity_controllers/JointGroupVelocityController.

In ex3_hardware_egm.yaml, we've found that we can put has_velocity_limits to false, but there seems to be no effect on the YuMi's speed.
In ex3_controllers.yaml, we've found that one can add PID gains for the velocity_controllers/JointTrajectoryController. When increasing velocity_ff, the YuMi actually moves faster, but becomes unstable (overshoot), and while not having a good understanding of ROS controllers, we have a feeling that we shouldn't use velocity_ff.

Are there any other configurations that influence maximum speed?

Best regards,
Robbert

[gavanderhoorn]

My first suggestion would be to check whether MoveIt uses its default acceleration limit of 1 rad/s^2. If you don't specify acceleration limits, all MoveIt time-parameterisation algorithms will use that default.

The driver uses the data coming from the ABB controller itself when it comes to limits, so there isn't anything there artificially keeping things slow. Provided you have increased the EGM limits of course (which it seems you have, as you mention #16 (comment)).

Unfortunately there is no data we can retrieve from the controller via public APIs which gives us acceleration limits, hence the driver does this internally. Note that this data is not used by MoveIt, it's purely internal and used for enforcing limits at the joint level inside the hw iface.

In ex3_controllers.yaml, we've found that one can add PID gains for the velocity_controllers/JointTrajectoryController. When increasing velocity_ff, the YuMi actually moves faster, but becomes unstable (overshoot), and while not having a good understanding of ROS controllers, we have a feeling that we shouldn't use velocity_ff.

there is nothing inherently problematic with adding/enabling it. But as always: as soon as you start using a velocity interface to achieve position control, you'll need to start tweaking PID values. velocity_ff is part of the set of things to tweak.

In ex3_hardware_egm.yaml, we've found that we can put has_velocity_limits to false, but there seems to be no effect on the YuMi's speed.

this doesn't do what I believe you believe it does.

That information is used by the driver to limit velocities at the joint level. There is no direct connection with the information MoveIt uses to time-parameterise your trajectories (you can use that same file to set MoveIt's limits, but that would require changes to your MoveIt configuration).

And, similar to the default acceleration, if you don't provide MoveIt with velocity limits, it's going to assume a 1 rad/s. I doubt that is what you wanted.

[gavanderhoorn]

If you can show or link us to your MoveIt configuration(s) and the specific .launch and .yaml files from the driver you use for your setup, I'm willing to take a look, but I can't guarantee any improvements.

It would also help if you could show all roslaunch output printed during startup of the driver.

Be sure to start your system with roslaunch --screen .., so all output is forced to the screen.

[gavanderhoorn]

Oh and some expectation management: I don't expect you to be able to achieve 100% performance using EGM compared to the built-in RAPID motion planner.

All external motion interfaces come with additional filtering, and limits used are almost always lower than what the internal motion planner is allowed to do.

Additionally, MoveIt (or any '3rd party planner') is for generic use. It's not tuned for YuMi, or ABB robots, at all. It will always be at a disadvantage when comparing it to the internal planner (which has been tweaked and optimised for 40+ years or something).

[gavanderhoorn]

Closing due to inactivity (and because I don't believe we have something to change/improve here in the driver right now).

[gavanderhoorn]

@robberthofmanfm: were you able to improve (perceived) performance?

[robberthofmanfm]

Thank you very much for your valuable suggestions and explanation @gavanderhoorn, it's much appreciated. Please excuse my late reply, I've been on vacation for the past 2 weeks. @ABJFM and I will try these suggestions in the coming weeks (we're not allocated full-time on the YuMi) and report back here as soon as we have results.

[gavanderhoorn]

@robberthofmanfm: did you manage to improve things?

The recently opened (and resolved) #41 might also be something to check.

[robberthofmanfm]

@gavanderhoorn We haven't found the time to test this out. I'm sorry that it's taking this long. Thank you for the reference, good to read that someone can achieve high accelerations and velocities using the driver. I'll add setting the robot to accuracy_mode to the list of possible solutions.

[aatb-ch]

I am noting (as I've reopened the case #41) that we've hit the issue again even in accurary mode and the current fix has been to recompile the driver with disabled joint limits enforcing (not ideal, but we use the max_speed_deviation setting and known pregenerated trajectories to keep things as safe as we can), i'll follow up on the linked issue when I find exactly where this stems from, IRC5 settings, EGM or controller.

[robberthofmanfm]

Just to let you know, I won't be working on the YuMi for the coming 2 months, so I won't report back soon.

[robberthofmanfm]

@gavanderhoorn Many thanks!

My first suggestion would be to check whether MoveIt uses its default acceleration limit of 1 rad/s^2. If you don't specify acceleration limits, all MoveIt time-parameterisation algorithms will use that default.
[...]
And, similar to the default acceleration, if you don't provide MoveIt with velocity limits, it's going to assume a 1 rad/s. I doubt that is what you wanted.

Today we adapted the yaml file specifying the joint limits, setting the has_velocity_limits and has_acceleration_limits to true. The YuMi is now a lot faster, especially for the first part of the trajectory. The last centimeter takes a while, but that probably comes down to PID tuning.

BTW, @aatb-ch I have checked and our setting for Motion Process Mode is optimal_cycle_time, not accuracy_mode.

[aatb-ch]

Hey, thanks this is indeed something i will check. On my end the trajectories are not generated by MoveIt so i didnt think there would be any applied. Do ros_control also apply default acceleration limits somehow? In the abb egm hardware interface it only seemed to enforce velocity limits and not acceleration which is why i have not yet double checked that, but i will explore that issue further as soon as i find time.