search

artofnothingness / mppic

MIT License
90 stars 21 forks source link

Consider log-form distribution #94

Open mkolodziejczyk-piap opened 2 years ago

mkolodziejczyk-piap commented 2 years ago

https://clearpathrobotics.com/blog/2022/05/indiana-university-explores-collision-free-navigation-in-cluttered-environments/

Seems like they are using nav stack

SteveMacenski commented 2 years ago

Thanks for sharing! This is the paper https://arxiv.org/pdf/2203.16599.pdf

Might be worth looking at the log-distribution, but also reading the results I'm not particularly impressed. Using the changes in distributions, sure, would improve smoothness, but that's not really going to solve it "enough" to call things 'smooth' without other actions. Also they don't really compare apples-to-apples in making the gaussian distribution on-par with the distribution of trajectories for their distribution in experimentation. Never the less, most of the metrics was < 1% different so its really difficult for me to say with any degree of certainty that those changes matter. I suspect the only reason for the few failures of normal MPPI is an intentional decision to set the distribution parameters so poorly as to make it so.

Seems like a potential new option we could offer once this is 'done' for a hardware testing phase, but I don't think it's going to necessarily be an objective improvement. Though, what I like about this paper is that its a model for potentially how we can structure a paper regarding this work in this repository if we choose to. I think the novelty of this work is in the cost function design and add benchmarking against existing trajectory planners that are commonly used.

Thanks for sharing this! Certainly got my brain moving a bit. The variation described is also trivial to implement to it might be worth the couple of hours just to test and see. Though, I'm quite surprised this made it through RAL. Its well put together, but the results and actual change are pretty unimpressive - more of a conference paper.

SteveMacenski commented 1 year ago

~Closing - but thanks for bringing to our attention!~ Actually, I'll just retarget the ticket towards trying that out

SteveMacenski commented 1 year ago

@mkolodziejczyk-piap I saw you have a fork using torch -- does that help in performance? Just curious if we should consider that here.

mkolodziejczyk-piap commented 1 year ago

Actually I gave up the idea to use torch (for many reasons) in favour of arrayfire (with flashlight in the future). My branch af is still WIP and need rebase, but I'm planning to come back to dev after some break. Apart from that, I'm planning to also modify Costmap2D as a af::array GPU grid, based on hypergrid project, to have fast footprint collision detection. Here's my TODO. So, still a lot to do to make it work

artofnothingness commented 1 year ago

What were the reasons for not using torch?

mkolodziejczyk-piap commented 1 year ago

Mostly because libtorch doesn't support JIT and vectorization. I also feel that the pace of development of the project slowed down recently and it's purpose is mainly to execute pytorch models in C++. Nevertheless, when I get to model execution I'll consider using libtorch models (jitted in python) instead of flashlight.

SteveMacenski commented 1 year ago

Well do let us know if you find you can get better performance with either libraries. We're pretty happy with xtensor, but obviously faster is always better. I should be back on working on this work once I get through my backlog from Japan (maybe still a week or two).