Revision history [back]

But this can also be done without using motoman_driver. for application like this if I use ROS-i, can it seen as here ´not required´? as this can be done also without using it.

using something like ROS (or more generically: a off-controller motion controller) can be beneficial if you wish to use something like sensor based motion planning.

Yes, you can send a Cartesian position to the controller and parameterise an INFORM job with it. And the controller will execute the motion hard-coded in the job, but with some changes based on the position you received from the camera.

If that is all you require, then using MotoROS is probably not going to be more efficient or interesting.

When it does get interesting is when (some examples):

• you want your motion plans to take obstacles into account (the robot controller will not do that, in fact: it will try to move through obstacles)
• when those obstacles are dynamic (ie: they move while the robot is moving)
• when your sensor data is voluminous and heterogenous (there is a lot of sensor data and it's also not all from the same type of sensor)
• when you have a complex motion planning problem that is also changing while the robot is executing it (fi: optimisation of process parameters in an on-line fashion)
• when the robot is only part of a larger system (ie: a 34 dof system in which the 6 (or 7) of the robot are a subset) and planning of motions must take all dofs into account
• when no part of your application can be preprogrammed in an INFORM job (essentially all joint poses are unknown at design time, fi because all future motions will depend on in-situ gathered data)

and there are many more situations in which external control of a robot can be beneficial.

As good as (industrial) robot controllers have become and are at controlling a robot (specifically: the robots of the OEM), robotic applications are typically much more than just a (single) robot. Such applications therefor typically also require more than just the controller of the OEM.

Robot controllers are getting more and more complex, but I haven't found one that can process point clouds or do dynamic motion planning.

A good example of a complex application that benefited from the external control that MotoROS made possible is the A5 system (from this video):

That's a pretty complex application that is using on-the-fly motion planning (no CAD models, so no off-line CAD-to-path) with collision avoidance, in-process Q&A and integrating many different sensors and actuators from many different OEMs.

Can this be done exclusively with MotoROS & ROS? No, of course not. Was the use of ROS (and ROS-Industrial) beneficial? Yes, according to the developers of the system it was.

how can I use motoman_driver to give only POSE of object to robot controller(as we can do in traditional vision system with INFORM programming job) without Moveit motion planning? as motoman robot has its own controller to do all the thing.

I hope it's clearer now that if all you want is to move an EEF to a (parameterised) position and don't care about (or don't have any need for) the things I just described then it may be that MotoROS is not a technology that is suited for your application.

The purpose of ROS-Industrial is to integrate, not to replace. So if the OEM's controller does all you need, there is no need to shoehorn (ie: force) ROS components into that.

But this can also be done without using motoman_driver. for application like this if I use ROS-i, can it seen as here ´not required´? as this can be done also without using it.

using something like ROS (or more generically: a off-controller motion controller) can be beneficial if you wish to use something like sensor based motion planning.

Yes, you can send a Cartesian position to the controller and parameterise an INFORM job with it. it as you describe. And in that case the controller will execute the motion hard-coded in the job, but with some changes based on the position you received from the camera.camera. You don't need MotoROS for such a setup.

If that is all you require, then using MotoROS is probably not going to be more efficient or interesting.

When it does get interesting is when (some examples):

• you want your motion plans to take obstacles into account (the robot controller will not do that, in fact: it will try to move through obstacles)
• when those obstacles are dynamic (ie: they move while the robot is moving)
• when your sensor data is voluminous and heterogenous (there is a lot of sensor data and it's also not all from the same type of sensor)
• when you have a complex motion planning problem that is also changing while the robot is executing it (fi: optimisation of process parameters in an on-line fashion)
• when the robot is only part of a larger system (ie: a 34 dof system in which the 6 (or 7) of the robot are a subset) and planning of motions must take all dofs into account
• when no part of your application can be preprogrammed in an INFORM job (essentially all joint poses are unknown at design time, fi because all future motions will depend on in-situ gathered data)

and there are many more situations in which external control of a robot can be beneficial.

As good as (industrial) robot controllers have become and are at controlling a robot (specifically: the robots of the OEM), robotic applications are typically much more than just a (single) robot. Such applications therefor typically also require more than just the controller of the OEM.

Robot controllers are getting more and more complex, but I haven't found one that can process point clouds or do dynamic motion planning.

A good example of a complex application that benefited from the external control that MotoROS made possible is the A5 system (from this video):

That's a pretty complex application that is using on-the-fly motion planning (no CAD models, so no off-line CAD-to-path) with collision avoidance, in-process Q&A and integrating many different sensors and actuators from many different OEMs.

Can this be done exclusively with MotoROS & ROS? No, of course not. Was the use of ROS (and ROS-Industrial) beneficial? Yes, according to the developers of the system it was.

how can I use motoman_driver to give only POSE of object to robot controller(as we can do in traditional vision system with INFORM programming job) without Moveit motion planning? as motoman robot has its own controller to do all the thing.

I hope it's clearer now that if all you want is to move an EEF to a (parameterised) position and don't care about (or don't have any need for) the things I just described then it may be that MotoROS is not a technology that is suited for your application.

The purpose of ROS-Industrial is to integrate, not to replace. So if the OEM's controller does all you need, there is no need to shoehorn (ie: force) ROS components into that.

But this can also be done without using motoman_driver. for application like this if I use ROS-i, can it seen as here ´not required´? as this can be done also without using it.

using something like ROS (or more generically: a off-controller motion controller) can be beneficial if you wish to use something like sensor based motion planning.

Yes, you can send a Cartesian position to the controller and parameterise an INFORM job with it as you describe. And in that case the controller will execute the motion hard-coded in the job, but with some changes based on the position you received from the camera. You don't need MotoROS for such a setup.

If that is all you require, then using MotoROS is probably not going to be more efficient or interesting.

When it does get interesting is when (some examples):

• you want your motion plans to take obstacles into account (the robot controller will not do that, in fact: it will try to move through obstacles)
• when those obstacles are dynamic (ie: they move while the robot is moving)
• when your sensor data is voluminous and heterogenous (there is a lot of sensor data and it's also not all from the same type of sensor)
• when you have a complex motion planning problem that is also changing while the robot is executing it (fi: optimisation of process parameters in an on-line fashion)
• when the robot is only part of a larger system (ie: a 34 dof system in which the 6 (or 7) of the robot are a subset) and planning of motions must take all dofs into account
• when no part of your application can be preprogrammed in an INFORM job (essentially all joint poses are unknown at design time, fi because all future motions will depend on in-situ gathered data)

and there are many more situations in which external control of a robot can be beneficial.

As good as (industrial) robot controllers have become and are at controlling a robot (specifically: the robots of the OEM), robotic applications are typically much more than just a (single) robot. Such applications therefor typically also require more than just the controller of the OEM.

Robot controllers are getting more and more complex, but I haven't found one that can process point clouds or do dynamic motion planning.

A good example of a complex application that benefited from the external control that MotoROS made possible is the A5 system (from this video):

That's a pretty complex application that is using on-the-fly motion planning (no CAD models, so no off-line CAD-to-path) with collision avoidance, in-process Q&A and integrating many different sensors and actuators from many different OEMs.OEMs. The plane (ie: "workpiece") can be anywhere, the robot can be anywhere, surface conditions can be anything, the environment can be anything, etc, etc.

Can this be done exclusively with MotoROS & ROS? No, of course not. Was the use of ROS (and ROS-Industrial) beneficial? Yes, according to the developers of the system it was.

how can I use motoman_driver to give only POSE of object to robot controller(as we can do in traditional vision system with INFORM programming job) without Moveit motion planning? as motoman robot has its own controller to do all the thing.

I hope it's clearer now that if all you want is to move an EEF to a (parameterised) position and don't care about (or don't have any need for) the things I just described then it may be that MotoROS is not a technology that is suited for your application.

The purpose of ROS-Industrial is to integrate, not to replace. So if the OEM's controller does all you need, there is no need to shoehorn (ie: force) ROS components into that.

I want to develop vision based pick and place. let say I have camera on robot end effector, I am taking image of object and esimating it pose to give it to robotic arm using camera. [..] But this can also be done without using motoman_driver. for application like this if I use ROS-i, can it seen as here ´not required´? as this can be done also without using it.

using something like ROS (or more generically: a off-controller motion controller) can be beneficial if you wish to use something like sensor based motion planning.

Yes, you can send a Cartesian position to the controller and parameterise an INFORM job with it as you describe. And in that case the controller will execute the motion hard-coded in the job, but with some changes based on the position you received from the camera. You don't need MotoROS for such a setup.

If that is all you require, then using MotoROS is probably not going to be more efficient or interesting.

When it does get interesting is when (some examples):

• you want your motion plans to take obstacles into account (the robot controller will not do that, in fact: it will try to move through obstacles)
• when those obstacles are dynamic (ie: they move while the robot is moving)
• when your sensor data is voluminous and heterogenous (there is a lot of sensor data and it's also not all from the same type of sensor)
• when you have a complex motion planning problem that is also changing while the robot is executing it (fi: optimisation of process parameters in an on-line fashion)
• when the robot is only part of a larger system (ie: a 34 dof system in which the 6 (or 7) of the robot are a subset) and planning of motions must take all dofs into account
• when no part of your application can be preprogrammed in an INFORM job (essentially all joint poses are unknown at design time, fi because all future motions will depend on in-situ gathered data)

and there are many more situations in which external control of a robot can be beneficial.

As good as (industrial) robot controllers have become and are at controlling a robot (specifically: the robots of the OEM), robotic applications are typically much more than just a (single) robot. Such applications therefor typically also require more than just the controller of the OEM.

Robot controllers are getting more and more complex, but I haven't found one that can process point clouds or do dynamic motion planning.

A good example of a complex application that benefited from the external control that MotoROS made possible is the A5 system (from this video):

That's a pretty complex application that is using on-the-fly motion planning (no CAD models, so no off-line CAD-to-path) with collision avoidance, in-process Q&A and integrating many different sensors and actuators from many different OEMs. The plane (ie: "workpiece") can be anywhere, the robot can be anywhere, surface conditions can be anything, the environment can be anything, etc, etc.

Can this be done exclusively with MotoROS & ROS? No, of course not. Was the use of ROS (and ROS-Industrial) beneficial? Yes, according to the developers of the system it was.

how can I use motoman_driver to give only POSE of object to robot controller(as we can do in traditional vision system with INFORM programming job) without Moveit motion planning? as motoman robot has its own controller to do all the thing.

I hope it's clearer now that if all you want is to move an EEF to a (parameterised) position and don't care about (or don't have any need for) the things I just described then it may be that MotoROS is not a technology that is suited for your application.

The purpose of ROS-Industrial is to integrate, not to replace. So if the OEM's controller does all you need, there is no need to shoehorn (ie: force) ROS components into that.