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

Question

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.

---

Originally posted by Dhara on ROS Answers with karma: 16 on 2022-05-16

Post score: 0

Answer 1

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.

---

Originally posted by emielke with karma: 261 on 2022-05-16

This answer was NOT ACCEPTED on the original site

Post score: 1

---

Original comments

Comment by Dhara on 2022-05-17:
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?

Comment by emielke on 2022-05-17:
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?

Comment by Dhara on 2022-05-17:
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?

Answer 2

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.

---

Originally posted by Dhara with karma: 16 on 2022-06-23

This answer was ACCEPTED on the original site

Post score: 0