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
That is general advice which is true. The discrepancy larger will impact performance the larger these values diverge. This advice is especially pointed to people trying to make it work at 10-15-20hz where the model_dts there are so huge the controller isn't super stable.
It still applies to the situation you rightly point out. But that was a tactical trade off between making the discrepancy low, yet having a high enough prediction time (model_dt * number of points), and a small enough number of points to work on a broad range of compute platforms out of the box.
You'd be right to say that if you're tuning and you have CPU you can spend, reducing that to 1/freq is a good potential move. The value add of much smaller after you've hit ~0.04 & at or lower than 1/freq is marginal (if any) and its better to optimize for other things like longer time horizons or more samples in your batches -- unless in exceptional situations
first line of https://github.com/ros-planning/navigation.ros.org/blob/master/configuration/packages/configuring-mppic.rst#general-words-of-wisdom strongly directs to never set
model_dt
>1 / controller_frequency
but in the example right above it, the controller frequency is 30.0 which suggestsmodel_dt
should be less than 0.33.I won't make a PR for this since I don't know exactly if I should bring the controller frequency or model_dt lower.
The text was updated successfully, but these errors were encountered: