Revision history [back]

(disclaimer: I'll use a few very definite looking "yes" and "no" answers here. These are all based on the rather minimal description of your system. Please keep that in mind when reading this answer)

Can Moveit plan a path for a robot arm on a gantry

Yes.

There is no difference between a gantry, a robot or a gantry + robot as far as MoveIt is concerned. It's just a collection of links and joints that happen to have a kinematic relationship. MoveIt (ultimately) plans in joint space, so any set of joints can be planned for.

or is that too many links?

No. There is no assumption on or limit to the nr of links and joints a model can contain (other than practical ones (ie: memory, CPU (planning time) and things like IK solver availability (if you want to plan for Cartesian goals)).

Should I modify the URDF for the robot to include the gantry,

No. Never add something to an existing model. Use composition where possible.

or is there a way/reason to make them two separate things.

I wouldn't make them "two separate things". As I wrote above: use composition:

• create the model of your gantry as a xacro macro. Make sure to take things such as prefixes into account.
• define a sane 'attachment' or 'tool' point for your gantry (likely the last link in its kinematic chain)
• create a composite xacro macro that combines the models of your gantry and the UR10
• create a workspace (or whatever you want to call it) xacro macro that places the composite structure (ie: gantry + robot) in its working environment (ie: model the workcell)

Making the composites macros themselves is not strictly needed, but is a nice convenience when you want to reuse those as composable parts. I always do it. If there is nothing to compose further, you create a top-level xacro file that just includes the highest-level composite and then instantiates it.

Will a system this complex be able to avoid self colliding in moveit?

Yes. This is not complex at all.

The composite robot that is. You haven't described your environment, which could add significant complexity.

Also I don't know how to incorporate the gantry servos even once I build a model in moveit.

My suggestion would be to somehow wrap the "clearpath servos" in a FollowJointTrajectory action server. MoveIt can interface with that directly (using a SimpleControllerManager) making the whole system almost trivial to integrate (if you're using ur_modern_driver for the UR10, that also has a FollowJointTrajectory action server). Use ros_control for the servo interface, then configure it with a joint_trajectory_controller.

One thing to keep in mind is that with two action servers, motions will not be synchronised between the gantry and the UR10.

If that would be desired/required, you would have to probably convert ur_modern_driver (assuming you're using that) into something compatible with the combined_robot_hw variant of hardware_interfaces. That would allow you to expose all joints of the gantry+robot as a single set to the joint_trajectory_controller. ur_modern_driver was not written with this in mind, so that may not be straightforward.

An asynchronous setup should be relatively easy to achieve, so that may be something to try first.

Final comment: you don't describe what you will be using this setup for, but "gantry" implies large and dangerous. Be sure to take proper safety measures and don't rely on MoveIt's collision avoidance only.

(disclaimer: I'll use a few very definite looking "yes" and "no" answers here. These are all based on the rather minimal description of your system. Please keep that in mind when reading this answer)

Can Moveit plan a path for a robot arm on a gantry

Yes.

There is no difference between a gantry, a robot or a gantry + robot as far as MoveIt is concerned. It's just a collection of links and joints that happen to have a kinematic relationship. MoveIt (ultimately) plans in joint space, so any set of joints can be planned for.

or is that too many links?

No. There is no assumption on or limit to the nr of links and joints a model can contain (other than practical ones (ie: memory, CPU (planning time) and things like IK solver availability (if you want to plan for Cartesian goals)).

Should I modify the URDF for the robot to include the gantry,

No. Never add something to an existing model. Use composition where possible.

or is there a way/reason to make them two separate things.

I wouldn't make them "two separate things". As I wrote above: use composition:

• create the model of your gantry as a xacro macro. Make sure to take things such as prefixes into account.
• define a sane 'attachment' or 'tool' point for your gantry (likely the last link in its kinematic chain)
• create a composite xacro macro that combines the models of your gantry and the UR10
• create a workspace (or whatever you want to call it) xacro macro that places the composite structure (ie: gantry + robot) in its working environment (ie: model the workcell)

Making the composites macros themselves is not strictly needed, but is a nice convenience when you want to reuse those as composable parts. I always do it. If there is nothing to compose further, you create a top-level xacro file that just includes the highest-level composite and then instantiates it.

Will a system this complex be able to avoid self colliding in moveit?

Yes. Yes.

This is not complex at all.

The composite robot that is. You haven't described your environment, which could add significant complexity.

Also I don't know how to incorporate the gantry servos even once I build a model in moveit.

My suggestion would be to somehow wrap the "clearpath servos" in a FollowJointTrajectory action server. MoveIt can interface with that directly (using a SimpleControllerManager) making the whole system almost trivial to integrate (if you're using ur_modern_driver for the UR10, that also has a FollowJointTrajectory action server). Use ros_control for the servo interface, then configure it with a joint_trajectory_controller.

One thing to keep in mind is that with two action servers, motions will not be synchronised between the gantry and the UR10.

If that would be desired/required, you would have to probably convert ur_modern_driver (assuming you're using that) into something compatible with the combined_robot_hw variant of hardware_interfaces. That would allow you to expose all joints of the gantry+robot as a single set to the joint_trajectory_controller. ur_modern_driver was not written with this in mind, so that may not be straightforward.

An asynchronous setup should be relatively easy to achieve, so that may be something to try first.

Final comment: you don't describe what you will be using this setup for, but "gantry" implies large and dangerous. Be sure to take proper safety measures and don't rely on MoveIt's collision avoidance only.

(disclaimer: I'll use a few very definite looking "yes" and "no" answers here. These are all based on the rather minimal description of your system. Please keep that in mind when reading this answer)

Can Moveit plan a path for a robot arm on a gantry

Yes.

There is no difference between a gantry, a robot or a gantry + robot as far as MoveIt is concerned. It's just a collection of links and joints that happen to have a kinematic relationship. MoveIt (ultimately) plans in joint space, so any set of joints can be planned for.

or is that too many links?

No. There is no assumption on or limit to the nr of links and joints a model can contain (other than practical ones (ie: memory, CPU (planning time) and things like IK solver availability (if you want to plan for Cartesian goals)).

Should I modify the URDF for the robot to include the gantry,

No. Never add something to an existing model. Use composition where possible.

or is there a way/reason to make them two separate things.

I wouldn't make them "two separate things". As I wrote above: use composition:

• create the model of your gantry as a xacro macro. Make sure to take things such as prefixes into account.
• define a sane 'attachment' or 'tool' point for your gantry (likely the last link in its kinematic chain)
• create a composite xacro macro that combines the models of your gantry and the UR10
• create a workspace (or whatever you want to call it) xacro macro that places the composite structure (ie: gantry + robot) in its working environment (ie: model the workcell)

Making the composites macros themselves is not strictly needed, but is a nice convenience when you want to reuse those as composable parts. I always do it. If there is nothing to compose further, you create a top-level xacro file that just includes the highest-level composite and then instantiates it.

Will a system this complex be able to avoid self colliding in moveit?

Yes.

This is not complex at all.

The composite robot that is. You haven't described your environment, which could add significant complexity.

Also I don't know how to incorporate the gantry servos even once I build a model in moveit.

My suggestion would be to somehow wrap the "clearpath servos" in a FollowJointTrajectory action server. MoveIt can interface with that directly (using a SimpleControllerManager) making the whole system almost trivial to integrate (if you're using ur_modern_driver for the UR10, that also has a FollowJointTrajectory action server). Use ros_control for the servo interface, then configure it with a joint_trajectory_controller.

One thing to keep in mind is that with two action servers, motions will not be synchronised between the gantry and the UR10.

If that would be desired/required, you would have to probably convert ur_modern_driver (assuming you're using that) into something compatible with the combined_robot_hw variant of hardware_interfaces. That would allow you to expose all joints of the gantry+robot as a single set to the joint_trajectory_controller. ur_modern_driver was not written with this in mind, so that may not be straightforward.

An asynchronous setup should be relatively easy to achieve, so that may be something to try first.

Final comment: you don't describe what you will be using this setup for, but "gantry" implies large and dangerous. Be sure to take proper safety measures and don't rely on MoveIt's collision avoidance only.

(disclaimer: I'll use a few very definite looking "yes" and "no" answers here. These are all based on the rather minimal description of your system. Please keep that in mind when reading this answer)

Can Moveit plan a path for a robot arm on a gantry

Yes.

There is no difference between a gantry, a robot or a gantry + robot as far as MoveIt is concerned. It's just a collection of links and joints that happen to have a kinematic relationship. MoveIt (ultimately) plans in joint space, so any set of joints can be planned for.

or is that too many links?

No. There is no assumption on or limit to the nr of links and joints a model can contain (other than practical ones (ie: memory, CPU (planning time) and things like IK solver availability (if you want to plan for Cartesian goals)).

Should I modify the URDF for the robot to include the gantry,

No. Never add something to an existing model. Use composition where possible.

or is there a way/reason to make them two separate things.

I wouldn't make them "two separate things". As I wrote above: use composition:

• create the model of your gantry as a xacro macro. Make sure to take things such as prefixes into account.
• define a sane 'attachment' or 'tool' point for your gantry (likely the last link in its kinematic chain)
• create a composite xacro macro that combines the models of your gantry and the UR10
• create a workspace workcell (or whatever you want to call it) xacro macro that places the composite structure (ie: gantry + robot) in its working environment (ie: model the workcell)

Making the composites macros themselves is not strictly needed, but is a nice convenience when you want to reuse those as composable parts. I always do it. If there is nothing to compose further, you create a top-level xacro file that just includes the highest-level composite and then instantiates it.

Minimal example of this approach: Working with ROS-Industrial Robot Support Packages/Example: adding an end-effector to a robot.

Will a system this complex be able to avoid self colliding in moveit?

Yes.

This is not complex at all.

The composite robot that is. You haven't described your environment, which could add significant complexity.

Also I don't know how to incorporate the gantry servos even once I build a model in moveit.

My suggestion would be to somehow wrap the "clearpath servos" in a FollowJointTrajectory action server. MoveIt can interface with that directly (using a SimpleControllerManager) making the whole system almost trivial to integrate (if you're using ur_modern_driver for the UR10, that also has a FollowJointTrajectory action server). Use ros_control for the servo interface, then configure it with a joint_trajectory_controller.

One thing to keep in mind is that with two action servers, motions will not be synchronised between the gantry and the UR10.

If that would be desired/required, you would have to probably convert ur_modern_driver (assuming you're using that) into something compatible with the combined_robot_hw variant of hardware_interfaces. That would allow you to expose all joints of the gantry+robot as a single set to the joint_trajectory_controller. ur_modern_driver was not written with this in mind, so that may not be straightforward.

An asynchronous setup should be relatively easy to achieve, so that may be something to try first.

Final comment: you don't describe what you will be using this setup for, but "gantry" implies large and dangerous. Be sure to take proper safety measures and don't rely on MoveIt's collision avoidance only.

(disclaimer: I'll use a few very definite looking "yes" and "no" answers here. These are all based on the rather minimal description of your system. Please keep that in mind when reading this answer)

Can Moveit plan a path for a robot arm on a gantry

Yes.

There is no difference between a gantry, a robot or a gantry + robot as far as MoveIt is concerned. It's just a collection of links and joints that happen to have a kinematic relationship. MoveIt (ultimately) plans in joint space, so any set of joints can be planned for.

or is that too many links?

No. There is no assumption on or limit to the nr of links and joints a model can contain (other than practical ones (ie: memory, CPU (planning time) and things like IK solver availability (if you want to plan for Cartesian goals)).

Should I modify the URDF for the robot to include the gantry,

No. Never add something to an existing model. Use composition where possible.

or is there a way/reason to make them two separate things.

I wouldn't make them "two separate things". As I wrote above: use composition:

• create the model of your gantry as a xacro macro. Make sure to take things such as prefixes into account.
• define a sane 'attachment' or 'tool' point for your gantry (likely the last link in its kinematic chain)
• create a composite xacro macro that combines the models of your gantry and the UR10
• create a workcell (or whatever you want to call it) xacro macro that places the composite structure (ie: gantry + robot) in its working environment (ie: model the workcell)

Making the composites macros themselves is not strictly needed, but is a nice convenience when you want to reuse those as composable parts. I always do it. If there is nothing to compose further, you create a top-level xacro file that just includes the highest-level composite and then instantiates it.

Minimal example of this approach: Working with ROS-Industrial Robot Support Packages/Example: adding an end-effector to a robot.

Will a system this complex be able to avoid self colliding in moveit?

Yes.

This is not complex at all.

The composite robot that is. You haven't described your environment, which could add significant complexity.

Also I don't know how to incorporate the gantry servos even once I build a model in moveit.

My suggestion would be to somehow wrap the "clearpath servos" in a FollowJointTrajectory action server. MoveIt can interface with that directly (using a SimpleControllerManagerMoveItSimpleControllerManager) making the whole system almost trivial to integrate (if you're using ur_modern_driver for the UR10, that also has a FollowJointTrajectory action server). Use ros_control for the servo interface, then configure it with a joint_trajectory_controller.

One thing to keep in mind is that with two action servers, motions will not be synchronised between the gantry and the UR10.

If that would be desired/required, you would have to probably convert ur_modern_driver (assuming you're using that) into something compatible with the combined_robot_hw variant of hardware_interfaces. That would allow you to expose all joints of the gantry+robot as a single set to the joint_trajectory_controller. ur_modern_driver was not written with this in mind, so that may not be straightforward.

An asynchronous setup should be relatively easy to achieve, so that may be something to try first.

Final comment: you don't describe what you will be using this setup for, but "gantry" implies large and dangerous. Be sure to take proper safety measures and don't rely on MoveIt's collision avoidance only.