Timeline for Moveit set_pose_target() weird motions
Current License: CC BY-SA 4.0
18 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Oct 17 at 14:01 | history | bumped | CommunityBot | This question has answers that may be good or bad; the system has marked it active so that they can be reviewed. | |
| Jun 19 at 14:01 | history | bumped | CommunityBot | This question has answers that may be good or bad; the system has marked it active so that they can be reviewed. | |
| Feb 20 at 14:00 | history | bumped | CommunityBot | This question has answers that may be good or bad; the system has marked it active so that they can be reviewed. | |
| Oct 23, 2023 at 13:05 | history | bumped | CommunityBot | This question has answers that may be good or bad; the system has marked it active so that they can be reviewed. | |
| Sep 23, 2023 at 12:09 | answer | added | Mike973 | timeline score: 0 | |
| Sep 22, 2023 at 7:03 | comment | added | thomas | 6 DOF. Both A and B are non optimal in the case of the weird motions. When I check the final joint angles (angles plan[1].joint_trajectory.points[-1].positions) of the plan=move_group.plan() in these cases, the joint angles are a valid IK solution, but far from the most optimal one. When I calculate an IK solution using roboticstooblox in these cases, and use MotionPlanning in Rviz ( with collision aware IK) and the joint angels set to the IK solution it works fine and as intended. | |
| Sep 21, 2023 at 20:01 | comment | added | Mike973 | 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)? | |
| Sep 21, 2023 at 18:28 | comment | added | thomas | It looks like all OMPL planners result in inefficient joint angels | |
| Sep 21, 2023 at 11:49 | comment | added | Mike973 | 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/… | |
| Sep 20, 2023 at 13:24 | history | edited | Greenonline | CC BY-SA 4.0 |
Code formatting and removed code formatting on list
|
| Sep 20, 2023 at 13:11 | history | edited | thomas | CC BY-SA 4.0 |
deleted 3 characters in body
|
| Sep 20, 2023 at 13:08 | history | edited | thomas | CC BY-SA 4.0 |
added 13 characters in body
|
| Sep 20, 2023 at 13:08 | history | edited | thomas | CC BY-SA 4.0 |
added 2 characters in body
|
| Sep 20, 2023 at 13:07 | history | edited | thomas | CC BY-SA 4.0 |
added 453 characters in body
|
| Sep 20, 2023 at 13:02 | comment | added | thomas | 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 | |
| Sep 20, 2023 at 12:50 | comment | added | Mike973 | 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. | |
| S Sep 20, 2023 at 11:42 | review | First questions | |||
| Sep 20, 2023 at 13:24 | |||||
| S Sep 20, 2023 at 11:42 | history | asked | thomas | CC BY-SA 4.0 |