Added .pre-commit-config.yaml and codespell_word, fixed spellchecks a…

…ccordingly

Signed-off-by: Chris Schindlbeck <[email protected]>

.codespell_words

@@ -0,0 +1,6 @@
+Configurating
+Segway
+implementors
+priorization
+retuned
+segway

.pre-commit-config.yaml

@@ -0,0 +1,23 @@
+# To use:
+#
+#     pre-commit run -a
+#
+# Or:
+#
+#     pre-commit install  # (runs every time you commit in git)
+#
+# To update this file:
+#
+#     pre-commit autoupdate
+#
+# See https://github.com/pre-commit/pre-commit
+---
+repos:
+  # Spellcheck in comments and docs
+  # skipping of *.svg files is not working...
+  - repo: https://github.com/codespell-project/codespell
+    rev: v2.3.0
+    hooks:
+      - id: codespell
+        args: ['--write-changes', '--ignore-words=.codespell_words']
+        exclude: CHANGELOG\.rst|\.(svg|pyc|drawio|dcf|eds)$

2021summerOfCode/projects/create_configuration_assistant.rst

@@ -7,7 +7,7 @@
 
 **Task description** 
 
-`Moveit <https://moveit.ros.org/>`_ has long has a QT `configuration assistant <http://docs.ros.org/kinetic/api/moveit_tutorials/html/doc/setup_assistant/setup_assistant_tutorial.html>`_. This setup assistent helps the user configure their UDRF and needs to setup MoveIt configuration files.
+`Moveit <https://moveit.ros.org/>`_ has long has a QT `configuration assistant <http://docs.ros.org/kinetic/api/moveit_tutorials/html/doc/setup_assistant/setup_assistant_tutorial.html>`_. This setup assistant helps the user configure their UDRF and needs to setup MoveIt configuration files.
 
 A configuration assistant could be extremely beneficial to Navigation2 users as a way to minimize friction. We should provide a gui tool to cover the following configurations:
 

2021summerOfCode/projects/multithreading.rst

@@ -12,7 +12,7 @@ Some examples include:
 - AMCL particle cloud updates
 - Costmap layer updates
 - Costmap sensor data population
-- Controller critic evalulation
+- Controller critic evaluation
 - Collision checking
 - Voxel grid ray casting
 - and more.

2021summerOfCode/projects/semantics.rst

@@ -18,7 +18,7 @@ After creating the generic representation, your project will be to create demons
 
 **Project output requirements**
 - Generic semantics standard added to Nav2 documentation
-- Generic semantics ROS 2 library that implements the standard and makes it easy for applications to get, retreive, or analyze semantic data for custom purposes
+- Generic semantics ROS 2 library that implements the standard and makes it easy for applications to get, retrieve, or analyze semantic data for custom purposes
 - A route server to enable navigation-graph and/or route following capabilities
 - 1 more demonstration using the semantics library of your choice (could be costmap layer with different rules in different rooms or with different objects, a multi-story building demo using semantic info to allow a robot to plan and execute multi-story trajectories, etc)
 

2021summerOfCode/projects/spinners.rst

@@ -11,7 +11,7 @@ This project is admittedly abstract to explain to someone unfamiliar with the in
 
 ROS 2 architecturally was changed before Foxy in order to ensure that any single process containing multiple ROS 2 node objects will share the same DDS participant on the network. This is important due to the overhead that each additional DDS participant has on the system.
 
-In order for nav2 to leverage this the best, we need to adjust our usage of ROS 2 nodes and executors to further minimize the number of node objects in existance. In the early days of ROS 2 when Nav2 was being built, we were required to have many nodes in a single server in order to handle action requests and other callbacks. Now, we can make use of multi-threaded spinners, callback groups, and individual executors for specific tasks.
+In order for nav2 to leverage this the best, we need to adjust our usage of ROS 2 nodes and executors to further minimize the number of node objects in existence. In the early days of ROS 2 when Nav2 was being built, we were required to have many nodes in a single server in order to handle action requests and other callbacks. Now, we can make use of multi-threaded spinners, callback groups, and individual executors for specific tasks.
 
 This project will involve identifying all of the Node objects in the stack (control+F makes this easy) and work with mentors to ensure by the end of the summer each server contains only a single node. Additionally, the behavior tree plugins should be updated to leverage callback groups to ensure that any single BT node spinning to check if any new messages are on its callback will **only** trigger its own callback by the same mechanisms.
 

