-
Notifications
You must be signed in to change notification settings - Fork 173
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Real Panda aborts motion with current joint limits in joint_limits.yaml
#116
Comments
Are you using MoveIt2? If so, there's a jerk-limited trajectory smoothing plugin that might help. There are usage instructions here: There's a PR in progress to bring this to MoveIt 1. I'm sorry I don't know the answers to your other questions. |
Thanks for pointing me to this plugin, I'll definitely take a look at it but no, I'm still using MoveIt 1 and ROS Noetic. Can I access the PR for MoveIt 1 somewhere? Any further information about whether these joint limits work for somebody else would be greatly appreciated! |
Do they match the limits in the Franka Emika official repo? Because lots of people are using that on actual robots. |
If I understand correctly, the Panda hardware limits (also found here) should be much higher than the limits used in joint_limits.yaml. |
They don't have to be higher (they could be the same). You're correct that the unit is rad/s^2 everywhere. |
Sorry, that was imprecisely formulated on my part. What I meant to say was that the Panda hardware limits are much higher than the limits given in the current moveit Edit: ... which is why I'm confused about the behavior that I'm seeing |
Can you provide more information about which time parameterization plugin you use? The default plugin, Did you try another plugin, e.g. Which versions of MoveIt and franka_ros are you using? |
Thanks for your reply. I was indeed using the default plugin. However, changing to On another panda robot that we use I can execute the motion, but the motor of the first joint is clearly overshooting the desired positions which results in braking with the maximal allowed accelerations in multiple trajectory points. I plotted the planned and observed velocities and accelerations to see what happens. |
If there is a discrepancy between planned and executed trajectories, you should file a bug report over at franka_ros, who provide the actual robot controllers. MoveIt correctly plans the trajectories. |
The robot did not carry any weight during these tests.
We recorded measured velocities during execution in fixed time intervals and calculated accelerations from these values just to visualize what happens during the last part of our example motion. |
I would expect much more noise from calculated accelerations. |
Dear MoveIt-Experts,
thank you for developing and maintaining this framework!
I'm using Panda for my research and am currently trying to optimize its execution speed. So far, I had been using the default joint limits from the
config/joint_limits.yaml
(from an earlier version of the moveit config) with all themax_velocity
limits set to the values given in the FE FCI documentation and allmax_acceleration
limits set to zero and encountered no problems during execution.I tried setting the values for
max_acceleration
to the values currently given injoint_limits.yaml
on the melodic and noetic branches, leading to Panda moving considerably faster but consistently throwinglibfranka: Move command aborted: motion aborted by reflex!
error and stopping the motion when trying to execute the task.With some trying around I could reestablish reliable execution by setting the
max_acceleration_scaling_factor
to 0.5.My question is: Have these limits been tested on real hardware and should work without throwing this error? If so, what could be the reason for my Panda aborting these movements?
Thanks and best regards!
The text was updated successfully, but these errors were encountered: