Real Panda aborts motion with current joint limits in `joint_limits.yaml`

[nikaulen]

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]

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

https://github.com/ros-planning/moveit2/pull/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]

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]

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]

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]

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

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

[nikaulen]

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]

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]

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.

[rhaschke]

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]

I cannot confirm the reported behavior on our Panda robot:

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]

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]

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.