configuration/packages/bt-plugins/actions/AssistedTeleop.rst

@@ -33,7 +33,7 @@ Input Ports
   ====== =======
 
   Description
-      Time to envoke behavior for, if exceeds considers it a stuck condition or failure case (seconds).
+      Time to invoke behavior for, if exceeds considers it a stuck condition or failure case (seconds).
 
 :server_name:
 

configuration/packages/bt-plugins/actions/BackUp.rst

@@ -43,7 +43,7 @@ Input Ports
   ====== =======
 
   Description
-      Time to envoke behavior for, if exceeds considers it a stuck condition or failure case (seconds).
+      Time to invoke behavior for, if exceeds considers it a stuck condition or failure case (seconds).
 
 :server_name:
 

configuration/packages/bt-plugins/actions/DriveOnHeading.rst

@@ -42,7 +42,7 @@ Input Ports
   ====== =======
 
   Description
-      Time to envoke behavior for, if exceeds considers it a stuck condition or failure case (seconds).
+      Time to invoke behavior for, if exceeds considers it a stuck condition or failure case (seconds).
 
 :server_name:
 

configuration/packages/bt-plugins/actions/Spin.rst

@@ -32,7 +32,7 @@ Input Ports
   ====== =======
 
   Description
-      Time to envoke behavior for, if exceeds considers it a stuck condition or failure case (seconds).
+      Time to invoke behavior for, if exceeds considers it a stuck condition or failure case (seconds).
 
 :server_name:
 

configuration/packages/bt-plugins/actions/TruncatePath.rst

@@ -30,8 +30,8 @@ Input Ports
   Description
     	The distance to the original goal for truncating the path.
 
-Ouput Ports
------------
+Output Ports
+------------
 
 :output_path:
 

configuration/packages/bt-plugins/actions/TruncatePathLocal.rst

@@ -96,8 +96,8 @@ Input Ports
   Description
     	Maximum forward integrated distance along the path (starting from the last detected pose) to bound the search for the closest pose to the robot. When set to infinity (default), whole path is searched every time.
 
-Ouput Ports
------------
+Output Ports
+------------
 
 :output_path:
 

configuration/packages/bt-plugins/controls/RoundRobin.rst

@@ -4,7 +4,7 @@
 RoundRobin
 ==========
 
-Custom control flow node used to create a round-robbin behavior for children BT nodes.
+Custom control flow node used to create a round-robin behavior for children BT nodes.
 
 Example
 -------

configuration/packages/collision_monitor/configuring-collision-detector-node.rst

@@ -75,7 +75,7 @@ Parameters
   ============== =============================
 
   Description:
-    Maximum time interval in which source data is considered as valid. If no new data is received within this interval, an additional warning will be displayed. Setting ``source_timeout: 0.0`` disables it. This parameter can be overriden per observation source.
+    Maximum time interval in which source data is considered as valid. If no new data is received within this interval, an additional warning will be displayed. Setting ``source_timeout: 0.0`` disables it. This parameter can be overridden per observation source.
 
 :base_shift_correction:
 
@@ -136,7 +136,7 @@ Polygons parameters
   ============== =============================
 
   Description:
