Typos, README instruction and ROS 2 conventions (ros-navigation#193)

* Fix small typo

Signed-off-by: Víctor Mayoral Vilches <[email protected]>

* breathe needs to be more recent than 4.12.0 for static builds

Tested in OS X, breathe 4.12.0 led to issues with
sphinx.ext.mathbase, updated to 4.30.0

Signed-off-by: Víctor Mayoral Vilches <[email protected]>

* Fix ROS2 for ROS 2

Signed-off-by: Víctor Mayoral Vilches <[email protected]>

* Use ROS instead of ROS1

Signed-off-by: Víctor Mayoral Vilches <[email protected]>

* Update concepts/index.rst, undo URL modification

* Undo filename modification

* Undo unnecessary URL modification

* Correct the alignment on the tables after ROS 2 fixes

Signed-off-by: Víctor Mayoral Vilches <[email protected]>

* Undo ROS1 modifications

Signed-off-by: Víctor Mayoral Vilches <[email protected]>

* Update breathe version in CI, match OS X-valid version

Versions prior to 4.30.0 of breathe python3 library led to
errors while building the static web content in OS X. This
patch matches f71f698 to
bring consistency in both instructions and CI runs.

Signed-off-by: Víctor Mayoral Vilches <[email protected]>

* Revert breathe changes, both CI and README to 4.12.0

* Breathe back to 4.9.1

Signed-off-by: Víctor Mayoral Vilches <[email protected]>

2021summerOfCode/projects/safety_node.rst

@@ -25,7 +25,7 @@ This will be an excellent chance to make mobile robots and Nav2 users significan
 **Mentor contact details: [See link above, link in GitHub profile description]**
 
 **Project output requirements**
-- Creation of a ROS2 node that will prevent robot collision based on lidar and/or RGBD data
+- Creation of a ROS 2 node that will prevent robot collision based on lidar and/or RGBD data
 - Node should be able to run at lidar data speed (40hz+) and adjust velocity commands accordingly
 - If time allots, work on tuning / adding new critics to the DWB local planner to improve safety of its performance for users out of the box
 

2021summerOfCode/projects/semantics.rst

@@ -18,13 +18,13 @@ After creating the generic representation, your project will be to create demons
 
 **Project output requirements**
 - Generic semantics standard added to Nav2 documentation
-- Generic semsntics ROS2 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, retreive, 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)
 
 **Skills required**
 
-- C++, Python, ROS2
+- C++, Python, ROS 2
 - Mobile robot navigation or manipulation experience
 - Perception, semantic information motivation, or similar.
 - Recommended: Gazebo simulation, ROS navigation

2021summerOfCode/projects/spinners.rst

@@ -2,20 +2,20 @@
 .. _spinners:
 
 
-7. Reduce ROS2 Nodes and Determinism
+7. Reduce ROS 2 Nodes and Determinism
 ====================================
 
 **Task description** 
 
-This project is admittedly abstract to explain to someone unfamiliar with the inner-details of ROS2 and its layers. If you're interested in working on this, you will become one of the few that truly understand the inner workings of it and be a very marketable skill. We do not expect anyone applying for this project to have that knowledge beforehand and we will help you learn the necessary items.
+This project is admittedly abstract to explain to someone unfamiliar with the inner-details of ROS 2 and its layers. If you're interested in working on this, you will become one of the few that truly understand the inner workings of it and be a very marketable skill. We do not expect anyone applying for this project to have that knowledge beforehand and we will help you learn the necessary items.
 
-ROS2 architecturally was changed before Foxy in order to ensure that any single process containing multiple ROS2 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.
+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 ROS2 nodes and executors to further minimize the number of node objects in existance. In the early days of ROS2 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 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.
 
 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.
 
-More details about this project can be supplied if interested, but the tickets linked below also provide more context. Trust me to say this is a very achievable goal over the course of the summer and will also let you look under the hood of both Nav2 and rclcpp, giving you valuable insight future in your career (and put you in the top 10% of ROS2 developers that know it to this degree).
+More details about this project can be supplied if interested, but the tickets linked below also provide more context. Trust me to say this is a very achievable goal over the course of the summer and will also let you look under the hood of both Nav2 and rclcpp, giving you valuable insight future in your career (and put you in the top 10% of ROS 2 developers that know it to this degree).
 
 **Project difficulty: Medium**
 
@@ -24,7 +24,7 @@ More details about this project can be supplied if interested, but the tickets l
 **Mentor contact details: [See link above, link in GitHub profile description]**
 
 **Project output requirements**
-- Remove excess ROS2 nodes from stack and replace with executors and multi-threaded executors
+- Remove excess ROS 2 nodes from stack and replace with executors and multi-threaded executors
 - Replace Behavior Tree node spinners with local executors to ensure deterministic execution & processing only callback groups of the current BT node
 - If time allots, create a single ``main()`` function Nav2 executable composing all Nav2 processes and benchmarking improvements in performance
 

2021summerOfCode/projects/twist_n_config.rst

