Pick and Place Documentation/Experiences

[Steffen P]

Hey,

is there any documentation for the pick and place capability available? I already had a look into the code but don't really get the hang of it.

I am interested in what happens exactly in the different Stages (Reachable and Valid Pose Filter,  Approach and Translate Stage and Plan Stage).

I would also be interested in the experiences others had/have with the pick and place functionality because for me it doesn't work very well.

What success rates do you have in your pickup application? What have you done to increase this rate?

Thanks a lot! 

Greetings to the whole MoveIt/ROS community!

Steffen

[Dave Coleman]

Hi Steffen,

I've worked a lot with the pick and place code and am currently trying to make it more robust for Baxter. I can get successful picks and places around 75% of the time, but, at least with my hardware, I need to add additional features like visual servoing and better controllers to account for inaccuracies in the actuators. You can see my demo pick place implementation, using MoveIt's move_group_interface, here.

I also just put a pull request to add more comments to the pick and place pipeline, if that helps.

It would be really nice to have the three stages documented better, I'm still not clear why they are named the way they are.

The most important thing I had to change was allowing Baxter to have more time to complete trajectories since its controls are not the best. I added two new optional parameters to MoveIt recently that allow you to do just this. First, you should set your max velocity low in joint_limits.yaml. Then, in trajectory_execution.launch, you can add these lines:

  <!-- When determining the expected duration of a trajectory, this multiplicative factor is applied to get the allowed duration of execution -->

  <param name="allowed_execution_duration_scaling" value="1.5"/> <!-- default 1.2 -->

  <!-- Allow more than the expected execution time before triggering a trajectory cancel (applied after scaling) -->

  <param name="allowed_goal_duration_margin" value="1.5"/> <!-- default 0.5 -->

With this, pick&place is working as intended for me at the moment.

:: dave | 251.463.2345 c

[Steffen P]

Hi Dave,

thanks a lot for the fast and interesting answer. I will look at your pull request and your pick/place code tomorrow.

One more question: Is your success rate successful picks/places in the real world? Or in Simulation?

I currently generate grasps with the old pr2_gripper_planner_cluster which creates nearly always over 100 grasps. I have even tried to generate more grasps out of them by rotating and shifting them for a certain amount. I sometimes had over 1000 grasps but still no plan for a pickup is found.

My actual pickup success rate in simulation is lower than 10%. 

Steffen

[Steffen P]

Is Dave the only one here with moveit pick and place experiences?

[Marcus Liebhardt]

Hi Steffen!

I was using the pick & place actions for a short time a while back. Because I had very a very low success rate, I switched to my own implementation of the pick & place actions using SMACH. The failing part was usually approach & translate, where the interpolated IK functionality is used. I'm using the MoveIt on a real robot and supplying manually created grasps.

I'm not sure, if the main reason of the low success rate is due to the few DOF (4) of my robot (arm) or the multiple issues I'm having with the environment representation (Octomap collision map). Since I found a work around to the latter - dropping the environment monitoring and adding the recognised object and table manually - I should give the default pick& place actions another try. Unfortunately, I don't have time for that at the moment.

Please keep us updated on your progress!

Good luck,

Marcus

--

Innovation Team Leader
Yujin Robot
주소: 대한민국 서울시 금천구 가산동 345-30 남성프라자 #601, 153-023.
Address: Door #601, Namsung-Plaza, 345-30 Gasan-dong, Guemcheon-gu, Seoul, 153-023, Republic of Korea
Website: http://inno.yujinrobot.com
Email: marcus.l...@yujinrobot.com
Phone: +82-70-46577073

[Adolfo Rodríguez Tsouroukdissian]

The most important thing I had to change was allowing Baxter to have more time to complete trajectories since its controls are not the best. I added two new optional parameters to MoveIt recently that allow you to do just this. First, you should set your max velocity low in joint_limits.yaml. Then, in trajectory_execution.launch, you can add these lines:

  <!-- When determining the expected duration of a trajectory, this multiplicative factor is applied to get the allowed duration of execution -->

  <param name="allowed_execution_duration_scaling" value="1.5"/> <!-- default 1.2 -->

  <!-- Allow more than the expected execution time before triggering a trajectory cancel (applied after scaling) -->

  <param name="allowed_goal_duration_margin" value="1.5"/> <!-- default 0.5 -->

