Ask Your Question

rivertam's profile - activity

2019-04-22 16:04:49 -0500 received badge  Nice Answer (source)
2019-02-28 09:52:04 -0500 received badge  Nice Answer (source)
2019-01-02 17:31:18 -0500 received badge  Famous Question (source)
2018-04-02 18:16:13 -0500 received badge  Self-Learner (source)
2018-01-29 11:23:34 -0500 received badge  Famous Question (source)
2018-01-09 20:16:17 -0500 received badge  Notable Question (source)
2017-12-29 15:02:10 -0500 commented answer MoveIt! path final position is off significantly

It's possible, but the commit literally just had that one change in it, and it solved the problem. It was a pretty long

2017-12-27 19:08:56 -0500 received badge  Notable Question (source)
2017-11-15 08:39:38 -0500 received badge  Enthusiast
2017-11-10 01:12:41 -0500 received badge  Popular Question (source)
2017-11-10 01:03:56 -0500 received badge  Popular Question (source)
2017-11-09 15:55:28 -0500 marked best answer MoveIt! path final position is off significantly

Hi everyone.

I'm trying to use MoveIt! for path planning. I'm using the TRAC_IK and I set the timeout to 10 seconds (just as a debugging measure), but the final position is consistently off by an inconsistent amount. This is frustrating in particular because I was led to understand the path planners would be pretty much perfect given enough time.

I'm running the planner pretty much as the tutorial suggests I do it:

    geometry_msgs::PoseStamped pose;
    pose.header.frame_id = "world";
    pose.pose.position.x = messageTarget.x();
    pose.pose.position.y = messageTarget.y();
    pose.pose.position.z = messageTarget.z();

    pose.pose.orientation.w = 0;

    std::vector<double> tolerancePose(3, 0.0001); // testing values; I've also tried higher values
    std::vector<double> toleranceAngle(3, 0.0001);

    req.group_name = "arm";
    moveit_msgs::Constraints poseGoal =
            kinematic_constraints::constructGoalConstraints("ee_link", pose, tolerancePose, toleranceAngle);
    req.goal_constraints.push_back(poseGoal);

    planning_interface::PlanningContextPtr context =
            this->plannerInstance->getPlanningContext(this->planningScene, req, res.error_code_);

    context->solve(res);

and I'm getting back a result as a moveit_msgs::MotionPlanResponse. However, the final point in the response is often off by as much as .07m in any axis (though I will grant that's pretty rare; it's usually closer to 0.03m). I'm checking the final point as such:

    this->updateState(planResponse.trajectory.joint_trajectory.points[0].positions);
    const auto & eeLinkTranslate = this->planningScene->getCurrentStateNonConst().getGlobalLinkTransform("ee_link").translation();
    logger->info("Moving EE to <{}, {}, {}> (should be <{}, {}, {}>)", eeLinkTranslate[0], eeLinkTranslate[1], eeLinkTranslate[2], messageTarget.x(), messageTarget.y(), messageTarget.z());

I suspect my issue is the inverse kinematics in particular because I've also tried KDL and that seemed to make the problem worse, but it could also be the planner (I've thus far been unable to change the planner. All instructions have failed me. I'll comment with steps I've attempted, but this is not part of my question unless someone thinks it's relevant). It could also be something entirely different.

I would appreciate any debugging steps or notes on how to resolve this issue.

Thank you!

2017-11-09 15:55:23 -0500 answered a question MoveIt! path final position is off significantly

The issue was that i wasn't setting TRAC IK's solve_type, so it was defaulting to Speed. To be totally blunt, I'm not su

2017-11-09 15:16:02 -0500 marked best answer RRTConnect/TRAC IK fails only on Distance solve_type

So I'm trying to change the solve_type to "Distance" as opposed to "Speed" for TRAC IK. RRTConnect and TRAC IK acknowledge the change, but I'm getting an error in the console and a failed compute solve. (it doesn't fail with Speed, and the target position I'm trying is essentially the start position).

The error is as follows:

Error:   RRTConnect: Unable to sample any valid states for goal tree
     at line 215 in /tmp/binarydeb/ros-kinetic-ompl-1.2.1/src/ompl/geometric/planners/rrt/src/RRTConnect.cpp

The code I'm using to solve is as follows:

    planning_interface::MotionPlanRequest req;
    planning_interface::MotionPlanResponse res;

    geometry_msgs::PoseStamped pose;
    pose.header.frame_id = "world";
    pose.pose.position.x = messageTarget.x();
    pose.pose.position.y = messageTarget.y();
    pose.pose.position.z = messageTarget.z();

    pose.pose.orientation.w = 1;

    std::vector<double> tolerancePose(3, 0.01);
    std::vector<double> toleranceAngle(3, 0.01);

    req.workspace_parameters.min_corner.x = -50;
    req.workspace_parameters.min_corner.y = -50;
    req.workspace_parameters.min_corner.z = -50;
    req.workspace_parameters.max_corner.x = 50;
    req.workspace_parameters.max_corner.y = 50;
    req.workspace_parameters.max_corner.z = 50;
    req.group_name = "arm";
    req.start_state.joint_state = this->getCurrentJointState(true);
    moveit_msgs::Constraints poseGoal =
            kinematic_constraints::constructGoalConstraints("ee_link", pose, tolerancePose, toleranceAngle);
    req.goal_constraints.push_back(poseGoal);

    planning_interface::PlanningContextPtr context =
            this->plannerInstance->getPlanningContext(this->planningScene, req, res.error_code_);

    context->solve(res);

Again, it works with "Speed" but not with "Distance".

My kinematics.yml file looks like this:

arm:
  solve_type: Distance
  kinematics_solver: trac_ik_kinematics_plugin/TRAC_IKKinematicsPlugin
  kinematics_solver_timeout: 10

I wouldn't mind changing to a different planner (if I could figure out how), but I think TRAC IK is right for our application.

Is there a way I can fix it? Am I not including the right information in the request?

2017-11-09 15:16:02 -0500 received badge  Scholar (source)
2017-11-09 15:15:57 -0500 answered a question RRTConnect/TRAC IK fails only on Distance solve_type

My problem was actually that my timeout was too high. I suppose MoveIt! or OMPL somewhere down the line has its own time

2017-11-09 11:15:39 -0500 edited question RRTConnect/TRAC IK fails only on Distance solve_type

RRTConnect/TRAC IK fails only on Distance solve_type So I'm trying to change the solve_type to "Distance" as opposed to

2017-11-09 11:15:06 -0500 asked a question RRTConnect/TRAC IK fails only on Distance solve_type

RRTConnect/TRAC IK fails only on Distance solve_type So I'm trying to change the solve_type to "Distance" as opposed to

2017-11-09 11:02:24 -0500 received badge  Supporter (source)
2017-11-03 08:08:40 -0500 received badge  Teacher (source)
2017-11-02 14:47:09 -0500 answered a question MoveIt RobotState initialisation

The "robot_description" param is just the description of the robot universally (it's loaded from the URDF). The robot mo

2017-11-02 14:47:09 -0500 commented question MoveIt! path final position is off significantly

I'm also somewhat unclear on the terminology. By "Planner" I mean RRTConnect or similar, not OMPL.

2017-11-02 14:47:08 -0500 commented question MoveIt! path final position is off significantly

I've attempted the following to change the planner: 1) Setting a different value for the request's planner_id 2) Removin

2017-11-02 14:47:08 -0500 asked a question MoveIt! path final position is off significantly

MoveIt! path final position is off significantly Hi everyone. I'm trying to use MoveIt! for path planning. I'm using th