Final steps: Tune MPPI for release on reference hardware platform

[artofnothingness]

Too high move forward cost after addition prefer forward critic i guess

[SteveMacenski]

It seemed fine to me last time I tested, but I can take a look again. If its just gain tuning and not code changes required, we can push it off til we finish a stable version

[artofnothingness]

close this temporary till new params tuning iteration

[SteveMacenski]

I just refocused the goal of the ticket as a reminder to do final tuning, which hopefully will be done on hardware if/when I can get access and time to do so

[SteveMacenski]

https://github.com/artofnothingness/mppic/issues/41#issuecomment-1165983035 tuning comments -- probably good for readme or at least when deciding on final parameters to ship with

• 3-3.5s for projection time decent range -- I recommend 3
• 0.05-0.1 s time increments a good range
• 0.25-0.45 decent range temperature -- I recommend 0.35

[SteveMacenski]

• Dead minimum of 500 batches for decent behavior, but I see real improvements at 1000 and very smooth behavior at 2000. 3000+ seems very nice as well, but that's outside the range of what I think we're going to be able to support on even my 8th gen i7 unless we make 30%+ speed ups. 1,000 is the smallest number I'd like to even consider for default behavior, but 2,000 is definitely the ideal.
• To support 0.075 time increments, that puts our minimum control at 13 hz. Anything below 20hz I think is probably not a good idea anyway from experience and stability on hardware. This is very difficult to judge in simulation, so I think this is definitely something for hardware tuning. 20hz seems like a dead minimum, 40hz would be a good thing to aim for to tune performance until we can achieve, and 50hz would be the top end of anything we should consider.

So if we're going to aim for what would be the best, I think 40hz with 2000 batches would be the thing to aim for.

with a temp of 0.35, time increment of 0.075, and projection time of 3 seconds with the otherwise default critics, the controller takes about 30ms for 2,000 batches, which corresponds to about 33 hz (it takes about 40-50ms when a new path is given).

That gives us a goal of improving performance by about 20-30% to achieve that.

[SteveMacenski]

Add comment about higher speeds and further prune distances to enable. Review comments in the Smoothing ticket and the Tuning PR to summarize tuning / configuration assistance notes for users.

[SteveMacenski]

Things to evaluate on hardware

• Good distance from obstacles
• Smooth and quality navigation path tracking
• Reactive to dynamic obstacles or obstacles on path
• Convergence to goal smoothly

[SteveMacenski]

Update defaults in code + readme defaults table + readme xonfiguration example

[SteveMacenski]

104 does docs and testing