ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

Revision history [back]

Just to clarify are you trying to build a visual servoing system?

You mentioned that you want to joint several trajectories together into a single smooth movement. The main challenge with this is that as standard MoveiIt will project trajectories who's start and end velocities are zero, this mean that if you join them together the motion will 'stutter' as the arm stops and starts between trajectories.

This is a complex problem and there are a few different solutions out there. One is known as velocity control, here instead of planning paths a control law is defined which sets the 6 DOF velocity of the end effector based upon the location of the target. When an appropriate control law is set this will result in very smooth following of a moving target, however singularity avoidance is not as easy as it when using pre-planned trajectories.

Another option would be to plan each new trajectory from the current robot state including its position and velocity. This way each new plan knows the robot is in motion and will plan a trajectory which smoothly joins onto this motion. I personally don't know how to do this with MoveiIt, although I've love to find out if it's possible.

Regarding your specific question here, it appears to be a launch file problem. The MoveGroup by default tries to load a robot model (URDF) from a parameter called robot_description this parameter doesn't appear to be set. You'll also need other nodes (real or simulation) that can provide JointState messages and provide a trajectory action server.

Hope this helps.

Just to clarify are you trying to build a visual servoing system?

You mentioned that you want to joint several trajectories together into a single smooth movement. The main challenge with this is that as standard MoveiIt will project trajectories who's start and end velocities are zero, this mean that if you join them together the motion will 'stutter' as the arm stops and starts between trajectories.

This is a complex problem and there are a few different solutions out there. One is known as velocity control, here instead of planning paths a control law is defined which sets the 6 DOF velocity of the end effector based upon the location of the target. When an appropriate control law is set this will result in very smooth following of a moving target, however singularity avoidance is not as easy as it when using pre-planned trajectories.

Another option would be to plan each new trajectory from the current robot state including its position and velocity. This way each new plan knows the robot is in motion and will plan a trajectory which smoothly joins onto this motion. I personally don't know how to do this with MoveiIt, although I've love to find out if it's possible.

Regarding your specific question here, it appears to be a launch file problem. The MoveGroup by default tries to load a robot model (URDF) from a parameter called robot_description this parameter doesn't appear to be set. You'll also need other nodes (real or simulation) that can provide JointState messages and provide a trajectory action server.

Hope this helps.

Update:

You can use the jog_arm package to velocity control a robot setup with MoveIt, this package allows you to set the 6DOF velocity of the end effector as well as gracefully handling singularities for you (saves you a lot of headaches!)

You second question is a good one. It all comes down to the design of your control law, this function will take in target positions and produce desired EE velocities. Ideally as the EE gets close the target the velocities will reduce so it gradually slows down and comes to rest at the target. It's easy to overshoot if your controller is under-damped or not quite reach the target if it's over-damped. But you'll need to experiment with the real robot hardware to tune this correctly. You'll want this control loop running at least 10 times per second in my experience.

Just to clarify are you trying to build a visual servoing system?

You mentioned that you want to joint several trajectories together into a single smooth movement. The main challenge with this is that as standard MoveiIt will project trajectories who's start and end velocities are zero, this mean that if you join them together the motion will 'stutter' as the arm stops and starts between trajectories.

This is a complex problem and there are a few different solutions out there. One is known as velocity control, here instead of planning paths a control law is defined which sets the 6 DOF velocity of the end effector based upon the location of the target. When an appropriate control law is set this will result in very smooth following of a moving target, however singularity avoidance is not as easy as it when using pre-planned trajectories.

Another option would be to plan each new trajectory from the current robot state including its position and velocity. This way each new plan knows the robot is in motion and will plan a trajectory which smoothly joins onto this motion. I personally don't know how to do this with MoveiIt, although I've love to find out if it's possible.

Regarding your specific question here, it appears to be a launch file problem. The MoveGroup by default tries to load a robot model (URDF) from a parameter called robot_description this parameter doesn't appear to be set. You'll also need other nodes (real or simulation) that can provide JointState messages and provide a trajectory action server.

Hope this helps.

Update:

You can use the jog_arm package to velocity control a robot setup with MoveIt, robot, this package allows you to set the 6DOF velocity of the end effector as well as gracefully handling singularities for you (saves you a lot of headaches!)

You second question is a good one. It all comes down to the design of your control law, this function will take in target positions and produce desired EE velocities. Ideally as the EE gets close the target the velocities will reduce so it gradually slows down and comes to rest at the target. It's easy to overshoot if your controller is under-damped or not quite reach the target if it's over-damped. But you'll need to experiment with the real robot hardware to tune this correctly. You'll want this control loop running at least 10 times per second in my experience.