Why did you have to add goal tolerances at the MoveIt! level?. The FollowJointTrajectoryAction API [1,2] already allows to specify both path and goal tolerances (and in a more expressive way), and implementations should be expected to enforce them. Does MoveIt! need such information internally for something?. IMO, it would be best if we could separate concerns here and make MoveIt! agnostic to trajectory execution details such as tolerances. It can also be confusing to have two separate places to specify similar behaviors.

[1] Tolerance specification: See constraints/ namespace in http://wiki.ros.org/joint_trajectory_controller#Parameters

[2] Result notification: See action goal error codes in http://docs.ros.org/api/control_msgs/html/action/FollowJointTrajectory.html

Best,

Adolfo.

--
Adolfo Rodríguez Tsouroukdissian
Senior robotics engineer
adolfo.r...@pal-robotics.com
http://www.pal-robotics.com

PAL ROBOTICS S.L
c/ Pujades 77-79, 4º4ª
08005 Barcelona, Spain.
Tel. +34.93.414.53.47
Fax.+34.93.209.11.09
Skype: adolfo.pal-robotics
Facebook - Twitter - PAL Robotics YouTube Channel

AVISO DE CONFIDENCIALIDAD: Este mensaje y sus documentos adjuntos, pueden contener información privilegiada y/o confidencial que está dirigida exclusivamente a su destinatario. Si usted recibe este mensaje y no es el destinatario indicado, o el empleado encargado de su entrega a dicha persona, por favor, notifíquelo inmediatamente y remita el mensaje original a la dirección de correo electrónico indicada. Cualquier copia, uso o distribución no autorizados de esta comunicación queda estrictamente prohibida.

CONFIDENTIALITY NOTICE: This e-mail and the accompanying document(s) may contain confidential information which is privileged and intended only for the individual or entity to whom they are addressed.  If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of this e-mail and/or accompanying document(s) is strictly prohibited.  If you have received this e-mail in error, please immediately notify the sender at the above e-mail address.

[Marcus Liebhardt]

On Mon, Nov 4, 2013 at 7:57 PM, Adolfo Rodríguez Tsouroukdissian <adolfo.r...@pal-robotics.com> wrote:

The most important thing I had to change was allowing Baxter to have more time to complete trajectories since its controls are not the best. I added two new optional parameters to MoveIt recently that allow you to do just this. First, you should set your max velocity low in joint_limits.yaml. Then, in trajectory_execution.launch, you can add these lines:

  <!-- When determining the expected duration of a trajectory, this multiplicative factor is applied to get the allowed duration of execution -->

  <param name="allowed_execution_duration_scaling" value="1.5"/> <!-- default 1.2 -->

  <!-- Allow more than the expected execution time before triggering a trajectory cancel (applied after scaling) -->

  <param name="allowed_goal_duration_margin" value="1.5"/> <!-- default 0.5 -->

Why did you have to add goal tolerances at the MoveIt! level?.

I had to use this functionality for my robot as well (thanks Dave for implementing this!). The execution of the trajectories usually took more time than MoveIt estimated. I guess, this is due to how our interpolator and (feed-forward) ROS controller works.

The FollowJointTrajectoryAction API [1,2] already allows to specify both path and goal tolerances (and in a more expressive way), and implementations should be expected to enforce them. Does MoveIt! need such information internally for something?. IMO, it would be best if we could separate concerns here and make MoveIt! agnostic to trajectory execution details such as tolerances. It can also be confusing to have two separate places to specify similar behaviors. 

In theory I agree. But wouldn't this require MoveIt to use the same interpolator as the controller implemented on the robot? In our case, the interpolator does its best to achieve the velocities given by the FollowJointTrajectoryAction, but will adjust them based on the (internally) configured joint accelerations, if needed.

Additionally, a motor control system would be required, which allows to track the calculated trajectory precisely - what is not given in our case, apparently with Baxter and many simple robots (e.g. TurtleBot plus Dynamixel-based arm).

Cheers,
Marcus

[Adolfo Rodríguez Tsouroukdissian]

