MPPI asymmetric accelerations cause slower trajectories

[tonynajjar]

Bug report

Required Info:

• ROS2 Version:
  • Jazzy
• Version or commit hash:
  • 6206406 + custom changes (likely unrelated to this bug)

Steps to reproduce issue

For my use case I want to decelerate much faster then I accelerate e.g ax_max: 0.2 and ax_min: -2.0. I assume that's a valid configuration no?

Expected behavior

The optimal and candidate trajectories become very unstable - not sure what's happening internally

Actual behavior

Stable trajectories and simple acceleration limiting as if done by the velocity_smoother

Reproduction instructions

Additional information

[SteveMacenski]

A couple of question:

• Related to MPPI acceleration constraints not respected #5464?
• If you set it to -0.2 - 0.2 or -2.0 - 2.0 do you see an issue? Just making sure its not an issue with fast or slow accelerations themselves and it has to do with asymmetry. Note that the PR MPPI acceleration constraints not respected #5464 takes issue with was in response to supporting slower acceleration profiles in a more stable fashion if you read its original ticket thread
• What is the behavior that you see and is this using the motion model changes from 5464?

[tonynajjar]

Related to #5464?

No, it reproduces without #5266

If you set it to -0.2 - 0.2 or -2.0 - 2.0 do you see an issue? Just making sure its not an issue with fast or slow accelerations themselves and it has to do with asymmetry.

It's because of the asymmetry, similar values work fine, no matter how small or large

this using the motion model changes from 5464?

No, without

What is the behavior that you see?

It looks like the bigger the difference between ax_min and ax_max, the "shorter" the candidate trajectories are

ax_max = 1.0 ax_min= -1.0:

ax_max = 1.0 ax_min= -5.0:

[SteveMacenski]

Ok. Last question: do you see this with Nav2 on main without your custom changes to solidly mark this as a bug independent of your changes? I don’t have an immediate explanation other than perhaps the wrong acceleration is being used in the wrong place which is uncovering a bug independent how we apply acceleration in the motion model or the post-optimization clamping to make sure optimal trajectories are remaining within dynamic limits.

I don’t intuit a reason why in a single iteration that would cause a slower trajectory or why when iteratively run it would result in that either, unless some critic is sensitive to acceleration or there’s a min/max use error when applying the limits so that in some case the 1 is being used when it should be the 5.

[tonynajjar]

do you see this with Nav2 on main without your custom changes

I tried on the latest main now with no changes in MPPI package and still reproduces. It would be useful if anyone else using MPPI could confirm this independently (@doisyg do you use considerably different ax_max and ax_min?), maybe I missed something particular in my setup.

[SteveMacenski]

That's enough for me to put this on my queue to look at, thank you. Though help from others are welcome, it might be a few weeks before I can address in earnest