Comments (4)
Maybe a "SpeedCritic" will be best way to explicitly desire trajectories/cmds that lead to a target speed... IOW vx_max?
from navigation2.
I'm not entirely sure how to read this ticket's request. If you'd like to make some kind of system for auto-tuning or testing, I'm all for it, but that is going to be something that probably makes sense as a separate repository if its going to be extremely involved.
Maybe a "SpeedCritic" will be best way to explicitly desire trajectories/cmds that lead to a target speed... IOW vx_max?
Sure, its plugin based for a reason, you can add any plugins your like that optimize for what's important to you. I did remark on that a bit in your other ticket #4219 The defaults I set to run at about 0.5m/s so you'd need to retune for higher velocity regimes. I'm sure its possible, you just need to make sure you have a large enough costmap to be able to handle that (i.e. if you have a prediction horizon of 5 seconds at 3.5 m/s, that's a costmap size of 35 meters) and thus a computer which can handle computing long trajectories like this in real-time. With speed comes increased computational burden.
I suppose you could try to either have a very low prediction horizon to stay inside a smaller costmap or keep it longer but have a good chunk of the trajectory off of the costmap, but those are both not optimal setups. Perhaps we need to adjust a couple of the critics to enable that, since right now we prune the path off of the costmap for alignment longer-term and cost critic values off of the costmap are set to max. We could have settings which lets you preform more actions outside of the costmap horizon (and don't negatively score when off of it) but then you run the risk of having collision issues if you only know about an obstacle once its too late to react to it. You'd need a strong low-level safety system to catch such situations and want to run the controller pretty fast (50+hz) to have the best chance of getting around those situations before they become a safety issue once the obstacle gets inside of the costmap window. The costmap size should at the bare minimum be the length of deceleration from full speed to a total stop (2x for both direction) - but you'd want it to be larger to be able to catch obstacle information earlier to plan around it before its a safety issue.
Another direction is if you had vectorized detections rather than relying solely on costmap information, we could include that in a new MPPI critic so that it would take into account collision information outside of the costmap window (i.e. if you have AI detectors, Radar, etc). That would be a general purpose and valuable improvement to MPPI that wouldn't be particularly hard to implement.
Another yet direction is improving the runtime performance so it can run over the larger time horizons, but that is probably going to require a GPU and a bit of effort on your part to GPU-ize MPPI.
from navigation2.
Hey - any updates / thoughts here?
from navigation2.
Closing without update
from navigation2.
Related Issues (20)
- Invalidate Pointer Accessed during `isUnsafeToPlan()` calculation of `nav2_theta_planner` HOT 1
- Obstacle Layer is still current after enable/disable HOT 6
- NullPointer Accessed during `makePlan` calculation of nav2_navfn_planner HOT 1
- NullPointer Accessed during `findCircumscribedCost` calculation of nav2_smac_planner HOT 1
- Global Costmap Not Updating with New Obstacles in ROS2 HOT 1
- How to implement path validity checking with ML models (GPT, LLM, etc) HOT 12
- Unable to Change default_nav_to_pose_bt_xml From .yaml file HOT 1
- [nav2_costmap] UAF bug caused by the exit mechanism flaw in class `ClearCostmapService` HOT 1
- Can't install for ROS2 Jazzy HOT 1
- How to stop some behavior server's behaviors? HOT 1
- min_x_velocity_threshold, min_y_velocity_threshold, min_theta_velocity_threshold do not appear to be in use: investigate HOT 1
- Completely shutdown dynamic_param callback threads instead of only `dyn_param_handler_.reset()` HOT 4
- [nav2_costmap] UAF bug caused by incomplete closed `dynamicParametersCallback` thread in `Inflation_layer_` HOT 1
- Increase backup speed for recovery in default BTs HOT 1
- Unable to build from source after PR #4393 HOT 2
- Nav2 Docking: Send a navigation goal while the robot is docking or is already docked HOT 3
- Compute Path Through Poses, transformPoseInTargetFrame "base link" does not exist HOT 2
- min_turning_r parameter is not applied HOT 1
- Obstacle layer min_height does not get applied HOT 7
- nav2_mppi_controller - ARM (Jetson NANO) Issue? [component_container_isolated-1]: process has died HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from navigation2.