On Mon, Nov 4, 2013 at 12:14 PM, Marcus Liebhardt <marcus.l...@yujinrobot.com> wrote:

On Mon, Nov 4, 2013 at 7:57 PM, Adolfo Rodríguez Tsouroukdissian <adolfo.r...@pal-robotics.com> wrote:

The most important thing I had to change was allowing Baxter to have more time to complete trajectories since its controls are not the best. I added two new optional parameters to MoveIt recently that allow you to do just this. First, you should set your max velocity low in joint_limits.yaml. Then, in trajectory_execution.launch, you can add these lines:

  <!-- When determining the expected duration of a trajectory, this multiplicative factor is applied to get the allowed duration of execution -->

  <param name="allowed_execution_duration_scaling" value="1.5"/> <!-- default 1.2 -->

  <!-- Allow more than the expected execution time before triggering a trajectory cancel (applied after scaling) -->

  <param name="allowed_goal_duration_margin" value="1.5"/> <!-- default 0.5 -->

Why did you have to add goal tolerances at the MoveIt! level?.

Maybe I can re-state the question otherwise. Some context first: A compliant implementation of the FollowJointTrajectory API has some default tolerances loaded from the param server, which can be overridden with tolerances specified in the action goal request. These overrides are not global, but only affect the action goal specifying them.

Question re-stated: Are the goal constraints specified in MoveIt! passed along to the FollowJointTrajectory goal request so they can be enforced in the controller?, or are they enforced independently inside MoveIt?. It would seem that the latter is the case. Is this to compensate for simpler, incomplete implementations of the FollowJointTrajectory API not supporting constraint validation?.

[Dave Coleman]

From my memory, MoveIt! does not monitor the trajectory as it is being executed, but only listens to the actionlib result to see if it was successful or not. However, MoveIt! does timeout if the actionlib result does not return successful within the time that MoveIt! excepts the trajectory to be executed. This has caused me a lot of pain getting the synchronization correct because the entire pick-and-place pipeline, I believe, runs on a non-re configurable timeline of pregrasp at time t1, grasp at time t2, etc... I've exposed recently some params that allow you to tweak how long MoveIt! will wait before timing out (see first email in this chain) but still its difficult. And yes, I'm using your implementation Adolfo of the FollowJointTrajectory controller. 

> Question re-stated: Are the goal constraints specified in MoveIt! passed along to the FollowJointTrajectory goal request so they can be enforced in the controller?,

Like I said, I believe only the total trajectory time is enforced, not position constraints, etc.

:: dave | 251.463.2345 c

[Adolfo Rodríguez Tsouroukdissian]

On Thu, Nov 7, 2013 at 8:17 PM, Dave Coleman <davetc...@gmail.com> wrote:

From my memory, MoveIt! does not monitor the trajectory as it is being executed, but only listens to the actionlib result to see if it was successful or not. However, MoveIt! does timeout if the actionlib result does not return successful within the time that MoveIt! excepts the trajectory to be executed. This has caused me a lot of pain getting the synchronization correct because the entire pick-and-place pipeline, I believe, runs on a non-re configurable timeline of pregrasp at time t1, grasp at time t2, etc... I've exposed recently some params that allow you to tweak how long MoveIt! will wait before timing out (see first email in this chain) but still its difficult. And yes, I'm using your implementation Adolfo of the FollowJointTrajectory controller. 

OK, that explanation makes sense. I just wanted to make clear that the FollowJointTrajectory action takes goal time tolerances into account. For completeness, I restate the pros/cons of leaving timeout checking to the FollowJointTrajectory server.

Pros:

- Code which enforces the timeout could be removed from MoveIt! (I imagine it's not much though). Goal time tolerances can be passed into the goal request and that's it.

Cons:

- If the FollowJointTrajectory server implementation is incomplete and does not enforce tolerances, then nobody is enforcing timeouts. The implementation in ros_control does enforce these constraints, but I know there are other implementations out there, and I don't know how complete they are.

> Question re-stated: Are the goal constraints specified in MoveIt! passed along to the FollowJointTrajectory goal request so they can be enforced in the controller?,

Like I said, I believe only the total trajectory time is enforced, not position constraints, etc.

Copy that.

Adolfo.