Adding initial prototype for a MPPI trajectory validator#5319
Adding initial prototype for a MPPI trajectory validator#5319SteveMacenski merged 7 commits intomainfrom
Conversation
Signed-off-by: SteveMacenski <stevenmacenski@gmail.com>
|
@leander-dsouza we have more mypy errors :( |
|
@MarcoMatteoBassa @nourazzii take a look |
I have resolved them in #5322 :) |
nourazzii
left a comment
There was a problem hiding this comment.
Just a few comments but overall looks good to me.
nav2_mppi_controller/include/nav2_mppi_controller/optimal_trajectory_validator.hpp
Show resolved
Hide resolved
nav2_mppi_controller/include/nav2_mppi_controller/optimal_trajectory_validator.hpp
Show resolved
Hide resolved
Signed-off-by: SteveMacenski <stevenmacenski@gmail.com>
Signed-off-by: SteveMacenski <stevenmacenski@gmail.com>
Codecov ReportAttention: Patch coverage is
... and 6 files with indirect coverage changes 🚀 New features to boost your workflow:
|
Signed-off-by: SteveMacenski <stevenmacenski@gmail.com>
|
@nourazzii I added in some implementation so this does something out of the box by default. We now can check if the optimal trajectory is in collision (which it technically could be after I thought about it for some time, since the optimal trajectory is a combination of the best scored trajectories. If you're really close to an obstacle, the averaging out of the best few could make you out of dynamic feasibility. Once that is quashed down to the valid range, that could deform the trajectory by just that slight amount that makes it invalid -- so we can check for that immediately within the local time horizon). |
Signed-off-by: SteveMacenski <stevenmacenski@gmail.com>
Signed-off-by: Steve Macenski <stevenmacenski@gmail.com>
This creates a new plugin interface to MPPI which takes in the control request, optimal trajectory, and outputs if this is valid.
This is performed after the optimization process is completed to receive a final trajectory for smoothing - so we should already be applying kinematic and dynamic constraints to the output to make sure its valid in that regard. It should also be known collision free since that would trigger a soft and then hard reset if no trajectories are valid.
This can be used to validate the trajectory based on application specific constraints, constraints on control due to standards or multi-robot coordination, via point achievement, and so forth.
TODO
On implementation, we could add in: