Skip to content
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

Closed
nikaulen opened this issue Jul 20, 2022 · 12 comments
Closed

Comments

@nikaulen
Copy link

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 the max_velocity limits set to the values given in the FE FCI documentation and all max_acceleration limits set to zero and encountered no problems during execution.

I tried setting the values for max_acceleration to the values currently given in joint_limits.yaml on the melodic and noetic branches, leading to Panda moving considerably faster but consistently throwing libfranka: 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!

@AndyZe
Copy link
Member

AndyZe commented Jul 20, 2022

Are you using MoveIt2? If so, there's a jerk-limited trajectory smoothing plugin that might help. There are usage instructions here:

moveit/moveit2#1202

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.

@nikaulen
Copy link
Author

nikaulen commented Jul 20, 2022

Are you using MoveIt2?

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!

@AndyZe
Copy link
Member

AndyZe commented Jul 20, 2022

Do they match the limits in the Franka Emika official repo? Because lots of people are using that on actual robots.

https://github.com/frankaemika/franka_ros

@nikaulen
Copy link
Author

If I understand correctly, the Panda hardware limits (also found here) should be much higher than the limits used in joint_limits.yaml.
Assuming the values in the moveit config also use rad/s^2 as unit for acceleration.

@AndyZe
Copy link
Member

AndyZe commented Jul 20, 2022

They don't have to be higher (they could be the same).

You're correct that the unit is rad/s^2 everywhere.

@nikaulen
Copy link
Author

nikaulen commented Jul 20, 2022

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 joint_limits.yaml

Edit: ... which is why I'm confused about the behavior that I'm seeing

@rhaschke
Copy link
Contributor

Can you provide more information about which time parameterization plugin you use? The default plugin, AddTimeParameterization / IterativeSplineParameterization, uses a default acceleration of 1.0, which explains that a factor of 0.5 works again.

Did you try another plugin, e.g. default_planner_request_adapters/AddTimeOptimalParameterization instead of default_planner_request_adapters/AddTimeParameterization?

Which versions of MoveIt and franka_ros are you using?

@nikaulen
Copy link
Author

Thanks for your reply. I was indeed using the default plugin. However, changing to AddTimeOptimalParametrization does not change panda's behavior. I'm using franka_ros version 0.8.1 and MoveIt version 1.1.9.

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.

planned
observed

@rhaschke
Copy link
Contributor

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.
Maybe you overload the robot?

@rhaschke
Copy link
Contributor

I cannot confirm the reported behavior on our Panda robot:
image

However, the controller isn't optimally tuned here as well - lots of oscillations in the deceleration phase. Maybe yours is tuned even worse? How did you record/plot actual accelerations?

@nikaulen
Copy link
Author

Maybe you overload the robot?

The robot did not carry any weight during these tests.

How did you record/plot actual accelerations?

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.

@rhaschke
Copy link
Contributor

I would expect much more noise from calculated accelerations.
In any case, I think you should contact Franka support as your robot controllers are obviously badly tuned.
From MoveIt's perspective, everything looks fine. Hence, closing here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants