diff --git a/nav2_constrained_smoother/README.md b/nav2_constrained_smoother/README.md index d37eb51b63e..d34274cda29 100644 --- a/nav2_constrained_smoother/README.md +++ b/nav2_constrained_smoother/README.md @@ -28,7 +28,7 @@ smoother_server: # Parameters used to improve obstacle avoidance near cusps (forward/reverse movement changes) # See the [docs page](https://navigation.ros.org/configuration/packages/configuring-constrained-smoother) for further clarification w_cost_cusp_multiplier: 3.0 # option to have higher weight during forward/reverse direction change which is often accompanied with dangerous rotations - cusp_zone_length: 2.5 # length of the section around cusp in which nodes use w_cost_cusp_multiplier (w_cost rises gradually inside the zone towards the cusp point, whose costmap weight eqals w_cost*w_cost_cusp_multiplier) + cusp_zone_length: 2.5 # length of the section around cusp in which nodes use w_cost_cusp_multiplier (w_cost rises gradually inside the zone towards the cusp point, whose costmap weight equals w_cost*w_cost_cusp_multiplier) # Points in robot frame to grab costmap values from. Format: [x1, y1, weight1, x2, y2, weight2, ...] # IMPORTANT: Requires much higher number of iterations to actually improve the path. Uncomment only if you really need it (highly elongated/asymmetric robots) diff --git a/nav2_map_server/README.md b/nav2_map_server/README.md index c0e7a2cf6a8..94a6bd66af0 100644 --- a/nav2_map_server/README.md +++ b/nav2_map_server/README.md @@ -18,7 +18,7 @@ Currently map server divides into tree parts: - `map_io` library `map_server` is responsible for loading the map from a file through command-line interface -or by using serice requests. +or by using service requests. `map_saver` saves the map into a file. Like `map_server`, it has an ability to save the map from command-line or by calling a service. @@ -27,7 +27,7 @@ command-line or by calling a service. in order to allow easily save/load map from external code just by calling necessary function. This library is also used by `map_loader` and `map_saver` to work. Currently it contains OccupancyGrid saving/loading functions moved from the rest part of map server code. -It is designed to be replaceble for a new IO library (e.g. for library with new map encoding +It is designed to be replaceable for a new IO library (e.g. for library with new map encoding method or any other library supporting costmaps, multifloor maps, etc...). ### CLI-usage diff --git a/nav2_simple_commander/README.md b/nav2_simple_commander/README.md index c4f398f77d3..7af387eb02f 100644 --- a/nav2_simple_commander/README.md +++ b/nav2_simple_commander/README.md @@ -92,7 +92,7 @@ This will bring up the robot in the AWS Warehouse in a reasonable position, laun ### Manually -The main benefit of this is to be able to launch alternative robot models or different navigation configurations than the default for a specific technology demonstation. As long as Nav2 and the simulation (or physical robot) is running, the simple python commander examples / demos don't care what the robot is or how it got there. Since the examples / demos do contain hard-programmed item locations or routes, you should still utilize the AWS Warehouse. Obviously these are easy to update if you wish to adapt these examples / demos to another environment. +The main benefit of this is to be able to launch alternative robot models or different navigation configurations than the default for a specific technology demonstration. As long as Nav2 and the simulation (or physical robot) is running, the simple python commander examples / demos don't care what the robot is or how it got there. Since the examples / demos do contain hard-programmed item locations or routes, you should still utilize the AWS Warehouse. Obviously these are easy to update if you wish to adapt these examples / demos to another environment. ``` bash # Terminal 1: launch your robot navigation and simulation (or physical robot). For example diff --git a/nav2_smac_planner/README.md b/nav2_smac_planner/README.md index 0396664f8e6..1faa85bf381 100644 --- a/nav2_smac_planner/README.md +++ b/nav2_smac_planner/README.md @@ -37,7 +37,7 @@ The `SmacPlannerHybrid` is designed to work with: The `SmacPlannerLattice` is designed to work with: - Arbitrary shaped, non-circular robots requiring kinematically feasible planning with SE2 collision checking using the full capabilities of the drivetrain -- Flexibility to use other robot model types or with provided non-circular differental, ackermann, and omni support +- Flexibility to use other robot model types or with provided non-circular differential, ackermann, and omni support The `SmacPlanner2D` is designed to work with: - Circular, differential or omnidirectional robots diff --git a/nav2_theta_star_planner/README.md b/nav2_theta_star_planner/README.md index b8e77299048..722957f8416 100644 --- a/nav2_theta_star_planner/README.md +++ b/nav2_theta_star_planner/README.md @@ -74,9 +74,9 @@ This planner uses the costs associated with each cell from the `global_costmap` Providing a gentle potential field over the region allows the planner to exchange the increase in path lengths for a decrease in the accumulated traversal cost, thus leading to an increase in the distance from the obstacles. This around a corner allows for naturally smoothing the turns and removes the requirement for an external path smoother. -`w_heuristic_cost` is an internal setting that is not user changable. It has been provided to have an admissible heuristic, restricting its value to the minimum of `w_euc_cost` and `1.0` to make sure the heuristic and travel costs are admissible and consistent. +`w_heuristic_cost` is an internal setting that is not user changeable. It has been provided to have an admissible heuristic, restricting its value to the minimum of `w_euc_cost` and `1.0` to make sure the heuristic and travel costs are admissible and consistent. -To begin with, you can set the parameters to its default values and then try increasing the value of `w_traversal_cost` to achieve those middling paths, but this would adversly make the paths less taut. So it is recommend ed that you simultaneously tune the value of `w_euc_cost`. Increasing `w_euc_cost` increases the tautness of the path, which leads to more straight line like paths (any-angled paths). Do note that the query time from the planner would increase for higher values of `w_traversal_cost` as more nodes would have to be expanded to lower the cost of the path, to counteract this you may also try setting `w_euc_cost` to a higher value and check if it reduces the query time. +To begin with, you can set the parameters to its default values and then try increasing the value of `w_traversal_cost` to achieve those middling paths, but this would adversely make the paths less taut. So it is recommended that you simultaneously tune the value of `w_euc_cost`. Increasing `w_euc_cost` increases the tautness of the path, which leads to more straight line like paths (any-angled paths). Do note that the query time from the planner would increase for higher values of `w_traversal_cost` as more nodes would have to be expanded to lower the cost of the path, to counteract this you may also try setting `w_euc_cost` to a higher value and check if it reduces the query time. Also note that changes to `w_traversal_cost` might cause slow downs, in case the number of node expanisions increase thus tuning it along with `w_euc_cost` is the way to go to. diff --git a/nav2_velocity_smoother/README.md b/nav2_velocity_smoother/README.md index bdd55277888..6ffbe5d372e 100644 --- a/nav2_velocity_smoother/README.md +++ b/nav2_velocity_smoother/README.md @@ -3,7 +3,7 @@ The ``nav2_velocity_smoother`` is a package containing a lifecycle-component node for smoothing velocities sent by Nav2 to robot controllers. The aim of this package is to implement velocity, acceleration, and deadband smoothing from Nav2 to reduce wear-and-tear on robot motors and hardware controllers by smoothing out the accelerations/jerky movements that might be present with some local trajectory planners' control efforts. -It supports differential drive and omnidirectional robot platforms primarily, but is applicable to ackermann as well with some intepretations of ``Twist``. It was built by [Steve Macenski](https://www.linkedin.com/in/steve-macenski-41a985101/) while at [Samsung Research](https://www.sra.samsung.com/). +It supports differential drive and omnidirectional robot platforms primarily, but is applicable to ackermann as well with some interpretations of ``Twist``. It was built by [Steve Macenski](https://www.linkedin.com/in/steve-macenski-41a985101/) while at [Samsung Research](https://www.sra.samsung.com/). See its [Configuration Guide Page](https://navigation.ros.org/configuration/packages/configuring-velocity-smoother.html) for additional parameter descriptions. @@ -39,7 +39,7 @@ There are two primary operation modes: open and closed loop. In open-loop, the node assumes that the robot was able to achieve the velocity send to it in the last command which was smoothed (which should be a good assumption if acceleration limits are set properly). This is useful when robot odometry is not particularly accurate or has significant latency relative to `smoothing_frequency` so there isn't a delay in the feedback loop. In closed-loop, the node will read from the odometry topic and apply a smoother over it to obtain the robot's current speed. -This will be used to determine the robot's current velocity and therefore achivable velocity targets by the velocity, acceleration, and deadband constraints using live data. +This will be used to determine the robot's current velocity and therefore achievable velocity targets by the velocity, acceleration, and deadband constraints using live data. ## Parameters