@@ -11,14 +11,14 @@ This project is comprised of 2 smaller projects that can be easily worked on in
 
 Subproject A: Convert Twist to TwistStamped in Ecosystem
 
-The aim of this project is to identify places in the ROS2 ecosystem that make use of ``Twist`` in the context of ``cmd_vel`` coming out of Navigation. This includes things like Nav2, ROS2 Control, Gazebo ROS Plugins, Yuk's Velocity Filter, major robot drivers, etc. A set of previously identified places is shown in the ticket linked below.
+The aim of this project is to identify places in the ROS 2 ecosystem that make use of ``Twist`` in the context of ``cmd_vel`` coming out of Navigation. This includes things like Nav2, ROS 2 Control, Gazebo ROS Plugins, Yuk's Velocity Filter, major robot drivers, etc. A set of previously identified places is shown in the ticket linked below.
 
-Once you've created a list of places in the ecosystem where it is used, your project will be to submit PRs on their ROS2 branches to change the interface to make use of a ``TwistStamped`` instead of a ``Twist``.
+Once you've created a list of places in the ecosystem where it is used, your project will be to submit PRs on their ROS 2 branches to change the interface to make use of a ``TwistStamped`` instead of a ``Twist``.
 
 
 Subproject B: Run-time Reconfiguration of Parameters
 
-In the meantime while you're waiting for PRs to be merged or blocked by reviews on converting all of the ecosystems ``cmd_vel`` use of ``Twist`` to ``TwistStamped``, your project will be to enable run-time reconfiguration of the major parameters in Nav2. In ROS2 this is done via the parameter change event callbacks. See tickets below for a list of plugins or servers needing dynamically reconfigurable parameter support added. 
+In the meantime while you're waiting for PRs to be merged or blocked by reviews on converting all of the ecosystems ``cmd_vel`` use of ``Twist`` to ``TwistStamped``, your project will be to enable run-time reconfiguration of the major parameters in Nav2. In ROS 2 this is done via the parameter change event callbacks. See tickets below for a list of plugins or servers needing dynamically reconfigurable parameter support added. 
 
 
 **Project difficulty: Medium**
@@ -35,7 +35,7 @@ In the meantime while you're waiting for PRs to be merged or blocked by reviews
 **Skills required**
 
 - C++, Python3
-- ROS2
+- ROS 2
 
 **List of relevant open source software repositories and refs** 
 

README.md

