0
$\begingroup$

Rosanswers logo

Hello,

I am working on coordinated motions with two 7 dof arms. I'm using diamondback. Currently, I am running only simulations via gazebo. I have been able to expose some basic move_arm functionality to two arms by creating an appropriate planning group and by using one joint_trajectory_action controller for handling control of both arms. I am using a JointPlanner via the RRT planner from ompl:

arms:
  planner_type: JointPlanner
  planner_configs:
    - RRTkConfig2 
  projection_evaluator: joint_state

  RRTkConfig2:
    type: kinematic::RRT  
    range: 0.75

Filter setup:

service_type: FilterJointTrajectoryWithConstraints
filter_chain:
  -
    name: unnormalize_trajectory
    type: UnNormalizeFilterJointTrajectoryWithConstraints
  -
    name: cubic_spline_short_cutter_smoother
    type: CubicSplineShortCutterFilterJointTrajectoryWithConstraints
    params: {discretization: 0.01}

The problems is on some coordinated movements, which bring the two arms close together, the trajectory filter doesn't seem to be constraint aware and it is removing parts of the plan which allow for collision free movement. So, in the end the arms are "colliding" with each other. I say "colliding" because they actual just pass through each other. Using rviz I can see the ompl RRT planner (prior to the filter) plans a collision free trajectory. But, after the trajectory filter snips alot of extra movement out the arms "collide". The "collisions" that happen are usually relatively minimal, i.e. just the tips of the end effectors pass through each other. I have tried different discretization values, but this doesn't help. I can increases the link padding, and this fixes the problem, but too much padding is unacceptable for our applications.

  1. Why is the trajectory filter eliminating parts of the plan that allow for collision free movement?

  2. What changes can I make to the filter or planner to stop this from happening? Are their other filters that are more appropriate for my application?

  3. Why is gazebo allowing "collisions", i.e. letting the arms pass through each other, as opposed to having them stop each other?

Any advice is much appreciated.

Cheers,
Jonathan


Originally posted by Jonathan Realmuto on ROS Answers with karma: 26 on 2011-07-26

Post score: 0


Original comments

Comment by Jonathan Realmuto on 2011-08-05:
Sorry for the delay Sachin. My lab has an upcoming demo, and I been incredibly busy preparing. As soon as this demo is over I will send you everything, so you can look at it (2 weeks max). Thank you.

Comment by Sachin Chitta on 2011-08-02:
Would you be able to post or send us (a) your URDF (b) your planning configuration and launch files and (c) your gazebo launch files and environment? We can try and duplicate this with the tools on our end then.

Comment by Jonathan Realmuto on 2011-08-01:
I can email you a video, if you would like.

Comment by Jonathan Realmuto on 2011-08-01:
The two end effectors are "colliding".

Comment by Jonathan Realmuto on 2011-08-01:
We are using a custom robot. On Friday, my lab visited Rice and disgust the problem with the Kavraki Lab. Ioan Sucan suggested this may be a current limitation of the trajectory filter, since we are planning with multiple tips. From my understanding, much work is been done to expand arm_navigation, and maybe this is something you guys can look further into.

Comment by Sachin Chitta on 2011-08-01:
Which robot are you doing this with? On the PR2, separate links define the tip of the hand. If you are not including all the links in your collision operations properly, you will get this error. When you have collisions, can you check which two links are colliding?

$\endgroup$

1 Answer 1

0
$\begingroup$

Rosanswers logo

no activity in > 1 month, closing


Originally posted by kwc with karma: 12244 on 2011-09-02

This answer was ACCEPTED on the original site

Post score: 0

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.