Revision history [back]

This is certainly possible, but as you found out, group.move() is probably not the best way to do this: group.move() assumes that you want to move your EEF, while avoiding collisions, through an unstructured / semi-structured scene to a single destination. That requires motion planning, which is a (relatively) complex process. On top of that, each .move() is considered a separate request, with smoothness only 'guaranteed' between start and goal of the motion, not between subsequent requests. The fact that you submit a lot of goals, one after the other, does not make MoveIt 'realise' that you want something it isn't doing: you're sending it separate requests, so MoveIt generates a lot of (very short) trajectories for you, just as you ask.

This is where your 'stuttering' is coming from.

The "simple" simulation software that you are referring to is probably either a CAD-to-path (c2p) or a kinematic playout tool (RoboDK by any chance?), not a simulation per se. These essentially generate either a single motion through all waypoints, or use something called blending to make subsequent motions smoothly follow each other. This blending is typically done by the controller, not the software generating the robot program.

As useful as those c2p tools are, it's slightly unfair to compare what they are doing to what MoveIt is doing: the latter is a complete planning pipeline, able to deal with (almost) arbitrarily complex kinematic setups and environments, with a focus on getting your EEF to your goal pose without colliding with anything. The former typically 'only' do pose interpolation based on waypoints generated from workpiece geometry without any regard for your robot, your tool or your environment (this is changing though).

Getting a single, continuous path out of MoveIt is possible however: you could take a look at the Cartesian Path capabilities which essentially allow you to provide a list of waypoints and plan (really: iterate) through all of them at once. See Move Group Interface Tutorial - Cartesian Paths for an impression on how to do this.

Another option would be to look at a planner such as Descartes: that is a slightly different approach, but well suited for these type of tasks. There is currently some interest over at the ROS-Industrial mailing list to extend the tutorials of Descartes with some more info on how it could be used for something like welding. See Descartes path planning extra tutorial.

Note btw that to successfully weld something you would most likely also need synchronised (de)activation of your EEF / other peripherals. Neither MoveIt nor Descartes will do this for you.

This is certainly possible, but as you found out, group.move() is probably not the best way to do this: group.move() assumes that you want to move your EEF, while avoiding collisions, through an unstructured / semi-structured scene to a single destination. That requires motion planning, which is a (relatively) complex process. On top of that, each .move() is considered a separate request, with smoothness only 'guaranteed' between start and goal of the motion, not between subsequent requests. The fact that you submit a lot of goals, one after the other, does not make MoveIt 'realise' that you want something it isn't doing: you're sending it separate requests, so MoveIt generates a lot of (very short) trajectories for you, just as you ask.

This is where your 'stuttering' is coming from.

The "simple" simulation software that you are referring to is probably either a CAD-to-path (c2p) or a kinematic playout tool (RoboDK by any chance?), not a simulation per se. These essentially generate either a single motion through all waypoints, or use something called blending to make subsequent motions smoothly follow each other. This blending is typically done by the controller, not the software generating the robot program.

As useful as those c2p tools are, it's slightly unfair to compare what they are doing to what MoveIt is doing: the latter is a complete planning pipeline, able to deal with (almost) arbitrarily complex kinematic setups and environments, with a focus on getting your EEF to your goal pose without colliding with anything. The former typically 'only' do pose interpolation based on waypoints generated from workpiece geometry without any regard for your robot, your tool or your environment (this is changing though).

Getting a single, continuous path out of MoveIt is possible however: you could take a look at the Cartesian Path capabilities which essentially allow you to provide a list of waypoints and plan (really: iterate) through all of them at once. See Move Group Interface Tutorial - Cartesian Paths for an impression on how to do this.

Another option would be to look at a planner such as Descartes: that is a slightly different approach, but well suited for these type of tasks. There is currently some interest over at the ROS-Industrial mailing list to extend the tutorials of Descartes with some more info on how it could be used for something like welding. See Descartes path planning extra tutorial.

Note btw that to successfully weld something you would most likely also need synchronised (de)activation of your EEF / other peripherals. Neither MoveIt nor Descartes will do this for you.

This is certainly possible, but as you found out, group.move() is probably not the best way to do this: group.move() assumes that you want to move your EEF, while avoiding collisions, through an unstructured / semi-structured scene to a single destination. That requires motion planning, which is a (relatively) complex process. On top of that, each .move() is considered a separate request, with smoothness only 'guaranteed' between start and goal of the motion, not between subsequent requests. The fact that you submit a lot of goals, one after the other, does not make MoveIt 'realise' that you want something it isn't doing: you're sending it separate requests, so MoveIt generates a lot of (very short) trajectories for you, just as you ask.

This is where your 'stuttering' is coming from.

The "simple" simulation software that you are referring to is probably either a CAD-to-path (c2p) or a kinematic playout tool (RoboDK by any chance?), not a simulation per se. These essentially generate either a single motion through all waypoints, or use something called blending to make subsequent motions smoothly follow each other. This blending is typically done by the controller, not the software generating the robot program.

As useful as those c2p tools are, it's slightly unfair to compare what they are doing to what MoveIt is doing: the latter is a complete planning pipeline, able to deal with (almost) arbitrarily complex kinematic setups and environments, with a focus on getting your EEF to your goal pose without colliding with anything. The former typically 'only' do pose interpolation based on waypoints generated from workpiece geometry without any regard for your robot, your tool or your environment (this is changing though).

Getting a single, continuous path out of MoveIt is possible however: you could take a look at the Cartesian Path capabilities which essentially allow you to provide a list of waypoints and plan (really: iterate) through all of them at once. See Move Group Interface Tutorial - Cartesian Paths for an impression on how to do this.

Another option would be to look at a planner such as Descartes: that is a slightly different approach, but well suited for these type of tasks. There is currently some interest over at the ROS-Industrial mailing list to extend the tutorials of Descartes with some more info on how it could be used for something like welding. See Descartes path planning extra tutorial.

Note btw that to successfully weld something you would most likely also need synchronised (de)activation of your EEF / other peripherals. Neither MoveIt nor Descartes will do this for you. Good welding is actually not trivial and includes much more than just planning a smooth motion through a nr of waypoints.