You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am experiencing a problem related to the acceleration profile generated by MoveIt Servo trajectory planner on my UR5e. I’m trying this example of pose tracking. For a bin-picking scenario.
The documentation specifies that MoveIt Servo can enforce only joint position and velocity limits. However, I am experiencing a rough acceleration profile at the start of the motion as shown in the following picture:
At the starting point, the robot joints make an annoying noise, which I want to avoid. During the deceleration phase this noise is not present and the deceleration profile seems much smoother.
I have seen that the time parametrization in MoveIt2 uses the TOTG algorithm to define the velocity and acceleration profiles, which enforce up to the joint acceleration limit. However, it seems that the acceleration limit is not read in MoveIt Servo. I assume that TOTG is used any time you plan using OMPL and Pilz planner, but I haven’t found this information written somewhere. And I would like to understand if changing to Pilz for instance may be a solution to my problem as it enforce at least the acceleration limit.
I have seen there is the possibility to perform an additional post-processing step and run [Ruckig](https://moveit.picknik.ai/humble/doc/examples/time_parameterization/time_parameterization_tutorial.html#time-parameterization-algorithms) algorithm to enforce also the jerk. From the documentation I have seen that this additional plugin is specified in the ompl_planning.yaml, therefore I believe it can be used only when planning with OMPL. Is this true?
As my goal is to remove this unwanted sound when I move my robot, do you think that implementing a vanilla Pilz planner enforcing the acceleration limits is enough? Do you have examples I can take to do so? I am using ros2 Humble.
Is there the possibility of implementing a minimum jerk time parametrization?
Thanks.
The text was updated successfully, but these errors were encountered:
I am experiencing a problem related to the acceleration profile generated by
MoveIt Servo
trajectory planner on myUR5e
. I’m trying this example ofpose tracking
. For abin-picking
scenario.The documentation specifies that
MoveIt Servo
can enforce only joint position and velocity limits. However, I am experiencing a rough acceleration profile at the start of the motion as shown in the following picture:At the starting point, the robot joints make an annoying noise, which I want to avoid. During the deceleration phase this noise is not present and the deceleration profile seems much smoother.
I have seen that the
time parametrization
inMoveIt2
uses the TOTG algorithm to define the velocity and acceleration profiles, which enforce up to the joint acceleration limit. However, it seems that the acceleration limit is not read inMoveIt Servo
. I assume thatTOTG
is used any time you plan usingOMPL
andPilz
planner, but I haven’t found this information written somewhere. And I would like to understand if changing toPilz
for instance may be a solution to my problem as it enforce at least the acceleration limit.I have seen there is the possibility to perform an additional post-processing step and run
[Ruckig](https://moveit.picknik.ai/humble/doc/examples/time_parameterization/time_parameterization_tutorial.html#time-parameterization-algorithms)
algorithm to enforce also the jerk. From the documentation I have seen that this additional plugin is specified in theompl_planning.yaml
, therefore I believe it can be used only when planning with OMPL. Is this true?As my goal is to remove this unwanted sound when I move my robot, do you think that implementing a vanilla
Pilz
planner enforcing the acceleration limits is enough? Do you have examples I can take to do so? I am using ros2 Humble.Is there the possibility of implementing a
minimum jerk
time parametrization?Thanks.
The text was updated successfully, but these errors were encountered: