rivertam's profile - activity

MoveGroup::plan causes hang/crash after apt update on ARM64 On an ARM64 docker image based on ros:noetic, calling a Move

LazyPRM with load_planner_data or _store_planner_data causes an undebuggable crash (after apt update, on ARM) On an ARM6

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

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!

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

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?

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

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

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

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

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

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

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