@@ -7,7 +7,7 @@ This folder holds the source and configuration files used to generate the
 Dependencies for Build: 
 * [Sphinx](https://www.sphinx-doc.org/en/master/usage/installation.html)
 * `sudo apt install python3-pip`
-* `pip3 install breathe==4.12.0 sphinx_rtd_theme sphinxcontrib-plantuml`
+* `pip3 install breathe==4.9.1 sphinx_rtd_theme sphinxcontrib-plantuml`
 
 Build the docs locally with `make html` and you'll find the built docs entry point in `_build/html/index.html`.
 

about/related_projects.rst

@@ -8,7 +8,7 @@ This is a community maintained list of related repositories and projects to Navi
 +--------------------------------+------------------------+----------------------------------+
 |                   Name         |         Maintainer     |       Description                |
 +================================+========================+==================================+
-| `Navigation2`_                 | Steve Macenski         | Main ROS2 Navigation Stack       |
+| `Navigation2`_                 | Steve Macenski         | Main ROS 2 Navigation Stack      |
 +--------------------------------+------------------------+----------------------------------+
 | `navigation.ros.org`_          | Steve Macenski         | Official documentation website   |
 |                                |                        | source code                      |
@@ -18,10 +18,10 @@ This is a community maintained list of related repositories and projects to Navi
 +--------------------------------+------------------------+----------------------------------+
 | `navigation2_dynamic`_         | Steve Macenski         | Tools, algorithms, and           |
 |                                |                        | capabilities for working with    |
-|                                |                        | dynamic obstacles in ROS2        |
+|                                |                        | dynamic obstacles in ROS 2       |
 +--------------------------------+------------------------+----------------------------------+
 |  `robot_localization`_         | Tom Moore              | State estimation software for    |
-|                                |                        | ROS2 used for odometry fusion    |
+|                                |                        | ROS 2 used for odometry fusion   |
 |                                |                        | and GPS transformations          |
 +--------------------------------+------------------------+----------------------------------+
 | `slam_toolbox`_                |  Steve Macenski        | Default 2D SLAM library          |

commander_api/index.rst

@@ -6,7 +6,7 @@ Simple Commander API
 Overview
 ********
 
-The goal of the Nav2 Simple (Python3) Commander is to provide a "navigation as a library" capability to Python3 users. We provide an API that handles all the ROS2 and Action Server tasks for you such that you can focus on building an application leveraging the capabilities of Nav2 (after you've configured it to your liking with your plugins of choice). `We also provide you with demos and examples of API usage <https://github.com/ros-planning/navigation2/tree/main/nav2_simple_commander>`_ to build common basic capabilities in autonomous mobile robotics in the ``nav2_simple_commander`` package.
+The goal of the Nav2 Simple (Python3) Commander is to provide a "navigation as a library" capability to Python3 users. We provide an API that handles all the ROS 2 and Action Server tasks for you such that you can focus on building an application leveraging the capabilities of Nav2 (after you've configured it to your liking with your plugins of choice). `We also provide you with demos and examples of API usage <https://github.com/ros-planning/navigation2/tree/main/nav2_simple_commander>`_ to build common basic capabilities in autonomous mobile robotics in the ``nav2_simple_commander`` package.
 
 A simple demonstration is shown below. Note: ``goToPose()``, ``goThroughPoses()``, ``followWaypoints()`` and similar are **non-blocking** such that you can receive and process feedback in a single-threaded application. As such while waiting for a task to be completed, the ``while not nav.isNavComplete()`` design is necessary to poll for changes in the navigation completion, and if not complete some tasks of interest to your application (like processing feedback, doing something with the data the robot is collecting, or checking for faults).
 

migration/Galactic.rst

@@ -38,7 +38,7 @@ The tl;dr of these improvements is:
 Simple (Python) Commander
 *************************
 
-`This PR <https://github.com/ros-planning/navigation2/pull/2411>`_ introduces a new package to Nav2, called the ``nav2_simple_commander``. It is a set of functions in an object, ``BasicNavigator``, which can be used to build Nav2-powered autonomy tasks in Python3 without concerning yourself with the Nav2, ROS2, or Action server details. It contains a simple API taking common types (primarily ``PoseStamped``) and handles all of the implementation details behind the hood. For example, this is a simple navigation task using this API:
+`This PR <https://github.com/ros-planning/navigation2/pull/2411>`_ introduces a new package to Nav2, called the ``nav2_simple_commander``. It is a set of functions in an object, ``BasicNavigator``, which can be used to build Nav2-powered autonomy tasks in Python3 without concerning yourself with the Nav2, ROS 2, or Action server details. It contains a simple API taking common types (primarily ``PoseStamped``) and handles all of the implementation details behind the hood. For example, this is a simple navigation task using this API:
 
 .. code-block:: python3
 
@@ -81,7 +81,7 @@ Simple (Python) Commander
 Reduce Nodes and Executors
 **************************
 
-In order for nav2 to make the best use of ROS2, we need minimize the number of nodes and executors in nav2, which can improve performance. 
+In order for nav2 to make the best use of ROS 2, we need minimize the number of nodes and executors in nav2, which can improve performance. 
 
 This functionality has been discussed in `the ticket #816 <https://github.com/ros-planning/navigation2/issues/816>`_, and carried out in
 

plugin_tutorials/docs/writing_new_nav2controller_plugin.rst

@@ -27,7 +27,7 @@ You can find the source code matching this tutorial `here <https://github.com/ro
 Requirements
 ============
 
-- ROS2 (binary or build-from-source)
+- ROS 2 (binary or build-from-source)
 - Nav2 (Including dependencies)
 - Gazebo
 - Turtlebot3
@@ -189,7 +189,7 @@ The remaining methods are not used, but it's mandatory to override them. As per
 ----------------------------------
 
 Now that we have created our custom controller, we need to export our controller plugin so that it would be visible to the controller server. 
-Plugins are loaded at runtime, and if they are not visible, then our controller server won't be able to load it. In ROS2, exporting and loading 
+Plugins are loaded at runtime, and if they are not visible, then our controller server won't be able to load it. In ROS 2, exporting and loading 
 plugins is handled by ``pluginlib``.
 
 Coming to our tutorial, class ``nav2_pure_pursuit_controller::PurePursuitController`` is loaded dynamically as ``nav2_core::Controller`` which is our base class.

setup_guides/odom/setup_odom.rst

@@ -43,7 +43,7 @@ Setting Up Odometry on your Robot
 
 Setting up the odometry system for Nav2 for your physical robot depends a lot on which odometry sensors are available with your robot. Due to the large number of configurations your robot may have, specific setup instructions will not be within the scope of this tutorial. Instead, we will provide some basic examples and useful resources to help you configure your robot for Nav2.
 
-To start, we will use an example of a robot with wheel encoders as its odometry source. Note that wheel encoders are not required for Nav2 but it is common in most setups. The goal in setting up the odometry is to compute the odometry information and publish the ``nav_msgs/Odometry`` message and ``odom`` => ``base_link`` transform over ROS2. To calculate this information, you will need to setup some code that will translate wheel encoder information into odometry information, similar to the snippet below:
+To start, we will use an example of a robot with wheel encoders as its odometry source. Note that wheel encoders are not required for Nav2 but it is common in most setups. The goal in setting up the odometry is to compute the odometry information and publish the ``nav_msgs/Odometry`` message and ``odom`` => ``base_link`` transform over ROS 2. To calculate this information, you will need to setup some code that will translate wheel encoder information into odometry information, similar to the snippet below:
 
 .. code-block:: shell