-    Polygon vertexes, listed in ``"[[p1.x, p1.y], [p2.x, p2.y], [p3.x, p3.y], ...]"`` format (e.g. ``"[[0.5, 0.25], [0.5, -0.25], [0.0, -0.25], [0.0, 0.25]]"`` for the square in the front). Used for ``polygon`` type. Minimum 3 points for a triangle polygon. If not specified, the collision detector will use dynamic polygon subscription to ``polygon_sub_topic``
+    Polygon vertices, listed in ``"[[p1.x, p1.y], [p2.x, p2.y], [p3.x, p3.y], ...]"`` format (e.g. ``"[[0.5, 0.25], [0.5, -0.25], [0.0, -0.25], [0.0, 0.25]]"`` for the square in the front). Used for ``polygon`` type. Minimum 3 points for a triangle polygon. If not specified, the collision detector will use dynamic polygon subscription to ``polygon_sub_topic``
 
 :``<polygon_name>``.polygon_sub_topic:
 

configuration/packages/collision_monitor/configuring-collision-monitor-node.rst

@@ -137,7 +137,7 @@ Parameters
   ============== =============================
 
   Description:
-    Maximum time interval in which source data is considered as valid. If no new data is received within this interval, the robot will be stopped. Setting ``source_timeout: 0.0`` disables this blocking mechanism. This parameter can be overriden per observation source.
+    Maximum time interval in which source data is considered as valid. If no new data is received within this interval, the robot will be stopped. Setting ``source_timeout: 0.0`` disables this blocking mechanism. This parameter can be overridden per observation source.
 
 :base_shift_correction:
 
@@ -232,7 +232,7 @@ Polygons parameters
   ============== =============================
 
   Description:
-    Polygon vertexes, listed in ``"[[p1.x, p1.y], [p2.x, p2.y], [p3.x, p3.y], ...]"`` format (e.g. ``"[[0.5, 0.25], [0.5, -0.25], [0.0, -0.25], [0.0, 0.25]]"`` for the square in the front). Used for ``polygon`` type. Minimum 3 points for a triangle polygon. If not specified, the collision monitor will use dynamic polygon subscription to ``polygon_sub_topic`` for points in the ``stop``/``slowdown``/``limit`` action types, or footprint subscriber to ``footprint_topic`` for ``approach`` action type.
+    Polygon vertices, listed in ``"[[p1.x, p1.y], [p2.x, p2.y], [p3.x, p3.y], ...]"`` format (e.g. ``"[[0.5, 0.25], [0.5, -0.25], [0.0, -0.25], [0.0, 0.25]]"`` for the square in the front). Used for ``polygon`` type. Minimum 3 points for a triangle polygon. If not specified, the collision monitor will use dynamic polygon subscription to ``polygon_sub_topic`` for points in the ``stop``/``slowdown``/``limit`` action types, or footprint subscriber to ``footprint_topic`` for ``approach`` action type.
 
 :``<polygon_name>``.polygon_sub_topic:
 
@@ -424,7 +424,7 @@ All previous Polygon parameters apply, in addition to the following unique param
   ============== =============================
 
   Description:
-    Polygon vertexes, listed in ``"[[p1.x, p1.y], [p2.x, p2.y], [p3.x, p3.y], ...]"`` format (e.g. ``"[[0.5, 0.25], [0.5, -0.25], [0.0, -0.25], [0.0, 0.25]]"`` for the square in the front). Used for ``polygon`` type. Minimum 3 points for a triangle polygon. Causes an error, if not specified.
+    Polygon vertices, listed in ``"[[p1.x, p1.y], [p2.x, p2.y], [p3.x, p3.y], ...]"`` format (e.g. ``"[[0.5, 0.25], [0.5, -0.25], [0.0, -0.25], [0.0, 0.25]]"`` for the square in the front). Used for ``polygon`` type. Minimum 3 points for a triangle polygon. Causes an error, if not specified.
 
 :``<vel_poly>.<subpoly>``.linear_min:
 

configuration/packages/configuring-amcl.rst

@@ -98,7 +98,7 @@ Parameters
   ============== =============================
 
   Description
-    Percentage of beams after not matching map to force full update due to bad convergance.
+    Percentage of beams after not matching map to force full update due to bad convergence.
 
 :beam_skip_threshold:
 

configuration/packages/configuring-coverage-server.rst

