0
$\begingroup$

I have an ABB IRB 1200 robotic arm that I'm controlling with MoveIt in ROS Noetic.

Using move_group.set_pose_target(pose), I'm getting weird inefficient motions sometimes. Using move_group.set_joint_value_target(pose,True), I'm not getting weird motions.

However, obstacle avoidance is only supported using set_pose_target(), because it plans in cartesian space.

How can I get the best of both worlds, ie. efficient motions and obstacle avoidance?

I tried:

  • increasing planning attempts: move_group.set_num_planning_attempts(20)
    • didn't work
  • increase tolerance: move_group.set_goal_tolerance(0.01)
    • weird motions occurred less often.

I'm using the Trac solver:

  • kinematics_solver: trac_ik_kinematics_plugin/TRAC_IKKinematicsPlugin
  • kinematics_solver_search_resolution: 0.005
  • kinematics_solver_timeout: 0.005
  • solve_type: Distance

And BiTRRT for path planning:

planner_configs:
 BiTRRT:
    type: geometric::BiTRRT
    range: 0.0 
    temp_change_factor: 0.1  
    init_temperature: 100  
    frountier_threshold: 0.0  
    frountier_node_ratio: 0.1  
    cost_threshold: 1e300  

manipulator:
  default_planner_config: BiTRRT
  planner_configs:
    - BiTRRT
    - etc
  projection_evaluator: joints(joint_1,joint_2)
  longest_valid_segment_fraction: 0.005
Improve this question
$\endgroup$
6
  • $\begingroup$ You should be looking at "path planning", not at "inverse kinematics". Typically your moveit config will choose a path planner from the OMPL library. OMPL has many different planners. $\endgroup$
    – Mike973
    Commented Sep 20, 2023 at 12:50
  • $\begingroup$ I'm using BiTRRT planner from OMPL lib, with config: BiTRRT: type: geometric::BiTRRT range: 0.0 # temp_change_factor: 0.1 init_temperature: 100 frountier_threshold: 0.0 frountier_node_ratio: 0.1 cost_threshold: 1e300 $\endgroup$
    – thomas
    Commented Sep 20, 2023 at 13:02
  • $\begingroup$ I have not used this BitRRT planner, but my guess is that you need to set better config values. You can start by reading the two papers mentioned near the top of the .h file: github.com/ompl/ompl/blob/main/src/ompl/geometric/planners/rrt/… $\endgroup$
    – Mike973
    Commented Sep 21, 2023 at 11:49
  • $\begingroup$ It looks like all OMPL planners result in inefficient joint angels $\endgroup$
    – thomas
    Commented Sep 21, 2023 at 18:28
  • $\begingroup$ Let's make sure we discussing the same problem: A) are you saying that the path that the eef is following is not good, or B) are you saying that the eef path is ok but the motion of the intermediate joints is not nice? How many DOF does the arm have (not including the manipulator)? $\endgroup$
    – Mike973
    Commented Sep 21, 2023 at 20:01

1 Answer 1

Reset to default
0
$\begingroup$

Your comments indicate you are unhappy with both the path planning and the IK solver.

You can get this move_group software to work better, but it will require more effort on your part. Remember that this is generic solver code, so it has no idea what you consider optimal or what might work better for your particular robot arm or for your particular application.

If it were me, I'd focus on the eef path planning first. Many planners try to minimize path length, but you may have to tell it to look for improvements rather than returning the first solution it finds. It is also usually necessary to tune the planner's parameters for your application. As an advanced feature, move_group also has support for Path Constraints and Joint Constraints, which are useful in some situations.

Don't ignore the fact that your code can use pre-defined solutions for some paths or some goal poses. It's way faster and deterministic if your code doesn't need to explore the search space.

Improve this answer
$\endgroup$

Your Answer

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.