Revision history [back]

First: I believe you mean abb_driver, not add_driver, correct?

If so: pay attention to the Status section of that page (or the same section in the readme): while usable, abb_driver is not feature complete, nor will it allow 100% use of the motion performance of your robots (due to the way it interfaces with the controller).

Focus has shifted to abb_robot_driver, which would be recommended to use, provided you have EGM licenses.

Having written that:

They have never even heard about ROS.

I'm not surprised.

Has anyone every come used SafeMove 1 in conjunction with ROS and the add_driver?

Yes, I have.

Something to realise: abb_driver is a simple, user-level task program as far as the ABB controller is concerned. There is no difference in the level of access or control compared to some RAPID code you wrote yourself.

Consequently, SafeMove also doesn't care whether your're running your own RAPID program, abb_driver or something else entirely. It will just function as it always does, meaning it will stop execution of motions if/when they (appear to) go out of the configured safety-limits.

You'll just need to make sure those limits either:

1. correspond to whatever limits are specced by the .urdfs/.xacros and/or MoveIt configuration pkgs you're using, or
2. update any .urdfs/.xacros and/or MoveIt configuration pkgs you intend to use such that the limits in those files and/or packages correspond to whatever limits you've configured SafeMove with

There is no automated support for SafeMove in abb_driver (nor in abb_robot_driver).

