velocity smoother deadband velocity as an interval about navigation2 HOT 10 CLOSED

I don't know much about the MPPI controller so sorry if i'm wrong but looking at the documentation i don't see how the deadband critic would work differently then what i have now with DWB + velocity_smoother. Wouldn't that also block all negatives values ?

I hadn't thought of RPP, that's a great advice, thanks !! It looks like with the right desired_velocity parameter, it could work. But it won't if the controller bring the command slowing toward this value instead of sending it directly. I'll try to play around accelerrations.
I'll try that as soon as i get my hands on the robot again. Mid-next week probably

I think it would be fine without an highly dynamic behavior but if that still doesn't work i'll try DWB/MPPI with my own critics.

from navigation2.

In RPP you can set the minimum speeds for slowdown due to regulation constraints and a desired translational velocity, that should square you away on that axis. The angular is a little more challenging since the angular is proportional to the error in path tracking so its a continous range. I suppose if you drive enough off then eventually the angular velocity will rise to a level to meet the threshold. The robot might do a little bit of delayed turning and/or a little low-frequency oscillations in straight lines but that "should work" for an MVP/POC level. This is also possibly a place where specialized algorithms to really optimize the behavior aware of these deadbands might be useful. I haven't read the literature on this subject, but I imagine there is plenty!

from navigation2.

I tried it and you were right, RPP makes it work really well !
The angular velocities threshold is actually low enough for it to work without oscillations. A bit of tuning is required but no need for homemade critics or a new feature.

Thanks a lot 👍

from navigation2.

Yes, but also like I said, the local path isn't the trajectory from the controller, its just the segment of the global path that the controller is evaluating. This is the same as in ROS 1 Navigation as well.

from navigation2.

You could use MPPI with the deadband critic (which is relatively new!) to penalize actions outside of those ranges or create easily your own critics for DWB that do the same.

However this is a bit of a specialized problem that may require a bit of a specialized solution with some leg work on your part. I think MPPI/DWB can do what you need, but you may benefit from something a bit simpler / different if you can't control the robot's speed continuously. Something like a Pure Pursuit with minimum velocity / max velocity ranges could work - I think RPP may actually allow you to do that out of the box with the right configurations, but happy to review / merge a PR with any changes required to make it work naturally.

Do you need highly dynamic behavior or something that follows the path (and path can be recomputed regularly) OK? If the latter, RPP might be fully setup to do it with a few parameter tweaks and maybe some minor handling differences in the code (but I think it should be trivial). DWB/MPPI will give you that more dynamic behavior, but will likely require a bit more thinking / experimentation on your part.

from navigation2.

After a bit of testing i would actually need a more dynamic behavior. Ideally i would need the controller to be able to adapt the path to dynamic obstacles that are seen on the local costmap.

From what i understand the RPP wont achieve that since it stricly follows the global plan. So i would want to try using MPPI/DWB with a custom critic to ensure velocities are within the appropriate ranges.

But there is something i don't understand, where is the local costmap used ? I thought the local_plan was an adapted version of the global_plan taking into account obstacles that were not seen when the path was computed. But i only see my local_costmap being subscribed to by the behavior_tree and never be the controller or the planner.

Is this a configuration problem from me or am i misunderstanding how it works ?

from navigation2.

The local plan is typically just the segment of the global plan transformed and pruned into the local and odometry frames. The trajectory published by the algorithms for the velocity and/or time-series trajectory being executed will be published by various other debugging topics depending on the algorithm (i.e. RPP/DWB publish out its arcs; MPPI publishes out its trajectry). Its generally bad to subscribe to at least the MPPI one because the candidates are huge and the publication of all those samples, even when pruned, is alot of data and slows down the actual controller in visualization. Its only for debugging use.

If you need the dynamic behavior and large deadbands, I'd suggest looking at creating the deadband critics for DWB/MPPI depending on which you want to use. There may be other specialized algorithms that you should look into literature regarding.

The isn't something unfortunately I can give you a recipe for "here's how to do it" or even a "here's how I would do it" that I would be confident will work very well. I'd personally need to experiment with a few ways of doing it, analyze where they are good/bad and then come to the final solution direction to refine. The MPPI critic is where I'd start since MPPI is very powerful and no matter what, a critic will be part of a MPPI-based solution, even if not itself sufficient. I suspect through for MPPI that would be sufficient for path tracking (you'll need to completely retune the system from scratch though probably), though the stopping at goal bits might be more complicated. If you don't have high accuracy requirements, then that may be easier.

Let us know what you're thinking / evaluating and how it goes! If there's some critics / changes for DWB/MPPI to get what you want, we're happy to review / merge PRs so that its part of the stack (that you don't have to maintain + solve the problem for the next person that comes along)

from navigation2.

Ok so the local_plan is actually just a portion of the global plan transformed and pruned ? But it does not take into account the local dynamic obstacles ?
Then how to get the path being adapted to thoses ? I thought that was done be the local_planner in ros1 which was replaced be the controller in ros2.

Will those dynamic obstacles be used to compute the path by the MPPI using ObstaclesCritic ? How is it possible without the controller_server subscribing to the local_costmap ?

I'll make sure to keep you up to date to the solutions i find !

PS : Just to be sure i'm clear, i am using a global_costmap that only has the static obstacles ( inflation layer and static layer ) and a local_costmap that only has the dynamic ones (inflation layer and obstacle layer).

The way i thought it works is this one : but it might be outdated/i misinterpreted

from navigation2.

Ok so the local_plan is actually just a portion of the global plan transformed and pruned ? But it does not take into account the local dynamic obstacles ?

Correct. See the debugging topics for the specific algorithms that publish their computed trajectories as I mentioned above.

Will those dynamic obstacles be used to compute the path by the MPPI using ObstaclesCritic ? How is it possible without the controller_server subscribing to the local_costmap ?

See the MPPI docs, there are multiple options for collision avoidance critics. Obstacles are one, Cost is another. The local costmap is inside of the controller server.

PS : Just to be sure i'm clear, i am using a global_costmap that only has the static obstacles ( inflation layer and static layer ) and a local_costmap that only has the dynamic ones (inflation layer and obstacle layer).

Usually how I set it up too :-)

BTW that diagram is ROS 1 and bares little resemblance to Nav2. See https://docs.nav2.org/

from navigation2.

Ok perfect, i think i get it !!

So the reason RPP was generating path through local dynamic obstacles is because RPP doesn't take them into account (hence "pure pursuit" ), but MPPI with cost/obstacles critic will ?

Thanks a lot :-)

from navigation2.