@@ -180,7 +180,7 @@ Parameters
   ============== ========
 
   Description
-    The default custom swath order for the route planner in the ``CUSTOM`` mode. The length of this custom order must be ``>= swaths.size()``. Only relevent when using the ``CUSTOM`` Route Type.
+    The default custom swath order for the route planner in the ``CUSTOM`` mode. The length of this custom order must be ``>= swaths.size()``. Only relevant when using the ``CUSTOM`` Route Type.
 
 :default_spiral_n:
 
@@ -191,7 +191,7 @@ Parameters
   ============== ===============
 
   Description
-    Default number of swaths to skip and double back on to create a spiral pattern in the route. Only relevent when usign the ``SPIRAL`` Route Type. ``SNAKE`` is a special case when Spiral N = 2.
+    Default number of swaths to skip and double back on to create a spiral pattern in the route. Only relevant when using the ``SPIRAL`` Route Type. ``SNAKE`` is a special case when Spiral N = 2.
 
 
 :default_path_continuity_type:

configuration/packages/configuring-docking-server.rst

@@ -37,7 +37,7 @@ Parameters
   ============== ==============
 
   Description
-    Timeout (s) to wait to obtain intial perception of the dock.
+    Timeout (s) to wait to obtain initial perception of the dock.
 
 :wait_charge_timeout:
 

configuration/packages/configuring-lifecycle.rst

@@ -8,7 +8,7 @@ Source code on Github_.
 .. _Github: https://github.com/ros-planning/navigation2/tree/main/nav2_lifecycle_manager
 
 The Lifecycle Manager module implements the method for handling the lifecycle transition states for the stack in a deterministic way.
-It will take in a set of ordered nodes to transition one-by-one into the configurating and activate states to run the stack.
+It will take in a set of ordered nodes to transition one-by-one into the configuration and activate states to run the stack.
 It will then bring down the stack into the finalized state in the opposite order.
 It will also create bond connections with the servers to ensure they are still up and transition down all nodes if any are non-responsive or crashed.
 

configuration/packages/configuring-map-server.rst

@@ -44,7 +44,7 @@ Map Saver Parameters
   ============== =============================
 
   Description
-    Occupied space minimum probability threshhold value for occupancy grid.
+    Occupied space minimum probability threshold value for occupancy grid.
 
 Map Server Parameters
 *********************

configuration/packages/configuring-mppic.rst

@@ -248,7 +248,7 @@ MPPI Parameters
   ============== ===========================
 
   Description
-    Whether to publish debuggin trajectories for visualization. This can slow down the controller substantially (e.g. 1000 batches of 56 size every 30hz is alot of data).
+    Whether to publish debugging trajectories for visualization. This can slow down the controller substantially (e.g. 1000 batches of 56 size every 30hz is a lot of data).
 
 :retry_attempt_limit:
 
@@ -1131,7 +1131,7 @@ General Words of Wisdom
 
 The ``model_dt`` parameter generally should be set to the duration of your control frequency. So if your control frequency is 20hz, this should be ``0.05``. However, you may also set it lower **but not larger**.
 
-Visualization of the trajectories using ``visualize`` uses compute resources to back out trajectories for visualization and therefore slows compute time. It is not suggested that this parameter is set to ``true`` during a deployed use, but is a useful debug instrument while tuning the system, but use sparingly. Visualizing 2000 batches @ 56 points at 30 hz is *alot*.
+Visualization of the trajectories using ``visualize`` uses compute resources to back out trajectories for visualization and therefore slows compute time. It is not suggested that this parameter is set to ``true`` during a deployed use, but is a useful debug instrument while tuning the system, but use sparingly. Visualizing 2000 batches @ 56 points at 30 hz is *a lot*.
 
 The most common parameters you might want to start off changing are the velocity profiles (``vx_max``, ``vx_min``, ``wz_max``, and ``vy_max`` if holonomic) and the ``motion_model`` to correspond to your vehicle. Its wise to consider the ``prune_distance`` of the path plan in proportion to your maximum velocity and prediction horizon. The only deeper parameter that will likely need to be adjusted for your particular settings is the Obstacle critics' ``repulsion_weight`` since the tuning of this is proprtional to your inflation layer's radius. Higher radii should correspond to reduced ``repulsion_weight`` due to the penalty formation (e.g. ``inflation_radius - min_dist_to_obstacle``). If this penalty is too high, the robot will slow significantly when entering cost-space from non-cost space or jitter in narrow corridors. It is noteworthy, but likely not necessary to be changed, that the Obstacle critic may use the full footprint information if ``consider_footprint = true``, though comes at an increased compute cost.
 

