Ask Your Question
0

When changing set_max_velocity_scaling_factor(0.5), moveit couldn't plan trajectory

asked 2022-05-16 05:52:23 -0500

Dhara gravatar image

updated 2022-05-17 05:15:47 -0500

Hello,

I am right now working to slow down the velocity of the abb_irb6640 model. When I use set_max_velocity_scaling_factor(1), everything works fine. But when I want to use set_max_velocity_scaling_factor(0.5), I get an error : Invalid Trajectory: start point deviates from current robot state more than 0.01 joint 'joint_1': expected: 0.575495, current: 0.6802.

My system is: melodic and ubuntu 18.04

Any leads will be very helpful.

edit retag flag offensive close merge delete

2 Answers

Sort by ยป oldest newest most voted
0

answered 2022-06-23 06:17:03 -0500

Dhara gravatar image

Found an answer:

Because I used group.execute(wait=False), moveIt does not wait for the trajectory to complete the first path, as it does not track the status of trajectory execution. And as soon as moveit received second execute command, it sends this above error. set_max_velocity_factor() was not an issue. So, used this wait parameter cautiously.

edit flag offensive delete link more
1

answered 2022-05-16 09:59:56 -0500

emielke gravatar image

Not sure exactly why the change would cause an issue, but you could try one of the following:

  • in your moveit_config package for your robot, in launch/trajectory_execution.launch.xml there is a line <param name="trajectory_execution/allowed_start_tolerance" value="0.01"/> that you can change to be more tolerant. (Note, this may not help everything, but could be a place to start looking).
  • Before you execute the trajectory, do you set your move_group start state? (i.e. move_group.setStartStateToCurrentState()?

I do know i've had issues with the UR models for the first bullet point, not much experience with abb, however. But those might be some places to start.

edit flag offensive delete link more

Comments

Hii,

I tried the first solution and set the tolerance to 0.05, but error stays the same. And I couldn't afford more tolerance in my process. My planning sequence is something like this:

`abb.set_start_state(robot.get_current_state())
 abb.set_pose_target(table1, end_effector_link)
 plan = abb.plan()
 if plan.joint_trajectory.points:
    abb.set_max_velocity_scaling_factor(0.5)
    abb.execute(plan,wait=False)
    rospy.sleep(2)`

Is there any other solution?

Dhara gravatar image Dhara  ( 2022-05-17 05:08:24 -0500 )edit

So like I said, I'm not familiar with abb, but what does the initial pose look like? Per here you might need to send a joint move to get it away from an initial singularity, and then plan to a pose. But based on the fact you do it with velocity at 100% makes me think this isn't the case.

Is the velocity scaling the only thing changed?

emielke gravatar image emielke  ( 2022-05-17 09:34:57 -0500 )edit

yes, you are right. Only thing that is changed here is velocity scaling. I also test this code: abb.set_start_state_to_current_state() start_pose1.pose.position.z = start_pose1.pose.position.z + 0.6 abb.set_pose_target(start_pose1, end_effector_link) plan = abb_plan_path(abb) if not plan == False: abb.set_max_velocity_scaling_factor(0.2) abb.execute(plan,wait=False) rospy.sleep(2)

But error stays the same. But when I use abb.go() for combine planning and execution ,everything works. Why is it like that?

Dhara gravatar image Dhara  ( 2022-05-17 09:46:27 -0500 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

2 followers

Stats

Asked: 2022-05-16 05:52:23 -0500

Seen: 46 times

Last updated: Jun 23