It would be interesting to add though (as it would likely come down to extracting some information from the controller's configuration and updating a few configuration files on the ROS side). But it would also be out-of-scope for the driver(s) in a way: joint limits are part of the robot support and MoveIt configuration packages, not of the driver(s).

First: I believe you mean abb_driver, not add_driver, correct?

If so: pay attention to the Status section of that page (or the same section in the readme): while usable, abb_driver is not feature complete, nor will it allow 100% use of the motion performance of your robots (due to the way it interfaces with the controller).

Focus has shifted to abb_robot_driver, which would be recommended to use, provided you have EGM licenses.

Having written that:

They have never even heard about ROS.

I'm not surprised.

I have a small ABB robot that i am using to test parts of our system atm, but am no able to get SafeMove for that, so won't be able to test my setup with the SafeMove setup until it gets to the install.

All available ROS drivers for ABB robots/controllers work with RobotStudio. Can't you create a cell with a SafeMove enabled controller and simulate your setup?

Has anyone every come used SafeMove 1 in conjunction with ROS and the add_driver?

Yes, I have.

Something to realise: abb_driver is a simple, user-level task program as far as the ABB controller is concerned. There is no difference in the level of access or control compared to some RAPID code you wrote yourself.

Consequently, SafeMove also doesn't care whether your're running your own RAPID program, abb_driver or something else entirely. It will just function as it always does, meaning it will stop execution of motions if/when they (appear to) go out of the configured safety-limits.

You'll just need to make sure those limits either:

1. correspond to whatever limits are specced by the .urdfs/.xacros and/or MoveIt configuration pkgs you're using, or
2. update any .urdfs/.xacros and/or MoveIt configuration pkgs you intend to use such that the limits in those files and/or packages correspond to whatever limits you've configured SafeMove with

There is no automated support for SafeMove in abb_driver (nor in abb_robot_driver).

It would be interesting to add though (as it would likely come down to extracting some information from the controller's configuration and updating a few configuration files on the ROS side). But it would also be out-of-scope for the driver(s) in a way: joint limits are part of the robot support and MoveIt configuration packages, not of the driver(s).

First: I believe you mean abb_driver, not add_driver, correct?

If so: pay attention to the Status section of that page (or the same section in the readme): while usable, abb_driver is not feature complete, nor will it allow 100% use of the motion performance of your robots (due to the way it interfaces with the controller).

Focus has shifted to abb_robot_driver, which would be recommended to use, provided you have EGM licenses.

Having written that:

They have never even heard about ROS.

I'm not surprised.

I have a small ABB robot that i am using to test parts of our system atm, but am no able to get SafeMove for that, so won't be able to test my setup with the SafeMove setup until it gets to the install.

All available ROS drivers for ABB robots/controllers work with RobotStudio. Can't you create a cell with a SafeMove enabled controller and simulate your setup?

Has anyone every come used SafeMove 1 in conjunction with ROS and the add_driver?

Yes, I have.

Something to realise: abb_driver is a simple, user-level task program as far as the ABB controller is concerned. There is no difference in the level of access or control compared to some RAPID code you wrote yourself.

Consequently, SafeMove also doesn't care whether your're running your own RAPID program, abb_driver or something else entirely. It will just function as it always does, meaning it will stop execution of motions if/when they (appear to) go out of the configured safety-limits.

You'll just need to make sure those limits either:

1. correspond to whatever limits are specced by the .urdfs/.xacros and/or MoveIt configuration pkgs you're using, or
2. update any .urdfs/.xacros and/or MoveIt configuration pkgs you intend to use such that the limits in those files and/or packages correspond to whatever limits you've configured SafeMove with

The first will likely make no sense, safety-wise (as you'd still allow the robots to use 100% of their work envelope at 100% speed and acceleration). The second is most likely what you'll want/need to do.

There is no automated support for SafeMove in abb_driver (nor in abb_robot_driver).

It would be interesting to add though (as it would likely come down to extracting some information from the controller's configuration and updating a few configuration files on the ROS side). But it would also be out-of-scope for the driver(s) in a way: joint limits are part of the robot support and MoveIt configuration packages, not of the driver(s).

First: I believe you mean abb_driver, not add_driver, correct?

If so: pay attention to the Status section of that page (or the same section in the readme): while usable, abb_driver is not feature complete, nor will it allow 100% use of the motion performance of your robots (due to the way it interfaces with the controller).

Focus has shifted to abb_robot_driver, which would be recommended to use, provided you have EGM licenses.

Having written that:

They have never even heard about ROS.

I'm not surprised.

I have a small ABB robot that i am using to test parts of our system atm, but am no able to get SafeMove for that, so won't be able to test my setup with the SafeMove setup until it gets to the install.

All available ROS drivers for ABB robots/controllers work with RobotStudio. Can't you create a cell with a SafeMove enabled controller and simulate your setup?

Has anyone every come used SafeMove 1 in conjunction with ROS and the add_driver?

Yes, I have.

Something to realise: abb_driver is a simple, user-level task program as far as the ABB controller is concerned. There is no difference in the level of access or control compared to some RAPID code you wrote yourself.

Consequently, SafeMove also doesn't care whether your're running your own RAPID program, abb_driver or something else entirely. It will just function as it always does, meaning it will stop execution of motions if/when they (appear to) go out of the configured safety-limits.

You'll just need to make sure those limits either:

1. correspond to whatever limits are specced by the .urdfs/.xacros and/or MoveIt configuration pkgs you're using, or
2. update any .urdfs/.xacros and/or MoveIt configuration pkgs you intend to use such that the limits in those files and/or packages correspond to whatever limits you've configured SafeMove with

The first will likely make no sense, safety-wise (as you'd still allow the robots to use 100% of their work envelope at 100% speed and acceleration). The second is most likely what you'll want/need to do.

There is no automated support for SafeMove in abb_driver (nor in abb_robot_driver).

It would be interesting to add though (as it would likely come down to extracting some information from the controller's configuration and updating a few configuration files on the ROS side). But it would also be out-of-scope for the driver(s) in a way: joint limits are part of the robot support and MoveIt configuration packages, not of the driver(s).

First: I believe you mean abb_driver, not add_driver, correct?

If so: pay attention to the Status section of that page (or the same section in the readme): while usable, abb_driver is not feature complete, nor will it allow 100% use of the motion performance of your robots (due to the way it interfaces with the controller).

Focus has shifted to abb_robot_driver, which would be recommended to use, provided you have EGM licenses.

Having written that:

They have never even heard about ROS.

I'm not surprised.

I have a small ABB robot that i am using to test parts of our system atm, but am no able to get SafeMove for that, so won't be able to test my setup with the SafeMove setup until it gets to the install.

All available ROS drivers for ABB robots/controllers work are compatible with RobotStudio. Can't you create a cell with a SafeMove enabled controller and simulate your setup?

Has anyone every come used SafeMove 1 in conjunction with ROS and the add_driver?

Yes, I have.

Something to realise: abb_driver is a simple, user-level task program as far as the ABB controller is concerned. There is no difference in the level of access or control compared to some RAPID code you wrote yourself.

Consequently, SafeMove also doesn't care whether your're running your own RAPID program, abb_driver or something else entirely. It will just function as it always does, meaning it will stop execution of motions if/when they (appear to) go out of the configured safety-limits.

You'll just need to make sure those limits either:

1. correspond to whatever limits are specced by the .urdfs/.xacros and/or MoveIt configuration pkgs you're using, or
2. update any .urdfs/.xacros and/or MoveIt configuration pkgs you intend to use such that the limits in those files and/or packages correspond to whatever limits you've configured SafeMove with

The first will likely make no sense, safety-wise (as you'd still allow the robots to use 100% of their work envelope at 100% speed and acceleration). The second is most likely what you'll want/need to do.

There is no automated support for SafeMove in abb_driver (nor in abb_robot_driver).

It would be interesting to add though (as it would likely come down to extracting some information from the controller's configuration and updating a few configuration files on the ROS side). But it would also be out-of-scope for the driver(s) in a way: joint limits are part of the robot support and MoveIt configuration packages, not of the driver(s) (note: I'm referring to joint limit specification, enforcement is of course part of the responsibilities of drivers).