configuration/packages/nav2_waypoint_follower-plugins/photo_at_waypoint.rst

@@ -33,7 +33,7 @@ Parameters
   ============== =============================
 
   Description
-     Camera image topic name to susbcribe
+     Camera image topic name to subscribe
 
 :``<nav2_waypoint_follower plugin>``.save_images_dir:
 

configuration/packages/smac/configuring-smac-hybrid.rst

@@ -266,7 +266,7 @@ Parameters
   ====== =======
 
   Description
-    Advanced feature: Cache the obstacle map dynamic programming distance expansion heuristic between subsiquent replannings of the same goal location. Dramatically speeds up replanning performance (40x) if costmap is largely static.
+    Advanced feature: Cache the obstacle map dynamic programming distance expansion heuristic between subsequent replannings of the same goal location. Dramatically speeds up replanning performance (40x) if costmap is largely static.
 
 :``<name>``.allow_primitive_interpolation:
 
@@ -288,7 +288,7 @@ Parameters
   ====== =======
 
   Description
-    Advanced feature: This allows a user to disable downsampling of the obstacle heuristic's costmap representation to search at the costmap's full-resolution. This will come at increased up-front costs while searching for the 2D approximate route to the goal in exchange for less search iterations and a slightly more smooth path. With ``smooth_path`` on, this increased smoothness is noticable but not massively different. When combined with all of the advanced features however, it can contribute to a better overall plan in exchange for some compute time. This scales with map size and complexity of the path plan requested. For simpler maps / paths, this may actually improve performance due to low up-front search times and lower iterations.
+    Advanced feature: This allows a user to disable downsampling of the obstacle heuristic's costmap representation to search at the costmap's full-resolution. This will come at increased up-front costs while searching for the 2D approximate route to the goal in exchange for less search iterations and a slightly more smooth path. With ``smooth_path`` on, this increased smoothness is noticeable but not massively different. When combined with all of the advanced features however, it can contribute to a better overall plan in exchange for some compute time. This scales with map size and complexity of the path plan requested. For simpler maps / paths, this may actually improve performance due to low up-front search times and lower iterations.
 
 :``<name>``.use_quadratic_cost_penalty:
 
@@ -409,7 +409,7 @@ Example
         cost_penalty: 2.0                   # Penalty to apply to higher cost areas when adding into the obstacle map dynamic programming distance expansion heuristic. This drives the robot more towards the center of passages. A value between 1.3 - 3.5 is reasonable.
         retrospective_penalty: 0.015
         lookup_table_size: 20.0             # Size of the dubin/reeds-sheep distance window to cache, in meters.
-        cache_obstacle_heuristic: false     # Cache the obstacle map dynamic programming distance expansion heuristic between subsiquent replannings of the same goal location. Dramatically speeds up replanning performance (40x) if costmap is largely static.   
+        cache_obstacle_heuristic: false     # Cache the obstacle map dynamic programming distance expansion heuristic between subsequent replannings of the same goal location. Dramatically speeds up replanning performance (40x) if costmap is largely static.   
         debug_visualizations: false         # For Hybrid nodes: Whether to publish expansions on the /expansions topic as an array of poses (the orientation has no meaning) and the path's footprints on the /planned_footprints topic. WARNING: heavy to compute and to display, for debug only as it degrades the performance.
         use_quadratic_cost_penalty: False
         downsample_obstacle_heuristic: True