diff --git a/.circleci/config.yml b/.circleci/config.yml index c3b33c3419..549f3d3945 100644 --- a/.circleci/config.yml +++ b/.circleci/config.yml @@ -68,7 +68,7 @@ jobs: - persist_to_workspace: root: . paths: - - _build + - _build docs_publish: executor: docs_exec steps: diff --git a/.gitignore b/.gitignore index 538d88f88e..efce211b1b 100644 --- a/.gitignore +++ b/.gitignore @@ -2,4 +2,4 @@ _build lib/ bin/ pyvenv.cfg -.DS_Store \ No newline at end of file +.DS_Store diff --git a/.pre-commit-config.yaml b/.pre-commit-config.yaml index 0e044ae207..ca3131ec72 100644 --- a/.pre-commit-config.yaml +++ b/.pre-commit-config.yaml @@ -21,3 +21,10 @@ repos: - id: codespell args: ['--write-changes', '--ignore-words=.codespell_words'] exclude: CHANGELOG\.rst|\.(svg|pyc|drawio|dcf|eds)$ + + - repo: https://github.com/pre-commit/pre-commit-hooks + rev: v5.0.0 + hooks: + - id: end-of-file-fixer + - id: mixed-line-ending + - id: trailing-whitespace diff --git a/2021summerOfCode/projects/assisted_teleop.rst b/2021summerOfCode/projects/assisted_teleop.rst index 39ff5f2bf9..1d034e512d 100644 --- a/2021summerOfCode/projects/assisted_teleop.rst +++ b/2021summerOfCode/projects/assisted_teleop.rst @@ -4,9 +4,9 @@ 3. Assisted Teleop ================== -**Task description** +**Task description** -In mobile robot and autonomous vehicle navigation, there are situations where a human driver is required to intervene to get the vehicle out of a sticky situation. This can be both as a backup in case of autonomy failure as well as the primary function of the robot (e.g. telepresence robots). +In mobile robot and autonomous vehicle navigation, there are situations where a human driver is required to intervene to get the vehicle out of a sticky situation. This can be both as a backup in case of autonomy failure as well as the primary function of the robot (e.g. telepresence robots). This project's aim is to create an assisted teleop feature in Nav2 by means of a new behavior tree configuration file (the file that defines the flow of information for the navigation task) and potentially new plugins. This feature should make sure to use the local costmap and/or sensor data in order to avoid obstacles and take position and/or velocity commands to attempt to follow. @@ -31,7 +31,7 @@ This will be an excellent chance to make a substantial new feature in the Nav2 s - Mobile robot navigation experience - Recommended: Gazebo simulation, ROS navigation, Behavior trees -**List of relevant open source software repositories and refs** +**List of relevant open source software repositories and refs** - `ROS `_ - `Gazebo Simulator `_ diff --git a/2021summerOfCode/projects/create_configuration_assistant.rst b/2021summerOfCode/projects/create_configuration_assistant.rst index a0a04f84f1..3f019d7445 100644 --- a/2021summerOfCode/projects/create_configuration_assistant.rst +++ b/2021summerOfCode/projects/create_configuration_assistant.rst @@ -5,7 +5,7 @@ 1. Create a Configuration Assistant (Analog to MoveIt) ====================================================== -**Task description** +**Task description** `Moveit `_ has long has a QT `configuration assistant `_. This setup assistant helps the user configure their UDRF and needs to setup MoveIt configuration files. @@ -43,7 +43,7 @@ After the items are configured, there should be a preview to see how the paramet - 3D programming (maybe needed in the preview) - Recommended: Gazebo simulation, ROS, and Navigation experience -**List of relevant open source software repositories and refs** +**List of relevant open source software repositories and refs** - `QT `_ - `Gazebo Simulator `_ @@ -51,4 +51,4 @@ After the items are configured, there should be a preview to see how the paramet **Licensing** - All contributions will be under the Apache 2.0 license. -- No other CLA's are required. \ No newline at end of file +- No other CLA's are required. diff --git a/2021summerOfCode/projects/create_plugins.rst b/2021summerOfCode/projects/create_plugins.rst index 6654526349..9f82f921c3 100644 --- a/2021summerOfCode/projects/create_plugins.rst +++ b/2021summerOfCode/projects/create_plugins.rst @@ -46,4 +46,3 @@ Your task will be to create a high-quality implementation of one of the followin **Licensing** - All contributions will be under the Apache 2.0 license. - No other CLA's are required. - diff --git a/2021summerOfCode/projects/dynamic.rst b/2021summerOfCode/projects/dynamic.rst index 710dcb1ccd..236d2bbda3 100644 --- a/2021summerOfCode/projects/dynamic.rst +++ b/2021summerOfCode/projects/dynamic.rst @@ -5,7 +5,7 @@ 1. Navigation Dynamic Obstacle Integration ========================================== -**Task description** +**Task description** The Navigation Stack has long provided robust navigation in a wide range of environments. Controllers have been developed to operate effectively in the presence of dynamic obstacles without explicitly modeling the characteristics of dynamic obstacles. However, as the field has progressed and we see more and more robots using ROS deployed in human-filled spaces, more consideration must be taken with respect to dynamic obstacles such as people, carts, animals, and vehicles. @@ -33,7 +33,7 @@ If time permits, you may also work to also integrate this dynamic information in - Geometry and statistics - Recommended: Gazebo simulation, machine learning, ROS navigation -**List of relevant open source software repositories and refs** +**List of relevant open source software repositories and refs** - `Starting project `_ - `ROS `_ diff --git a/2021summerOfCode/projects/grid_maps.rst b/2021summerOfCode/projects/grid_maps.rst index d74baf0750..489716c729 100644 --- a/2021summerOfCode/projects/grid_maps.rst +++ b/2021summerOfCode/projects/grid_maps.rst @@ -8,7 +8,7 @@ 3. Port Grid Maps to ROS 2 and Environmental Model ================================================== -**Task description** +**Task description** Grid Maps was created by ETH Zurich and later transferred to ANYbotics. It is a universal grid map library for mobile robotic mapping that can be used as the basis of environmental models and various forms of grid maps available in ROS 1. This library is one of the top downloaded ROS packages. Your task will be to work with the community and the mentor to port grid_maps metapackage from ROS 1 to ROS 2 and help develop the next generation environment model in ROS 2 to replace costmap_2d. This will involve porting code from ROS 1 to ROS 2, analyzing uses of the environmental model to define an abstract interface to allow replacement of costmap_2d with grid_map, and building up the basic grid-operations for costmaps. It is not expected to complete the full new model with sensor processing over the course of the summer. If completed early, you may be able to help design a gradient model to complement your implemented costmap model using grid_maps. This will allow robots to select a gradient or a costmap model on startup. @@ -33,7 +33,7 @@ This will involve porting code from ROS 1 to ROS 2, analyzing uses of the enviro - Coordinate transformations and basic geometry - Recommended: Gazebo simulation and Navigation experience -**List of relevant open source software repositories and refs** +**List of relevant open source software repositories and refs** - `ROS `_ - `Gazebo Simulator `_ @@ -44,4 +44,3 @@ This will involve porting code from ROS 1 to ROS 2, analyzing uses of the enviro **Licensing** - All contributions will be under the Apache 2.0 license. - No other CLA's are required. - diff --git a/2021summerOfCode/projects/localization.rst b/2021summerOfCode/projects/localization.rst index cf5e9b117e..3b0a836df7 100644 --- a/2021summerOfCode/projects/localization.rst +++ b/2021summerOfCode/projects/localization.rst @@ -6,16 +6,16 @@ 6. 2D/3D Localization Improvements ================================== -**Task description** +**Task description** -The Navigation2 stack uses AMCL as its primary localization engine. Over the last 10 years, essentially no updates to AMCL has been made. This is due to the code base for this implementation of an Adaptive Monte Carlo Localizer is written in embedded C, not well structured, and very sensitive to changes. A-MCL implementations have been a hallmark of localization for over a decade but this particular implementation should be deprecated. +The Navigation2 stack uses AMCL as its primary localization engine. Over the last 10 years, essentially no updates to AMCL has been made. This is due to the code base for this implementation of an Adaptive Monte Carlo Localizer is written in embedded C, not well structured, and very sensitive to changes. A-MCL implementations have been a hallmark of localization for over a decade but this particular implementation should be deprecated. Your target involves designing and creating a new localization engine for the Nav2 stack. The requirements of this are: - Support 2D laser scanners - Support 3D laser scanners, where 2D case could potentially be a simplified case - Accurately track the localization of a robot in a given occupancy grid -The reason that specific method is left open-ended is to allow for creativity, novelty, or reimplementation of a what you feel is best. We have, however, analyzed other MCL variants as being good options. This may include reimplementing an A-MCL that is designed to be modified with modular components and support sampling from a 3D lidar. Another option is a NDT-MCL using NDT 2D/3D scan matching. Other options may be proposed and discussed with mentors during the application phase. The task involves 3D as well since there is no standard 3D localizer in ROS 2 yet and more and more robust 3D SLAM libraries have emerged over the last 2 years. +The reason that specific method is left open-ended is to allow for creativity, novelty, or reimplementation of a what you feel is best. We have, however, analyzed other MCL variants as being good options. This may include reimplementing an A-MCL that is designed to be modified with modular components and support sampling from a 3D lidar. Another option is a NDT-MCL using NDT 2D/3D scan matching. Other options may be proposed and discussed with mentors during the application phase. The task involves 3D as well since there is no standard 3D localizer in ROS 2 yet and more and more robust 3D SLAM libraries have emerged over the last 2 years. An optional but recommended feature of this work would be to also accept the inputs from multiple laser scanners. However it is not strictly required. @@ -38,7 +38,7 @@ An optional but recommended feature of this work would be to also accept the inp - Ability to read and implement academic works - Recommended: Gazebo simulation and Navigation experience -**List of relevant open source software repositories and refs** +**List of relevant open source software repositories and refs** - `ROS `_ - `Gazebo Simulator `_ @@ -48,6 +48,3 @@ An optional but recommended feature of this work would be to also accept the inp **Licensing** - All contributions will be under the Apache 2.0 license. - No other CLA's are required. - - - diff --git a/2021summerOfCode/projects/multithreading.rst b/2021summerOfCode/projects/multithreading.rst index dd078ae414..8cc7ff807f 100644 --- a/2021summerOfCode/projects/multithreading.rst +++ b/2021summerOfCode/projects/multithreading.rst @@ -4,7 +4,7 @@ 4. Navigation MultiThreading ============================ -**Task description** +**Task description** The aim of this project is the significantly improve the run-time performance of Nav2 making sure to leverage the full capabilities of multi-processor core CPUs. We seek to identify areas in the Nav2 stack that could leverage multi-threading or parallel processing to speed up computations and improve overall user performance on a broad range of compute platforms. @@ -19,7 +19,7 @@ Some examples include: We are seeking a student interested in learning about multi-threading and parallel processing, ideally with some exposure to these concepts and libraries already, to analyze potential areas for parallel computing. Then, select the top candidates and implement them with parallel processing and benchmark the improvements to the Nav2 stack they provide. -This will be an excellent chance to apply (or obtain) C++ parallel computing skills while also learning a great deal about how to build mobile robot navigation systems -- both very valuable skillsets. +This will be an excellent chance to apply (or obtain) C++ parallel computing skills while also learning a great deal about how to build mobile robot navigation systems -- both very valuable skillsets. **Project difficulty: Medium** @@ -39,7 +39,7 @@ This will be an excellent chance to apply (or obtain) C++ parallel computing ski - Working knowledge (or ability to quickly obtain) on one or more of: TBB, OpenMP, OpenCL, Cuda, and similar - Recommended: Gazebo simulation, ROS navigation -**List of relevant open source software repositories and refs** +**List of relevant open source software repositories and refs** - `ROS `_ - `Gazebo Simulator `_ diff --git a/2021summerOfCode/projects/navigation_rebranding.rst b/2021summerOfCode/projects/navigation_rebranding.rst index 69da387ded..e2f41368da 100644 --- a/2021summerOfCode/projects/navigation_rebranding.rst +++ b/2021summerOfCode/projects/navigation_rebranding.rst @@ -6,7 +6,7 @@ 5. Navigation Branding and Website ================================== -**Task description** +**Task description** Navigation2 has made significant strides to be the best navigation system in the world. Over time, the original navigation stack in ROS has gained a reputation, fair or unfair, of being relatively limited in the types of tasks it can accomplish that are no longer true in ROS 2 Navigation2. @@ -30,7 +30,7 @@ As such, we would like to initiate a re-branding effort to help differentiate it - Web technologies - Creative thinking -**List of relevant open source software repositories and refs** +**List of relevant open source software repositories and refs** - `Github issue `_ - `Navigation2 `_ @@ -38,4 +38,3 @@ As such, we would like to initiate a re-branding effort to help differentiate it **Licensing** - All contributions will be under the Apache 2.0 license. - No other CLA's are required. - diff --git a/2021summerOfCode/projects/safety_node.rst b/2021summerOfCode/projects/safety_node.rst index 4dbd49ad2b..d41125b82e 100644 --- a/2021summerOfCode/projects/safety_node.rst +++ b/2021summerOfCode/projects/safety_node.rst @@ -4,7 +4,7 @@ 5. Navigation Safety Node ========================= -**Task description** +**Task description** The aim of this project is to create a safety watchdog node to ensure the robot is acting properly and not about to collide with an obstacle. Typical safety-rated lidars will contain "safety zones" whereas if any sensor points are located in a box around the lidar, then the lidar will send a signal to the robot to stop due to a potential collision. However, less and less people are using safety-rated lidars as consumer available lidars are dropping in cost and 3D lidars are seeing more use in mobile robotics. @@ -14,7 +14,7 @@ Your project will be to re-create this logic at the Navigation level. While this - Projecting the velocity forward in time ``N`` seconds, check if that velocity will result in a collision with any sensor measurements - If not, allow the velocity command through to the base - If it does collide, scale back the velocity such that the robot will always be at minimum ``N`` seconds from a collision -- Optionally if a flag is set, if ``M`` or more points are in defined bounding boxes around the robot, send only ``0`` commands to enact an emergency stop. +- Optionally if a flag is set, if ``M`` or more points are in defined bounding boxes around the robot, send only ``0`` commands to enact an emergency stop. This will be an excellent chance to make mobile robots and Nav2 users significantly safer and run at higher speeds in their production or research environments. It goes a long way for functional safety for those not using safety-rated lidars which contain similar features. @@ -36,7 +36,7 @@ This will be an excellent chance to make mobile robots and Nav2 users significan - Geometry and statistics - Recommended: Gazebo simulation, ROS navigation -**List of relevant open source software repositories and refs** +**List of relevant open source software repositories and refs** - `ROS `_ - `Gazebo Simulator `_ diff --git a/2021summerOfCode/projects/semantics.rst b/2021summerOfCode/projects/semantics.rst index b4201ddf29..5f6d29a463 100644 --- a/2021summerOfCode/projects/semantics.rst +++ b/2021summerOfCode/projects/semantics.rst @@ -29,7 +29,7 @@ After creating the generic representation, your project will be to create demons - Perception, semantic information motivation, or similar. - Recommended: Gazebo simulation, ROS navigation -**List of relevant open source software repositories and refs** +**List of relevant open source software repositories and refs** - `ROS `_ - `Gazebo Simulator `_ diff --git a/2021summerOfCode/projects/spinners.rst b/2021summerOfCode/projects/spinners.rst index e4d7ff803c..6ae9206423 100644 --- a/2021summerOfCode/projects/spinners.rst +++ b/2021summerOfCode/projects/spinners.rst @@ -5,7 +5,7 @@ 7. Reduce ROS 2 Nodes and Determinism ===================================== -**Task description** +**Task description** 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. @@ -32,7 +32,7 @@ More details about this project can be supplied if interested, but the tickets l - C++, ROS -**List of relevant open source software repositories and refs** +**List of relevant open source software repositories and refs** - `ROS `_ - `Gazebo Simulator `_ diff --git a/2021summerOfCode/projects/testing.rst b/2021summerOfCode/projects/testing.rst index 0d351f8fd0..bb42917b03 100644 --- a/2021summerOfCode/projects/testing.rst +++ b/2021summerOfCode/projects/testing.rst @@ -5,7 +5,7 @@ 2. Advanced Navigation Testing Framework ======================================== -**Task description** +**Task description** The ROS 2 Navigation Stack has had a focus on testing and reliability as a characteristic change from ROS 1 to ROS 2. We currently have a test coverage rate of 85% and do full system simulations in Continuous Integration (CI) to test the entire navigation system with a real robot completing real navigation tasks. Your task will be to increase the testing coverage rate to 90% (or +5% from your starting) and improve on the existing system tests to represent a more realistic environment. You will then work to make sure of that environment to actively block the robot from completing its task to simulate worst-case conditions. @@ -27,7 +27,7 @@ The ROS 2 Navigation Stack has had a focus on testing and reliability as a chara - Gazebo, recommended experience with Gazebo plugins - Recommended: Navigation experience -**List of relevant open source software repositories and refs** +**List of relevant open source software repositories and refs** - `ROS `_ - `Gazebo Simulator `_ diff --git a/2021summerOfCode/projects/twist_n_config.rst b/2021summerOfCode/projects/twist_n_config.rst index 7623153b6c..106cd60781 100644 --- a/2021summerOfCode/projects/twist_n_config.rst +++ b/2021summerOfCode/projects/twist_n_config.rst @@ -5,7 +5,7 @@ 8. Convert Twist to TwistStamped in Ecosystem and Run-Time Configuration ======================================================================== -**Task description** +**Task description** This project is comprised of 2 smaller projects that can be easily worked on in parallel. @@ -18,7 +18,7 @@ Once you've created a list of places in the ecosystem where it is used, your pro 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 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. +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** @@ -37,7 +37,7 @@ In the meantime while you're waiting for PRs to be merged or blocked by reviews - C++, Python3 - ROS 2 -**List of relevant open source software repositories and refs** +**List of relevant open source software repositories and refs** - `ROS `_ - `Gazebo Simulator `_ diff --git a/_themes/otc_tcs_sphinx_theme/.gitignore b/_themes/otc_tcs_sphinx_theme/.gitignore index 3139edebb0..6c014f9811 100644 --- a/_themes/otc_tcs_sphinx_theme/.gitignore +++ b/_themes/otc_tcs_sphinx_theme/.gitignore @@ -1,2 +1,2 @@ __pycache__ -_build \ No newline at end of file +_build diff --git a/_themes/otc_tcs_sphinx_theme/static/tcs_theme.css b/_themes/otc_tcs_sphinx_theme/static/tcs_theme.css index 02d5051b2d..263df8a775 100644 --- a/_themes/otc_tcs_sphinx_theme/static/tcs_theme.css +++ b/_themes/otc_tcs_sphinx_theme/static/tcs_theme.css @@ -169,4 +169,4 @@ th,td { .header__menu_list li { display: inline; margin-left: 20px; -} \ No newline at end of file +} diff --git a/_themes/otc_tcs_sphinx_theme/static/tcs_theme.js b/_themes/otc_tcs_sphinx_theme/static/tcs_theme.js index 9064b9f774..6317390701 100644 --- a/_themes/otc_tcs_sphinx_theme/static/tcs_theme.js +++ b/_themes/otc_tcs_sphinx_theme/static/tcs_theme.js @@ -36,7 +36,7 @@ for (i = 0; i < contents.length; i++) { content.style.maxHeight = 0; } else { content.style.maxHeight = content.scrollHeight + "px"; - } + } }); //Add the button to the page and remove the header @@ -47,4 +47,4 @@ for (i = 0; i < contents.length; i++) { spanElement.id = span_id; } } -} \ No newline at end of file +} diff --git a/about/robots.rst b/about/robots.rst index 2cfeaf6370..59fcc26f3f 100644 --- a/about/robots.rst +++ b/about/robots.rst @@ -52,7 +52,7 @@ Research Robots .. |ACFR| image:: images/ACFR.png :width: 100% :align: middle - :alt: Australian Centre for Robotics + :alt: Australian Centre for Robotics :target: https://robotics.sydney.edu.au/ .. |torch| image:: images/torch.png @@ -240,4 +240,3 @@ Research Robots :align: middle :alt: Waratah from Monash Nova Rocer :target: https://www.novarover.space/ - diff --git a/behavior_trees/overview/detailed_behavior_tree_walkthrough.rst b/behavior_trees/overview/detailed_behavior_tree_walkthrough.rst index 8f02a73b49..8707c59db8 100644 --- a/behavior_trees/overview/detailed_behavior_tree_walkthrough.rst +++ b/behavior_trees/overview/detailed_behavior_tree_walkthrough.rst @@ -268,6 +268,3 @@ For example, let's say the robot is stuck and the ``Navigation`` subtree returns 6. In this hypothetical scenario, let's assume that the ``BackUp`` action allowed the robot to successfully navigate in the ``Navigation`` subtree, and the robot reaches the goal. In this case, the overall BT will still return ``SUCCESS``. If the ``BackUp`` action was not sufficient enough to allow the robot to become un-stuck, the above logic will go on indefinitely until the ``number_of_retries`` in the parent of the ``Navigate`` subtree and ``Recovery`` subtree is exceeded, or if all the system-wide recoveries in the ``Recovery`` subtree return ``FAILURE`` (this is unlikely, and likely points to some other system failure). - - - diff --git a/behavior_trees/trees/nav_to_pose_and_pause_near_goal_obstacle.rst b/behavior_trees/trees/nav_to_pose_and_pause_near_goal_obstacle.rst index 9554e7a9c9..ef4c244d52 100644 --- a/behavior_trees/trees/nav_to_pose_and_pause_near_goal_obstacle.rst +++ b/behavior_trees/trees/nav_to_pose_and_pause_near_goal_obstacle.rst @@ -1,7 +1,7 @@ Navigate To Pose and Pause Near Goal-Obstacle ############################################# -.. note:: As a prerequisite, we encourage the users to go through the `Behavior Tree documentation `_, which explains about different behaviors nodes used in these trees such as ``ReactiveSequence``, ``SequenceWithMemory`` and ``RetryUntilSuccessful``. +.. note:: As a prerequisite, we encourage the users to go through the `Behavior Tree documentation `_, which explains about different behaviors nodes used in these trees such as ``ReactiveSequence``, ``SequenceWithMemory`` and ``RetryUntilSuccessful``. This behavior tree is a soft extension to the :ref:`behavior_tree_nav_to_pose`. Apart from the functionalities of :ref:`behavior_tree_nav_to_pose`, this behavior tree allows the robot to efficiently handle an obstacle (e.g. forklift, person, or other temporary obstacles) close to the goal by pausing the robot's navigation and wait for a user-specified time to check if the obstacle has cleared. @@ -16,9 +16,9 @@ If there is no significantly longer path, the monitor node goes into the ``Follo .. image:: ../images/walkthrough/patience_and_recovery.png Once there is a significantly longer path, the child node for the ``PathLongerOnApproach`` node ticks. -The child node is a ``RetryUntilSuccessful`` decorator node, which inturns have a ``SequenceWithMemory`` node as its child. -Firstly, the ``SequenceWithMemory`` node cancels the controller server by ticking the ``CancelControl`` node. The cancellation of the controller server halts the further navigation of the robot. -Next, the ``SequenceWithMemory`` node ticks the ``Wait`` node, which enables the robot to wait for the given user-specified time. +The child node is a ``RetryUntilSuccessful`` decorator node, which inturns have a ``SequenceWithMemory`` node as its child. +Firstly, the ``SequenceWithMemory`` node cancels the controller server by ticking the ``CancelControl`` node. The cancellation of the controller server halts the further navigation of the robot. +Next, the ``SequenceWithMemory`` node ticks the ``Wait`` node, which enables the robot to wait for the given user-specified time. Here we need to note that, the ``MonitorAndFollowPath`` is a ``ReactiveSequence`` node, therefore the ``PathLongerOnApproach`` node needs to return SUCCESS, before the ``FollowPath`` node can be ticked once again. In the below GIF, it can be seen that the robot is approaching the goal location, but it found an obstacle in the goal proximity, because of which the global planner, plans a longer path around. diff --git a/behavior_trees/trees/nav_to_pose_with_consistent_replanning_and_if_path_becomes_invalid.rst b/behavior_trees/trees/nav_to_pose_with_consistent_replanning_and_if_path_becomes_invalid.rst index 202978a8b4..71f649fe47 100644 --- a/behavior_trees/trees/nav_to_pose_with_consistent_replanning_and_if_path_becomes_invalid.rst +++ b/behavior_trees/trees/nav_to_pose_with_consistent_replanning_and_if_path_becomes_invalid.rst @@ -70,5 +70,3 @@ While this behavior tree does not make use of it, the ``PlannerSelector``, ``Con - - diff --git a/commander_api/index.rst b/commander_api/index.rst index 9b518d00d2..fbf1710c2f 100644 --- a/commander_api/index.rst +++ b/commander_api/index.rst @@ -19,7 +19,7 @@ You may use this simple commander preempt commands of the same type (e.g. you ca rclpy.init() nav = BasicNavigator() - + # ... nav.setInitialPose(init_pose) @@ -230,7 +230,7 @@ The ``nav2_simple_commander`` has a few examples to highlight the API functions - ``example_nav_through_poses.py`` - Demonstrates the navigate through poses capabilities of the navigator, as well as a number of auxiliary methods. - ``example_waypoint_follower.py`` - Demonstrates the waypoint following capabilities of the navigator, as well as a number of auxiliary methods. - ``example_follow_path.py`` - Demonstrates the path following capabilities of the navigator, as well as a number of auxiliary methods like path smoothing. -- ``example_assisted_teleop.py`` - Demonstrates the assisted teleop capabilities of the navigator. +- ``example_assisted_teleop.py`` - Demonstrates the assisted teleop capabilities of the navigator. The ``nav2_simple_commander`` has a few demonstrations to highlight a couple of simple autonomy applications you can build using the API: diff --git a/concepts/index.rst b/concepts/index.rst index 7d90ccb76c..4c46b75d22 100644 --- a/concepts/index.rst +++ b/concepts/index.rst @@ -82,7 +82,7 @@ More information can be found `in this book `_ I **strongly** recommend reading chapters 1-3 to get a good understanding of the nomenclature and workflow. It should only take about 30 minutes. -Behavior Trees provide a formal structure for navigation logic which can be both used to create complex systems but also be verifiable and validated as provenly correct using advanced tools. Having the application logic centralized in the behavior tree and with independent task servers (which only communicate data over the tree) allows for formal analysis. +Behavior Trees provide a formal structure for navigation logic which can be both used to create complex systems but also be verifiable and validated as provenly correct using advanced tools. Having the application logic centralized in the behavior tree and with independent task servers (which only communicate data over the tree) allows for formal analysis. For this project, we use `BehaviorTree CPP V4 `_ as the behavior tree library. We create node plugins which can be constructed into a tree, inside the ``BT Navigator``. diff --git a/configuration/packages/bt-plugins/actions/CancelControl.rst b/configuration/packages/bt-plugins/actions/CancelControl.rst index d285c02d6f..f448ba713f 100644 --- a/configuration/packages/bt-plugins/actions/CancelControl.rst +++ b/configuration/packages/bt-plugins/actions/CancelControl.rst @@ -13,7 +13,7 @@ Input Ports ====== ======= Type Default ------ ------- - string N/A + string N/A ====== ======= Description @@ -25,7 +25,7 @@ Input Ports ====== ======= Type Default ------ ------- - double 10 + double 10 ====== ======= Description diff --git a/configuration/packages/bt-plugins/actions/CancelCoverage.rst b/configuration/packages/bt-plugins/actions/CancelCoverage.rst index f39a4e1b7e..3d55032c8f 100644 --- a/configuration/packages/bt-plugins/actions/CancelCoverage.rst +++ b/configuration/packages/bt-plugins/actions/CancelCoverage.rst @@ -13,7 +13,7 @@ Input Ports ====== ======= Type Default ------ ------- - string N/A + string N/A ====== ======= Description @@ -25,7 +25,7 @@ Input Ports ====== ======= Type Default ------ ------- - double 10 + double 10 ====== ======= Description diff --git a/configuration/packages/bt-plugins/actions/ClearCostmapAroundRobot.rst b/configuration/packages/bt-plugins/actions/ClearCostmapAroundRobot.rst index f583809841..3254acca88 100644 --- a/configuration/packages/bt-plugins/actions/ClearCostmapAroundRobot.rst +++ b/configuration/packages/bt-plugins/actions/ClearCostmapAroundRobot.rst @@ -14,18 +14,18 @@ Input Ports ============== ======= Type Default -------------- ------- - double 1 + double 1 ============== ======= Description side size of the square area centered on the robot that will be cleared on the costmap (the rest of the costmap won't) - + :service_name: ============== ======= Type Default -------------- ------- - string N/A + string N/A ============== ======= Description @@ -36,7 +36,7 @@ Input Ports ============== ======= Type Default -------------- ------- - double 10 + double 10 ============== ======= Description diff --git a/configuration/packages/bt-plugins/actions/ClearCostmapExceptRegion.rst b/configuration/packages/bt-plugins/actions/ClearCostmapExceptRegion.rst index 9e31a90e58..bc76f97529 100644 --- a/configuration/packages/bt-plugins/actions/ClearCostmapExceptRegion.rst +++ b/configuration/packages/bt-plugins/actions/ClearCostmapExceptRegion.rst @@ -14,18 +14,18 @@ Input Ports ============== ======= Type Default -------------- ------- - double 1 + double 1 ============== ======= Description side size of the square area centered on the robot that will not be cleared on the costmap (all the rest of the costmap will) - + :service_name: ============== ======= Type Default -------------- ------- - string N/A + string N/A ============== ======= Description @@ -36,7 +36,7 @@ Input Ports ============== ======= Type Default -------------- ------- - double 10 + double 10 ============== ======= Description diff --git a/configuration/packages/bt-plugins/actions/ClearEntireCostmap.rst b/configuration/packages/bt-plugins/actions/ClearEntireCostmap.rst index da213e0c9b..f591648142 100644 --- a/configuration/packages/bt-plugins/actions/ClearEntireCostmap.rst +++ b/configuration/packages/bt-plugins/actions/ClearEntireCostmap.rst @@ -14,7 +14,7 @@ Input Ports ============== ======= Type Default -------------- ------- - string N/A + string N/A ============== ======= Description @@ -25,7 +25,7 @@ Input Ports ============== ======= Type Default -------------- ------- - double 10 + double 10 ============== ======= Description diff --git a/configuration/packages/bt-plugins/actions/ControllerSelector.rst b/configuration/packages/bt-plugins/actions/ControllerSelector.rst index 1506336378..6443d6563b 100644 --- a/configuration/packages/bt-plugins/actions/ControllerSelector.rst +++ b/configuration/packages/bt-plugins/actions/ControllerSelector.rst @@ -17,18 +17,18 @@ Input Ports ====== ======= Type Default ------ ------- - string controller_selector + string controller_selector ====== ======= Description - The name of the topic used to received select command messages. This is used to support multiple ControllerSelector nodes. - + The name of the topic used to received select command messages. This is used to support multiple ControllerSelector nodes. + :default_controller: ====== ======= Type Default ------ ------- - string N/A + string N/A ====== ======= Description @@ -43,7 +43,7 @@ Output Ports ====== ======= Type Default ------ ------- - string N/A + string N/A ====== ======= Description diff --git a/configuration/packages/bt-plugins/actions/FollowPath.rst b/configuration/packages/bt-plugins/actions/FollowPath.rst index 8e6b16b90a..65e4aaae06 100644 --- a/configuration/packages/bt-plugins/actions/FollowPath.rst +++ b/configuration/packages/bt-plugins/actions/FollowPath.rst @@ -47,7 +47,7 @@ Input Ports ====== ======= Type Default ------ ------- - string N/A + string N/A ====== ======= Description diff --git a/configuration/packages/bt-plugins/actions/GetPoseFromPath.rst b/configuration/packages/bt-plugins/actions/GetPoseFromPath.rst index 7a366653cd..cd06098450 100644 --- a/configuration/packages/bt-plugins/actions/GetPoseFromPath.rst +++ b/configuration/packages/bt-plugins/actions/GetPoseFromPath.rst @@ -38,7 +38,7 @@ Output Ports ========================= ======= Type Default ------------------------- ------- - geometry_msgs/PoseStamped N/A + geometry_msgs/PoseStamped N/A ========================= ======= Description diff --git a/configuration/packages/bt-plugins/actions/GoalCheckerSelector.rst b/configuration/packages/bt-plugins/actions/GoalCheckerSelector.rst index 8ac7c0a452..0a9cccdf33 100644 --- a/configuration/packages/bt-plugins/actions/GoalCheckerSelector.rst +++ b/configuration/packages/bt-plugins/actions/GoalCheckerSelector.rst @@ -17,18 +17,18 @@ Input Ports ====== ======= Type Default ------ ------- - string goal_checker_selector + string goal_checker_selector ====== ======= Description - The name of the topic used to received select command messages. This is used to support multiple GoalCheckerSelector nodes. - + The name of the topic used to received select command messages. This is used to support multiple GoalCheckerSelector nodes. + :default_goal_checker: ====== ======= Type Default ------ ------- - string N/A + string N/A ====== ======= Description @@ -43,7 +43,7 @@ Output Ports ====== ======= Type Default ------ ------- - string N/A + string N/A ====== ======= Description diff --git a/configuration/packages/bt-plugins/actions/PlannerSelector.rst b/configuration/packages/bt-plugins/actions/PlannerSelector.rst index 0e20196094..8d01ad8736 100644 --- a/configuration/packages/bt-plugins/actions/PlannerSelector.rst +++ b/configuration/packages/bt-plugins/actions/PlannerSelector.rst @@ -17,18 +17,18 @@ Input Ports ====== ======= Type Default ------ ------- - string planner_selector + string planner_selector ====== ======= Description The name of the topic used to received select command messages. This is used to support multiple PlannerSelector nodes. - + :default_planner: ====== ======= Type Default ------ ------- - string N/A + string N/A ====== ======= Description @@ -43,7 +43,7 @@ Output Ports ====== ======= Type Default ------ ------- - string N/A + string N/A ====== ======= Description diff --git a/configuration/packages/bt-plugins/actions/ProgressCheckerSelector.rst b/configuration/packages/bt-plugins/actions/ProgressCheckerSelector.rst index efd6717af2..af25faf737 100644 --- a/configuration/packages/bt-plugins/actions/ProgressCheckerSelector.rst +++ b/configuration/packages/bt-plugins/actions/ProgressCheckerSelector.rst @@ -17,18 +17,18 @@ Input Ports ====== ======= Type Default ------ ------- - string progress_checker_selector + string progress_checker_selector ====== ======= Description - The name of the topic used to received select command messages. This is used to support multiple ProgressCheckerSelector nodes. - + The name of the topic used to received select command messages. This is used to support multiple ProgressCheckerSelector nodes. + :default_progress_checker: ====== ======= Type Default ------ ------- - string N/A + string N/A ====== ======= Description @@ -43,7 +43,7 @@ Output Ports ====== ======= Type Default ------ ------- - string N/A + string N/A ====== ======= Description diff --git a/configuration/packages/bt-plugins/actions/ReinitializeGlobalLocalization.rst b/configuration/packages/bt-plugins/actions/ReinitializeGlobalLocalization.rst index b9e597a48a..e55135ae1b 100644 --- a/configuration/packages/bt-plugins/actions/ReinitializeGlobalLocalization.rst +++ b/configuration/packages/bt-plugins/actions/ReinitializeGlobalLocalization.rst @@ -13,7 +13,7 @@ Input Ports ====== ======= Type Default ------ ------- - string N/A + string N/A ====== ======= Description @@ -25,7 +25,7 @@ Input Ports ====== ======= Type Default ------ ------- - double 10 + double 10 ====== ======= Description diff --git a/configuration/packages/bt-plugins/actions/RemoveInCollisionGoals.rst b/configuration/packages/bt-plugins/actions/RemoveInCollisionGoals.rst index e575bfb605..d16b96e413 100644 --- a/configuration/packages/bt-plugins/actions/RemoveInCollisionGoals.rst +++ b/configuration/packages/bt-plugins/actions/RemoveInCollisionGoals.rst @@ -14,7 +14,7 @@ Input Ports ====== ======================================= Type Default ------ --------------------------------------- - string /global_costmap/get_cost_global_costmap + string /global_costmap/get_cost_global_costmap ====== ======================================= Description @@ -36,18 +36,18 @@ Input Ports ====== ======= Type Default ------ ------- - double 254.0 + double 254.0 ====== ======= Description - The cost threshold above which a waypoint is considered in collision and should be removed. If ``use_footprint = false``, consider setting to 253 for occupied. + The cost threshold above which a waypoint is considered in collision and should be removed. If ``use_footprint = false``, consider setting to 253 for occupied. :use_footprint: ====== ======= Type Default ------ ------- - bool true + bool true ====== ======= Description @@ -58,7 +58,7 @@ Input Ports ====== ======= Type Default ------ ------- - bool false + bool false ====== ======= Description @@ -72,7 +72,7 @@ Output Ports =============================== ======= Type Default ------------------------------- ------- - geometry_msgs::msg::PoseStamped N/A + geometry_msgs::msg::PoseStamped N/A =============================== ======= Description @@ -84,4 +84,3 @@ Example .. code-block:: xml - diff --git a/configuration/packages/bt-plugins/actions/RemovePassedGoals.rst b/configuration/packages/bt-plugins/actions/RemovePassedGoals.rst index 65feb42b8a..5f9c96448d 100644 --- a/configuration/packages/bt-plugins/actions/RemovePassedGoals.rst +++ b/configuration/packages/bt-plugins/actions/RemovePassedGoals.rst @@ -14,11 +14,11 @@ Input Ports ====== ======= Type Default ------ ------- - double 0.5 + double 0.5 ====== ======= Description - The radius (m) in proximity to the viapoint for the BT node to remove from the list as having passed. + The radius (m) in proximity to the viapoint for the BT node to remove from the list as having passed. :robot_base_frame: @@ -62,4 +62,3 @@ Example .. code-block:: xml - diff --git a/configuration/packages/bt-plugins/actions/SmootherSelector.rst b/configuration/packages/bt-plugins/actions/SmootherSelector.rst index 9736d98161..7277f92ad9 100644 --- a/configuration/packages/bt-plugins/actions/SmootherSelector.rst +++ b/configuration/packages/bt-plugins/actions/SmootherSelector.rst @@ -17,18 +17,18 @@ Input Ports ====== ======= Type Default ------ ------- - string smoother_selector + string smoother_selector ====== ======= Description - The name of the topic used to received select command messages. This is used to support multiple SmootherSelector nodes. - + The name of the topic used to received select command messages. This is used to support multiple SmootherSelector nodes. + :default_smoother: ====== ======= Type Default ------ ------- - string N/A + string N/A ====== ======= Description @@ -43,7 +43,7 @@ Output Ports ====== ======= Type Default ------ ------- - string N/A + string N/A ====== ======= Description diff --git a/configuration/packages/bt-plugins/actions/Spin.rst b/configuration/packages/bt-plugins/actions/Spin.rst index 907d855cab..1c45084aab 100644 --- a/configuration/packages/bt-plugins/actions/Spin.rst +++ b/configuration/packages/bt-plugins/actions/Spin.rst @@ -110,4 +110,3 @@ Example - diff --git a/configuration/packages/bt-plugins/conditions/AreErrorCodesPresent.rst b/configuration/packages/bt-plugins/conditions/AreErrorCodesPresent.rst index 5fa494071b..5989c5a920 100644 --- a/configuration/packages/bt-plugins/conditions/AreErrorCodesPresent.rst +++ b/configuration/packages/bt-plugins/conditions/AreErrorCodesPresent.rst @@ -5,7 +5,7 @@ AreErrorCodesPresent Checks the if the provided error code matches any error code within a set. -If the active error code is a match, the node returns ``SUCCESS``. Otherwise, it returns ``FAILURE``. +If the active error code is a match, the node returns ``SUCCESS``. Otherwise, it returns ``FAILURE``. Input Ports ----------- @@ -19,7 +19,7 @@ Input Ports ============== ======= Description - The active error code to compare against. + The active error code to compare against. :error_codes_to_check: @@ -30,18 +30,18 @@ Input Ports ======================== ======= Description - The set of error codes you wish to compare against the active error code. + The set of error codes you wish to compare against the active error code. Example ------- -Error codes to check are defined in another port. +Error codes to check are defined in another port. .. code-block:: xml -Error codes to check are defined to be 101, 107 and 119. +Error codes to check are defined to be 101, 107 and 119. .. code-block:: xml diff --git a/configuration/packages/bt-plugins/conditions/DistanceTraveled.rst b/configuration/packages/bt-plugins/conditions/DistanceTraveled.rst index 1ee3e51b7a..71524a1ac4 100644 --- a/configuration/packages/bt-plugins/conditions/DistanceTraveled.rst +++ b/configuration/packages/bt-plugins/conditions/DistanceTraveled.rst @@ -29,7 +29,7 @@ Input Ports ====== ======= Type Default ------ ------- - double 1.0 + double 1.0 ====== ======= Description diff --git a/configuration/packages/bt-plugins/conditions/GlobalUpdatedGoal.rst b/configuration/packages/bt-plugins/conditions/GlobalUpdatedGoal.rst index c2aeb77c5b..ebc4d1391d 100644 --- a/configuration/packages/bt-plugins/conditions/GlobalUpdatedGoal.rst +++ b/configuration/packages/bt-plugins/conditions/GlobalUpdatedGoal.rst @@ -3,11 +3,11 @@ GlobalUpdatedGoal ================= -Checks if the global navigation goal has changed in the blackboard. +Checks if the global navigation goal has changed in the blackboard. Returns failure if the goal is the same, if it changes, it returns success. This node differs from the GoalUpdated by retaining the state of the current goal/goals throughout each tick of the BehaviorTree -such that it will update on any "global" change to the goal. +such that it will update on any "global" change to the goal. Input Ports ----------- @@ -39,4 +39,4 @@ Example .. code-block:: xml - \ No newline at end of file + diff --git a/configuration/packages/bt-plugins/conditions/GoalUpdated.rst b/configuration/packages/bt-plugins/conditions/GoalUpdated.rst index db0c17d203..e68d4d853e 100644 --- a/configuration/packages/bt-plugins/conditions/GoalUpdated.rst +++ b/configuration/packages/bt-plugins/conditions/GoalUpdated.rst @@ -3,7 +3,7 @@ GoalUpdated =========== -Checks if the global navigation goal, or a vector of goals, has changed in the blackboard. +Checks if the global navigation goal, or a vector of goals, has changed in the blackboard. Returns failure if the goal is the same, if it changes, it returns success. Input Ports diff --git a/configuration/packages/bt-plugins/conditions/IsBatteryCharging.rst b/configuration/packages/bt-plugins/conditions/IsBatteryCharging.rst index 91e50ae525..834d7378fe 100644 --- a/configuration/packages/bt-plugins/conditions/IsBatteryCharging.rst +++ b/configuration/packages/bt-plugins/conditions/IsBatteryCharging.rst @@ -15,7 +15,7 @@ Input Ports --------------- ------------------- string "/battery_status" =============== =================== - + Description Topic for battery info. diff --git a/configuration/packages/bt-plugins/conditions/IsBatteryLow.rst b/configuration/packages/bt-plugins/conditions/IsBatteryLow.rst index f72cc56147..27795fcc8f 100644 --- a/configuration/packages/bt-plugins/conditions/IsBatteryLow.rst +++ b/configuration/packages/bt-plugins/conditions/IsBatteryLow.rst @@ -26,7 +26,7 @@ Input Ports --------------- ------------------- string "/battery_status" =============== =================== - + Description Topic for battery info. @@ -36,7 +36,7 @@ Input Ports ------ ------- bool false ====== ======= - + Description If true voltage will be used to check for low battery. diff --git a/configuration/packages/bt-plugins/conditions/IsPathValid.rst b/configuration/packages/bt-plugins/conditions/IsPathValid.rst index 31b6b7953e..8007835ec6 100644 --- a/configuration/packages/bt-plugins/conditions/IsPathValid.rst +++ b/configuration/packages/bt-plugins/conditions/IsPathValid.rst @@ -26,7 +26,7 @@ Input Ports ==================================== ======= Type Default ------------------------------------ ------- - nav_msgs::msg::Path N/A + nav_msgs::msg::Path N/A ==================================== ======= Description @@ -48,7 +48,7 @@ Input Ports ====== ======= Type Default ------ ------- - bool false + bool false ====== ======= Description @@ -60,4 +60,4 @@ Example .. code-block:: xml - \ No newline at end of file + diff --git a/configuration/packages/bt-plugins/conditions/IsStopped.rst b/configuration/packages/bt-plugins/conditions/IsStopped.rst index ce3ca4d35d..d1375ccb34 100644 --- a/configuration/packages/bt-plugins/conditions/IsStopped.rst +++ b/configuration/packages/bt-plugins/conditions/IsStopped.rst @@ -25,15 +25,15 @@ Input Port ======== ======= Type Default -------- ------- - int (ms) 1000 + int (ms) 1000 ======== ======= Description - Duration (ms) the velocity must remain below the threshold + Duration (ms) the velocity must remain below the threshold Example ------- .. code-block:: xml - \ No newline at end of file + diff --git a/configuration/packages/bt-plugins/conditions/IsStuck.rst b/configuration/packages/bt-plugins/conditions/IsStuck.rst index 93da9f20fa..90f7ea404e 100644 --- a/configuration/packages/bt-plugins/conditions/IsStuck.rst +++ b/configuration/packages/bt-plugins/conditions/IsStuck.rst @@ -3,8 +3,8 @@ IsStuck ======= -Determines if the robot is not progressing towards the goal. -If the robot is stuck and not progressing, the condition returns +Determines if the robot is not progressing towards the goal. +If the robot is stuck and not progressing, the condition returns SUCCESS, otherwise it returns FAILURE. Example @@ -12,4 +12,4 @@ Example .. code-block:: xml - \ No newline at end of file + diff --git a/configuration/packages/bt-plugins/conditions/TimeExpired.rst b/configuration/packages/bt-plugins/conditions/TimeExpired.rst index 99ca8aae36..02feb9af7a 100644 --- a/configuration/packages/bt-plugins/conditions/TimeExpired.rst +++ b/configuration/packages/bt-plugins/conditions/TimeExpired.rst @@ -21,4 +21,4 @@ Example .. code-block:: xml - \ No newline at end of file + diff --git a/configuration/packages/bt-plugins/conditions/WouldAControllerRecoveryHelp.rst b/configuration/packages/bt-plugins/conditions/WouldAControllerRecoveryHelp.rst index 7e053eff74..cfa3758542 100644 --- a/configuration/packages/bt-plugins/conditions/WouldAControllerRecoveryHelp.rst +++ b/configuration/packages/bt-plugins/conditions/WouldAControllerRecoveryHelp.rst @@ -5,7 +5,7 @@ WouldAControllerRecoveryHelp Checks if the active controller server error code is UNKNOWN, PATIENCE_EXCEEDED, FAILED_TO_MAKE_PROGRESS, or NO_VALID_CONTROL. -If the active error code is a match, the node returns ``SUCCESS``. Otherwise, it returns ``FAILURE``. +If the active error code is a match, the node returns ``SUCCESS``. Otherwise, it returns ``FAILURE``. Input Port ---------- @@ -19,11 +19,11 @@ Input Port ============== ======= Description - The active error code to compare against. This should match the controller server error code. + The active error code to compare against. This should match the controller server error code. Example ------- .. code-block:: xml - \ No newline at end of file + diff --git a/configuration/packages/bt-plugins/conditions/WouldAPlannerRecoveryHelp.rst b/configuration/packages/bt-plugins/conditions/WouldAPlannerRecoveryHelp.rst index c039c31a01..a16b82d465 100644 --- a/configuration/packages/bt-plugins/conditions/WouldAPlannerRecoveryHelp.rst +++ b/configuration/packages/bt-plugins/conditions/WouldAPlannerRecoveryHelp.rst @@ -5,7 +5,7 @@ WouldAPlannerRecoveryHelp Checks if the active controller server error code is UNKNOWN, NO_VALID_CONTROL, or TIMEOUT. -If the active error code is a match, the node returns ``SUCCESS``. Otherwise, it returns ``FAILURE``. +If the active error code is a match, the node returns ``SUCCESS``. Otherwise, it returns ``FAILURE``. Input Port ---------- @@ -19,11 +19,11 @@ Input Port ============== ======= Description - The active error code to compare against. This should match the planner server error code. + The active error code to compare against. This should match the planner server error code. Example ------- .. code-block:: xml - \ No newline at end of file + diff --git a/configuration/packages/bt-plugins/conditions/WouldASmootherRecoveryHelp.rst b/configuration/packages/bt-plugins/conditions/WouldASmootherRecoveryHelp.rst index 96e7f0d0e3..2cdee5f679 100644 --- a/configuration/packages/bt-plugins/conditions/WouldASmootherRecoveryHelp.rst +++ b/configuration/packages/bt-plugins/conditions/WouldASmootherRecoveryHelp.rst @@ -5,7 +5,7 @@ WouldASmootherRecoveryHelp Checks if the active controller server error code is UNKNOWN, TIMEOUT, FAILED_TO_SMOOTH_PATH, or SMOOTHED_PATH_IN_COLLISION. -If the active error code is a match, the node returns ``SUCCESS``. Otherwise, it returns ``FAILURE``. +If the active error code is a match, the node returns ``SUCCESS``. Otherwise, it returns ``FAILURE``. Input Port ---------- @@ -19,11 +19,11 @@ Input Port ============== ======= Description - The active error code to compare against. This should match the smoother server error code. + The active error code to compare against. This should match the smoother server error code. Example ------- .. code-block:: xml - \ No newline at end of file + diff --git a/configuration/packages/bt-plugins/controls/PipelineSequence.rst b/configuration/packages/bt-plugins/controls/PipelineSequence.rst index a9e69b3221..95822074a1 100644 --- a/configuration/packages/bt-plugins/controls/PipelineSequence.rst +++ b/configuration/packages/bt-plugins/controls/PipelineSequence.rst @@ -3,9 +3,9 @@ PipelineSequence ================ -Ticks the first child till it succeeds, then ticks the first and second children till the second one succeeds. -It then ticks the first, second, and third children until the third succeeds, and so on, and so on. If at any -time a child returns RUNNING, that doesn't change the behavior. If at any time a child returns FAILURE, that +Ticks the first child till it succeeds, then ticks the first and second children till the second one succeeds. +It then ticks the first, second, and third children until the third succeeds, and so on, and so on. If at any +time a child returns RUNNING, that doesn't change the behavior. If at any time a child returns FAILURE, that stops all children and returns FAILURE overall. @@ -17,4 +17,3 @@ Example - \ No newline at end of file diff --git a/configuration/packages/bt-plugins/controls/RecoveryNode.rst b/configuration/packages/bt-plugins/controls/RecoveryNode.rst index 2ffad7fefd..06f25ce009 100644 --- a/configuration/packages/bt-plugins/controls/RecoveryNode.rst +++ b/configuration/packages/bt-plugins/controls/RecoveryNode.rst @@ -3,11 +3,11 @@ RecoveryNode ============ -The RecoveryNode is a control flow node with two children. -It returns SUCCESS if and only if the first child returns SUCCESS. -The second child will be executed only if the first child returns FAILURE. -If the second child SUCCEEDS, then the first child will be executed again. -The user can specify how many times the recovery actions should be taken before returning FAILURE. +The RecoveryNode is a control flow node with two children. +It returns SUCCESS if and only if the first child returns SUCCESS. +The second child will be executed only if the first child returns FAILURE. +If the second child SUCCEEDS, then the first child will be executed again. +The user can specify how many times the recovery actions should be taken before returning FAILURE. In nav2, the RecoveryNode is included in Behavior Trees to implement recovery actions upon failures. Input Ports diff --git a/configuration/packages/bt-plugins/decorators/DistanceController.rst b/configuration/packages/bt-plugins/decorators/DistanceController.rst index 1e0d7829ef..29a584227f 100644 --- a/configuration/packages/bt-plugins/decorators/DistanceController.rst +++ b/configuration/packages/bt-plugins/decorators/DistanceController.rst @@ -3,9 +3,9 @@ DistanceController ================== -A node that controls the tick rate for its child based on the distance traveled. -The distance to be traveled before replanning can be supplied to the node as a parameter. -The node returns RUNNING when it is not ticking its child. Currently, in the navigation +A node that controls the tick rate for its child based on the distance traveled. +The distance to be traveled before replanning can be supplied to the node as a parameter. +The node returns RUNNING when it is not ticking its child. Currently, in the navigation stack, the ``DistanceController`` is used to adjust the rate at which the ``ComputePathToPose`` and ``GoalReached`` nodes are ticked. Input Ports diff --git a/configuration/packages/bt-plugins/decorators/PathLongerOnApproach.rst b/configuration/packages/bt-plugins/decorators/PathLongerOnApproach.rst index 7e2d84e3f0..b377e8b451 100644 --- a/configuration/packages/bt-plugins/decorators/PathLongerOnApproach.rst +++ b/configuration/packages/bt-plugins/decorators/PathLongerOnApproach.rst @@ -13,7 +13,7 @@ Input Ports ========================== ======= Type Default -------------------------- ------- - nav_msgs::msg::Path N/A + nav_msgs::msg::Path N/A ========================== ======= Description @@ -24,7 +24,7 @@ Input Ports ============= ======= Type Default ------------- ------- - double 3.0 + double 3.0 ============= ======= Description @@ -35,7 +35,7 @@ Input Ports ============= ======= Type Default ------------- ------- - double 2.0 + double 2.0 ============= ======= Description diff --git a/configuration/packages/bt-plugins/decorators/RateController.rst b/configuration/packages/bt-plugins/decorators/RateController.rst index d21e003033..b51a3d2e80 100644 --- a/configuration/packages/bt-plugins/decorators/RateController.rst +++ b/configuration/packages/bt-plugins/decorators/RateController.rst @@ -3,10 +3,10 @@ RateController ============== -A node that throttles the tick rate for its child. -The tick rate can be supplied to the node as a parameter. -The node returns RUNNING when it is not ticking its child. -Currently, in the navigation stack, the ``RateController`` is +A node that throttles the tick rate for its child. +The tick rate can be supplied to the node as a parameter. +The node returns RUNNING when it is not ticking its child. +Currently, in the navigation stack, the ``RateController`` is used to adjust the rate at which the ``ComputePathToPose`` and ``GoalReached`` nodes are ticked. Input Ports @@ -31,4 +31,3 @@ Example - \ No newline at end of file diff --git a/configuration/packages/bt-plugins/decorators/SingleTrigger.rst b/configuration/packages/bt-plugins/decorators/SingleTrigger.rst index 0114755276..9091ad7683 100644 --- a/configuration/packages/bt-plugins/decorators/SingleTrigger.rst +++ b/configuration/packages/bt-plugins/decorators/SingleTrigger.rst @@ -3,7 +3,7 @@ SingleTrigger ============= -This node triggers its child only once and returns FAILURE for every succeeding tick. +This node triggers its child only once and returns FAILURE for every succeeding tick. Example ------- diff --git a/configuration/packages/bt-plugins/decorators/SpeedController.rst b/configuration/packages/bt-plugins/decorators/SpeedController.rst index e6f9c05975..94eae7121c 100644 --- a/configuration/packages/bt-plugins/decorators/SpeedController.rst +++ b/configuration/packages/bt-plugins/decorators/SpeedController.rst @@ -5,7 +5,7 @@ SpeedController A node that controls the tick rate for its child based on current robot speed. The maximum and minimum replanning rates can be supplied to the node as parameters along with maximum and minimum speed. -The node returns RUNNING when it is not ticking its child. Currently, in the navigation +The node returns RUNNING when it is not ticking its child. Currently, in the navigation stack, the ``SpeedController`` is used to adjust the rate at which the ``ComputePathToPose`` and ``GoalReached`` nodes are ticked. Input Ports diff --git a/configuration/packages/collision_monitor/configuring-collision-detector-node.rst b/configuration/packages/collision_monitor/configuring-collision-detector-node.rst index 0776f3d22f..9310620c35 100644 --- a/configuration/packages/collision_monitor/configuring-collision-detector-node.rst +++ b/configuration/packages/collision_monitor/configuring-collision-detector-node.rst @@ -285,7 +285,7 @@ Observation sources parameters Description: Internally the polygon is sampled for collision detection. sampling_distance is the distance between sampled points of the polygon. Applicable for ``polygon`` source type. - + :````.enabled: ============== ============================= @@ -296,7 +296,7 @@ Observation sources parameters Description: Whether to use this source for collision detection. (Can be dynamically set) - + :````.source_timeout: ============== ============================= @@ -307,7 +307,7 @@ Observation sources 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. Overrides node parameter for each source individually, if desired. - + :bond_heartbeat_period: ============== ============================= @@ -353,4 +353,3 @@ Here is an example of configuration YAML for the Collision Detector. min_height: 0.1 max_height: 0.5 enabled: True - diff --git a/configuration/packages/collision_monitor/configuring-collision-monitor-node.rst b/configuration/packages/collision_monitor/configuring-collision-monitor-node.rst index e9a21f27ac..023f34c4b3 100644 --- a/configuration/packages/collision_monitor/configuring-collision-monitor-node.rst +++ b/configuration/packages/collision_monitor/configuring-collision-monitor-node.rst @@ -47,7 +47,7 @@ The zones around the robot can take the following shapes: - Arbitrary user-defined polygon relative to the robot base frame, which can be static in a configuration file or dynamically changing via a topic interface. - Robot footprint polygon, which is used in the approach behavior model only. Will use the static user-defined polygon or the footprint topic to allow it to be dynamically adjusted over time. - Circle: is made for the best performance and could be used in the cases where the zone or robot footprint could be approximated by round shape. -- VelocityPolygon: allow switching of polygons based on the command velocity. This is useful for robots to set different safety zones based on their velocity (e.g. a robot that has a larger safety zone when moving at 1.0 m/s than when moving at 0.5 m/s). +- VelocityPolygon: allow switching of polygons based on the command velocity. This is useful for robots to set different safety zones based on their velocity (e.g. a robot that has a larger safety zone when moving at 1.0 m/s than when moving at 0.5 m/s). All shapes (``Polygon``, ``Circle`` and ``VelocityPolygon``) are derived from base ``Polygon`` class, so without loss of generality they would be called as "polygons". Subscribed footprint is also having the same properties as other polygons, but it is being obtained a footprint topic for the Approach Model. @@ -189,7 +189,7 @@ Parameters ============== ======= Type Default -------------- ------- - bool false + bool false ============== ======= Description @@ -450,7 +450,7 @@ All previous Polygon parameters apply, in addition to the following unique param Maximum linear velocity for the sub polygon. In holonomic mode, this is the maximum resultant velocity. Causes an error, if not specified. :``.``.theta_min: - + ============== ============================= Type Default -------------- ----------------------------- @@ -467,7 +467,7 @@ All previous Polygon parameters apply, in addition to the following unique param -------------- ----------------------------- double N/A ============== ============================= - + Description: Maximum angular velocity for the sub polygon. Causes an error, if not specified. @@ -574,7 +574,7 @@ Observation sources parameters Description: Whether to use this source for collision monitoring. (Can be dynamically set) - + :````.source_timeout: ============== ============================= @@ -688,7 +688,7 @@ Here is an example of configuration YAML for the Collision Monitor. theta_max: 1.0 # This is the last polygon to be checked, it should cover the entire range of robot's velocities # It is used as the stopped polygon when the robot is not moving and as a fallback if the velocity - # is not covered by any of the other sub-polygons + # is not covered by any of the other sub-polygons stopped: points: "[[0.25, 0.25], [0.25, -0.25], [-0.25, -0.25], [-0.25, 0.25]]" linear_min: -1.0 diff --git a/configuration/packages/configuring-amcl.rst b/configuration/packages/configuring-amcl.rst index e43e47f171..ff6105b7db 100644 --- a/configuration/packages/configuring-amcl.rst +++ b/configuration/packages/configuring-amcl.rst @@ -17,7 +17,7 @@ Parameters ============== ======= Type Default -------------- ------- - double 0.2 + double 0.2 ============== ======= Description @@ -26,9 +26,9 @@ Parameters :alpha2: ============== ============== - Type Default + Type Default -------------- -------------- - double 0.2 + double 0.2 ============== ============== Description @@ -37,9 +37,9 @@ Parameters :alpha3: ============== ============================= - Type Default + Type Default -------------- ----------------------------- - double 0.2 + double 0.2 ============== ============================= Description @@ -48,9 +48,9 @@ Parameters :alpha4: ============== ============================= - Type Default + Type Default -------------- ----------------------------- - double 0.2 + double 0.2 ============== ============================= Description @@ -59,9 +59,9 @@ Parameters :alpha5: ============== ============================= - Type Default + Type Default -------------- ----------------------------- - double 0.2 + double 0.2 ============== ============================= Description @@ -70,9 +70,9 @@ Parameters :base_frame_id: ============== ============================= - Type Default + Type Default -------------- ----------------------------- - string "base_footprint" + string "base_footprint" ============== ============================= Description @@ -81,9 +81,9 @@ Parameters :beam_skip_distance: ============== ============================= - Type Default + Type Default -------------- ----------------------------- - double 0.5 + double 0.5 ============== ============================= Description @@ -92,9 +92,9 @@ Parameters :beam_skip_error_threshold: ============== ============================= - Type Default + Type Default -------------- ----------------------------- - double 0.9 + double 0.9 ============== ============================= Description @@ -103,9 +103,9 @@ Parameters :beam_skip_threshold: ============== ============================= - Type Default + Type Default -------------- ----------------------------- - double 0.3 + double 0.3 ============== ============================= Description @@ -114,9 +114,9 @@ Parameters :do_beamskip: ============== ============================= - Type Default + Type Default -------------- ----------------------------- - bool False + bool False ============== ============================= Description @@ -125,9 +125,9 @@ Parameters :global_frame_id: ============== ============================= - Type Default + Type Default -------------- ----------------------------- - string "map" + string "map" ============== ============================= Description @@ -136,9 +136,9 @@ Parameters :lambda_short: ============== ============================= - Type Default + Type Default -------------- ----------------------------- - double 0.1 + double 0.1 ============== ============================= Description @@ -147,9 +147,9 @@ Parameters :laser_likelihood_max_dist: ============== ============================= - Type Default + Type Default -------------- ----------------------------- - double 2.0 + double 2.0 ============== ============================= Description @@ -158,9 +158,9 @@ Parameters :laser_max_range: ============== ============================= - Type Default + Type Default -------------- ----------------------------- - double 100.0 + double 100.0 ============== ============================= Description @@ -169,9 +169,9 @@ Parameters :laser_min_range: ============== ============================= - Type Default + Type Default -------------- ----------------------------- - double -1.0 + double -1.0 ============== ============================= Description @@ -180,9 +180,9 @@ Parameters :laser_model_type: ============== ============================= - Type Default + Type Default -------------- ----------------------------- - string "likelihood_field" + string "likelihood_field" ============== ============================= Description @@ -191,9 +191,9 @@ Parameters :set_initial_pose: ============== ============================= - Type Default + Type Default -------------- ----------------------------- - bool False + bool False ============== ============================= Description @@ -202,7 +202,7 @@ Parameters :initial_pose: ============== ================================== - Type Default + Type Default -------------- ---------------------------------- Pose2D {x: 0.0, y: 0.0, z: 0.0, yaw: 0.0} ============== ================================== @@ -213,9 +213,9 @@ Parameters :max_beams: ============== ============================= - Type Default + Type Default -------------- ----------------------------- - int 60 + int 60 ============== ============================= Description @@ -224,9 +224,9 @@ Parameters :max_particles: ============== ============================= - Type Default + Type Default -------------- ----------------------------- - int 2000 + int 2000 ============== ============================= Description @@ -235,9 +235,9 @@ Parameters :min_particles: ============== ============================= - Type Default + Type Default -------------- ----------------------------- - int 500 + int 500 ============== ============================= Description @@ -246,9 +246,9 @@ Parameters :odom_frame_id: ============== ============================= - Type Default + Type Default -------------- ----------------------------- - string "odom" + string "odom" ============== ============================= Description @@ -257,9 +257,9 @@ Parameters :pf_err: ============== ============================= - Type Default + Type Default -------------- ----------------------------- - double 0.05 + double 0.05 ============== ============================= Description @@ -268,9 +268,9 @@ Parameters :pf_z: ============== ============================= - Type Default + Type Default -------------- ----------------------------- - double 0.99 + double 0.99 ============== ============================= Description @@ -279,9 +279,9 @@ Parameters :recovery_alpha_fast: ============== ============================= - Type Default + Type Default -------------- ----------------------------- - double 0.0 + double 0.0 ============== ============================= Description @@ -290,9 +290,9 @@ Parameters :recovery_alpha_slow: ============== ============================= - Type Default + Type Default -------------- ----------------------------- - double 0.0 + double 0.0 ============== ============================= Description @@ -302,9 +302,9 @@ Parameters :resample_interval: ============== ============================= - Type Default + Type Default -------------- ----------------------------- - int 1 + int 1 ============== ============================= Description @@ -313,9 +313,9 @@ Parameters :robot_model_type: ============== ============================= - Type Default + Type Default -------------- ----------------------------- - string "nav2_amcl::DifferentialMotionModel" + string "nav2_amcl::DifferentialMotionModel" ============== ============================= Description @@ -327,9 +327,9 @@ Parameters :save_pose_rate: ============== ============================= - Type Default + Type Default -------------- ----------------------------- - double 0.5 + double 0.5 ============== ============================= Description @@ -338,9 +338,9 @@ Parameters :sigma_hit: ============== ============================= - Type Default + Type Default -------------- ----------------------------- - double 0.2 + double 0.2 ============== ============================= Description @@ -349,9 +349,9 @@ Parameters :tf_broadcast: ============== ============================= - Type Default + Type Default -------------- ----------------------------- - bool True + bool True ============== ============================= Description @@ -360,9 +360,9 @@ Parameters :transform_tolerance: ============== ============================= - Type Default + Type Default -------------- ----------------------------- - double 1.0 + double 1.0 ============== ============================= Description @@ -371,9 +371,9 @@ Parameters :update_min_a: ============== ============================= - Type Default + Type Default -------------- ----------------------------- - double 0.2 + double 0.2 ============== ============================= Description @@ -382,9 +382,9 @@ Parameters :update_min_d: ============== ============================= - Type Default + Type Default -------------- ----------------------------- - double 0.25 + double 0.25 ============== ============================= Description @@ -393,9 +393,9 @@ Parameters :z_hit: ============== ============================= - Type Default + Type Default -------------- ----------------------------- - double 0.5 + double 0.5 ============== ============================= Description @@ -404,9 +404,9 @@ Parameters :z_max: ============== ============================= - Type Default + Type Default -------------- ----------------------------- - double 0.05 + double 0.05 ============== ============================= Description @@ -415,9 +415,9 @@ Parameters :z_rand: ============== ============================= - Type Default + Type Default -------------- ----------------------------- - double 0.5 + double 0.5 ============== ============================= Description @@ -426,9 +426,9 @@ Parameters :z_short: ============== ============================= - Type Default + Type Default -------------- ----------------------------- - double 0.005 + double 0.005 ============== ============================= Description @@ -437,20 +437,20 @@ Parameters :always_reset_initial_pose: ============== ============================= - Type Default + Type Default -------------- ----------------------------- - bool False + bool False ============== ============================= Description Requires that AMCL is provided an initial pose either via topic or initial_pose* parameter (with parameter set_initial_pose: true) when reset. Otherwise, by default AMCL will use the last known pose to initialize. - + :scan_topic: ============== ============================= - Type Default + Type Default -------------- ----------------------------- - string scan + string scan ============== ============================= Description diff --git a/configuration/packages/configuring-behavior-server.rst b/configuration/packages/configuring-behavior-server.rst index 6cd8ba351e..643c72f9b8 100644 --- a/configuration/packages/configuring-behavior-server.rst +++ b/configuration/packages/configuring-behavior-server.rst @@ -73,7 +73,7 @@ Behavior Server Parameters :action_server_result_timeout: - ====== ======= ======= + ====== ======= ======= Type Default Unit ------ ------- ------- double 10.0 seconds @@ -82,7 +82,7 @@ Behavior Server Parameters Description The timeout value (in seconds) for action servers to discard a goal handle if a result has not been produced. This used to default to 15 minutes in rcl but was changed to 10 seconds in this `PR #1012 `_, which may be less than - some actions in Nav2 take to run. For most applications, this should not need to be adjusted as long as the actions within the server do not exceed this deadline. + some actions in Nav2 take to run. For most applications, this should not need to be adjusted as long as the actions within the server do not exceed this deadline. This issue has been raised with OSRF to find another solution to avoid active goal timeouts for bookkeeping, so this is a semi-temporary workaround :transform_tolerance: diff --git a/configuration/packages/configuring-collision-monitor.rst b/configuration/packages/configuring-collision-monitor.rst index f943297f98..c4e3300b22 100644 --- a/configuration/packages/configuring-collision-monitor.rst +++ b/configuration/packages/configuring-collision-monitor.rst @@ -20,4 +20,3 @@ The nodes listed below are inside the ``nav2_collision_monitor`` package. See th collision_monitor/configuring-collision-monitor-node.rst collision_monitor/configuring-collision-detector-node.rst - diff --git a/configuration/packages/configuring-constrained-smoother.rst b/configuration/packages/configuring-constrained-smoother.rst index 48f732f7a5..94d692b4c0 100644 --- a/configuration/packages/configuring-constrained-smoother.rst +++ b/configuration/packages/configuring-constrained-smoother.rst @@ -31,7 +31,7 @@ Smoother Server Parameters :reversing_enabled: ============== =========================== - Type Default + Type Default -------------- --------------------------- bool true ============== =========================== @@ -42,7 +42,7 @@ Smoother Server Parameters :path_downsampling_factor: ============== =========================== - Type Default + Type Default -------------- --------------------------- int 1 ============== =========================== @@ -53,7 +53,7 @@ Smoother Server Parameters :path_upsampling_factor: ============== =========================== - Type Default + Type Default -------------- --------------------------- int 1 ============== =========================== @@ -64,7 +64,7 @@ Smoother Server Parameters :keep_start_orientation: ============== =========================== - Type Default + Type Default -------------- --------------------------- bool true ============== =========================== @@ -75,7 +75,7 @@ Smoother Server Parameters :keep_goal_orientation: ============== =========================== - Type Default + Type Default -------------- --------------------------- bool true ============== =========================== @@ -86,7 +86,7 @@ Smoother Server Parameters :minimum_turning_radius: ============== =========================== - Type Default + Type Default -------------- --------------------------- double 0.4 ============== =========================== @@ -97,7 +97,7 @@ Smoother Server Parameters :w_curve: ============== =========================== - Type Default + Type Default -------------- --------------------------- double 30.0 ============== =========================== @@ -108,7 +108,7 @@ Smoother Server Parameters :w_dist: ============== =========================== - Type Default + Type Default -------------- --------------------------- double 0.0 ============== =========================== @@ -119,7 +119,7 @@ Smoother Server Parameters :w_smooth: ============== =========================== - Type Default + Type Default -------------- --------------------------- double 2000000.0 ============== =========================== @@ -130,7 +130,7 @@ Smoother Server Parameters :w_cost: ============== =========================== - Type Default + Type Default -------------- --------------------------- double 0.015 ============== =========================== @@ -141,7 +141,7 @@ Smoother Server Parameters :w_cost_cusp_multiplier: ============== =========================== - Type Default + Type Default -------------- --------------------------- double 3.0 ============== =========================== @@ -149,7 +149,7 @@ Smoother Server Parameters Description Option to use higher weight during forward/reverse direction change, helping optimizer to converge or add an extra obstacle avoidance at these problematic segments. Following image depicts improvement of the path with ``w_cost_cusp_multiplier`` (green) compared to one without it (purple). Original path has cyan color. - + .. image:: images/constrained_smoother/w_cost_cusp_multiplier.png :height: 429px :width: 282px @@ -158,7 +158,7 @@ Smoother Server Parameters :cusp_zone_length: ============== =========================== - Type Default + Type Default -------------- --------------------------- double 2.5 ============== =========================== @@ -169,7 +169,7 @@ Smoother Server Parameters :cost_check_points: =============== =========================== - Type Default + Type Default --------------- --------------------------- array of double [] =============== =========================== @@ -185,11 +185,11 @@ Smoother Server Parameters :height: 284px :width: 176px :align: center - + :optimizer.max_iterations: ============== =========================== - Type Default + Type Default -------------- --------------------------- int 100 ============== =========================== @@ -200,7 +200,7 @@ Smoother Server Parameters :optimizer.debug_optimizer: ============== =========================== - Type Default + Type Default -------------- --------------------------- bool false ============== =========================== @@ -211,7 +211,7 @@ Smoother Server Parameters :optimizer.linear_solver_type: ============== =========================== - Type Default + Type Default -------------- --------------------------- string "SPARSE_NORMAL_CHOLESKY" ============== =========================== @@ -222,7 +222,7 @@ Smoother Server Parameters :optimizer.gradient_tol: ============== =========================== - Type Default + Type Default -------------- --------------------------- bool 1e-10 ============== =========================== @@ -233,7 +233,7 @@ Smoother Server Parameters :optimizer.fn_tol: ============== =========================== - Type Default + Type Default -------------- --------------------------- bool 1e-7 ============== =========================== @@ -244,7 +244,7 @@ Smoother Server Parameters :optimizer.param_tol: ============== =========================== - Type Default + Type Default -------------- --------------------------- bool 1e-15 ============== =========================== @@ -287,4 +287,4 @@ Example debug_optimizer: false # print debug info gradient_tol: 5e3 fn_tol: 1.0e-15 - param_tol: 1.0e-20 \ No newline at end of file + param_tol: 1.0e-20 diff --git a/configuration/packages/configuring-controller-server.rst b/configuration/packages/configuring-controller-server.rst index 68ae28fc61..6fd51a2ac0 100644 --- a/configuration/packages/configuring-controller-server.rst +++ b/configuration/packages/configuring-controller-server.rst @@ -19,7 +19,7 @@ Parameters ============== ======= Type Default -------------- ------- - double 20.0 + double 20.0 ============== ======= Description @@ -30,7 +30,7 @@ Parameters ============== ======= Type Default -------------- ------- - bool false + bool false ============== ======= Description @@ -49,7 +49,7 @@ Parameters :action_server_result_timeout: - ====== ======= ======= + ====== ======= ======= Type Default Unit ------ ------- ------- double 10.0 seconds @@ -58,15 +58,15 @@ Parameters Description The timeout value (in seconds) for action servers to discard a goal handle if a result has not been produced. This used to default to 15 minutes in rcl but was changed to 10 seconds in this `PR #1012 `_, which may be less than - some actions in Nav2 take to run. For most applications, this should not need to be adjusted as long as the actions within the server do not exceed this deadline. + some actions in Nav2 take to run. For most applications, this should not need to be adjusted as long as the actions within the server do not exceed this deadline. This issue has been raised with OSRF to find another solution to avoid active goal timeouts for bookkeeping, so this is a semi-temporary workaround :controller_plugins: ============== ============== - Type Default + Type Default -------------- -------------- - vector ['FollowPath'] + vector ['FollowPath'] ============== ============== Description @@ -138,9 +138,9 @@ Parameters :min_x_velocity_threshold: ============== ============================= - Type Default + Type Default -------------- ----------------------------- - double 0.0001 + double 0.0001 ============== ============================= Description @@ -150,9 +150,9 @@ Parameters :min_y_velocity_threshold: ============== ============================= - Type Default + Type Default -------------- ----------------------------- - double 0.0001 + double 0.0001 ============== ============================= Description @@ -162,21 +162,21 @@ Parameters :min_theta_velocity_threshold: ============== ============================= - Type Default + Type Default -------------- ----------------------------- - double 0.0001 + double 0.0001 ============== ============================= Description The controller server filters the velocity portion of the odometry messages received before sending them to the controller plugin. Odometry values below this threshold (in rad/s) will be set to 0.0. - + :failure_tolerance: ============== ============================= - Type Default + Type Default -------------- ----------------------------- - double 0.0 + double 0.0 ============== ============================= Description @@ -217,7 +217,7 @@ Parameters Whether to use geometry_msgs::msg::Twist or geometry_msgs::msg::TwistStamped velocity data. True uses TwistStamped, false uses Twist. Note: This parameter is default ``false`` in Jazzy or older! Kilted or newer uses ``TwistStamped`` by default. - + :bond_heartbeat_period: ============== ============================= diff --git a/configuration/packages/configuring-costmaps.rst b/configuration/packages/configuring-costmaps.rst index cd30178e14..087b0aec00 100644 --- a/configuration/packages/configuring-costmaps.rst +++ b/configuration/packages/configuring-costmaps.rst @@ -8,7 +8,7 @@ Source code on Github_. .. _Github: https://github.com/ros-navigation/navigation2/tree/main/nav2_costmap_2d The Costmap 2D package implements a 2D grid-based costmap for environmental representations and a number of sensor processing plugins (AI outputs, depth sensor obstacle buffering, semantic information, etc). -It is used in the planner and controller servers for creating the space to check for collisions or higher cost areas to negotiate around. +It is used in the planner and controller servers for creating the space to check for collisions or higher cost areas to negotiate around. Costmap2D ROS Parameters ************************ @@ -18,7 +18,7 @@ Costmap2D ROS Parameters ============== ======= Type Default -------------- ------- - bool False + bool False ============== ======= Description @@ -29,7 +29,7 @@ Costmap2D ROS Parameters ============== ======= Type Default -------------- ------- - double 0.01 + double 0.01 ============== ======= Description @@ -40,7 +40,7 @@ Costmap2D ROS Parameters ============== ======= Type Default -------------- ------- - vector "[]" + vector "[]" ============== ======= Description @@ -51,7 +51,7 @@ Costmap2D ROS Parameters ============== ======= Type Default -------------- ------- - string "map" + string "map" ============== ======= Description @@ -62,7 +62,7 @@ Costmap2D ROS Parameters ============== ======= Type Default -------------- ------- - int 5 + int 5 ============== ======= Description @@ -73,7 +73,7 @@ Costmap2D ROS Parameters ============== ======= Type Default -------------- ------- - int 5 + int 5 ============== ======= Description @@ -84,7 +84,7 @@ Costmap2D ROS Parameters ============== ======= Type Default -------------- ------- - int 100 + int 100 ============== ======= Description @@ -95,7 +95,7 @@ Costmap2D ROS Parameters ============== ======= Type Default -------------- ------- - double 0.0 + double 0.0 ============== ======= Description @@ -106,7 +106,7 @@ Costmap2D ROS Parameters ============== ======= Type Default -------------- ------- - string "" + string "" ============== ======= Description @@ -117,7 +117,7 @@ Costmap2D ROS Parameters ============== ======= Type Default -------------- ------- - double 0.0 + double 0.0 ============== ======= Description @@ -128,7 +128,7 @@ Costmap2D ROS Parameters ============== ======= Type Default -------------- ------- - double 0.0 + double 0.0 ============== ======= Description @@ -139,7 +139,7 @@ Costmap2D ROS Parameters ============== ======= Type Default -------------- ------- - double 1.0 + double 1.0 ============== ======= Description @@ -150,7 +150,7 @@ Costmap2D ROS Parameters ============== ======= Type Default -------------- ------- - double 0.1 + double 0.1 ============== ======= Description @@ -159,9 +159,9 @@ Costmap2D ROS Parameters :robot_base_frame: ============== =========== - Type Default + Type Default -------------- ----------- - string "base_link" + string "base_link" ============== =========== Description @@ -172,7 +172,7 @@ Costmap2D ROS Parameters ============== ======= Type Default -------------- ------- - double 0.1 + double 0.1 ============== ======= Description @@ -183,7 +183,7 @@ Costmap2D ROS Parameters ============== ======= Type Default -------------- ------- - bool False + bool False ============== ======= Description @@ -194,7 +194,7 @@ Costmap2D ROS Parameters ============== ======= Type Default -------------- ------- - bool False + bool False ============== ======= Description @@ -205,7 +205,7 @@ Costmap2D ROS Parameters ============== ======= Type Default -------------- ------- - double 0.3 + double 0.3 ============== ======= Description @@ -216,7 +216,7 @@ Costmap2D ROS Parameters ============== ======= Type Default -------------- ------- - double 60.0 + double 60.0 ============== ======= Description @@ -227,7 +227,7 @@ Costmap2D ROS Parameters ============== ======= Type Default -------------- ------- - bool True + bool True ============== ======= Description @@ -238,7 +238,7 @@ Costmap2D ROS Parameters ============== ======= Type Default -------------- ------- - int 255 + int 255 ============== ======= Description @@ -249,7 +249,7 @@ Costmap2D ROS Parameters ============== ======= Type Default -------------- ------- - double 5.0 + double 5.0 ============== ======= Description @@ -260,7 +260,7 @@ Costmap2D ROS Parameters ============== ======= Type Default -------------- ------- - bool False + bool False ============== ======= Description diff --git a/configuration/packages/configuring-coverage-server.rst b/configuration/packages/configuring-coverage-server.rst index 9879f757e5..6013f90081 100644 --- a/configuration/packages/configuring-coverage-server.rst +++ b/configuration/packages/configuring-coverage-server.rst @@ -19,9 +19,9 @@ Parameters :action_server_result_timeout: ============== ============== - Type Default + Type Default -------------- -------------- - double 10.0 + double 10.0 ============== ============== Description @@ -96,7 +96,7 @@ Parameters :default_headland_type: ============== ========== - Type Default + Type Default -------------- ---------- string "CONSTANT" ============== ========== @@ -107,7 +107,7 @@ Parameters :default_headland_width: ============== ========== - Type Default + Type Default -------------- ---------- double 2.0 ============== ========== @@ -118,7 +118,7 @@ Parameters :default_swath_type: ============== =============== - Type Default + Type Default -------------- --------------- string "LENGTH" ============== =============== @@ -130,7 +130,7 @@ Parameters :default_swath_angle_type: ============== =============== - Type Default + Type Default -------------- --------------- double 1.7e-2 ============== =============== @@ -141,7 +141,7 @@ Parameters :default_step_angle: ============== =============== - Type Default + Type Default -------------- --------------- double 1.7e-2 ============== =============== @@ -152,7 +152,7 @@ Parameters :default_swath_angle: ============== =============== - Type Default + Type Default -------------- --------------- double N/A ============== =============== @@ -163,7 +163,7 @@ Parameters :default_route_type: ============== =============== - Type Default + Type Default -------------- --------------- string "BOUSTROPHEDON" ============== =============== @@ -185,7 +185,7 @@ Parameters :default_spiral_n: ============== =============== - Type Default + Type Default -------------- --------------- int 4 ============== =============== @@ -197,7 +197,7 @@ Parameters :default_path_continuity_type: ============== ============ - Type Default + Type Default -------------- ------------ string "CONTINUOUS" ============== ============ @@ -208,7 +208,7 @@ Parameters :default_path_type: ============== ============ - Type Default + Type Default -------------- ------------ string "DUBIN" ============== ============ @@ -219,18 +219,18 @@ Parameters :default_turn_point_distance: ============== ============ - Type Default + Type Default -------------- ------------ double 0.1 ============== ============ Description - Distance between points on the plan and route for sending back in paths (e.g. 0.1m). This impacts the density of the output turn paths and the overall nav paths. + Distance between points on the plan and route for sending back in paths (e.g. 0.1m). This impacts the density of the output turn paths and the overall nav paths. :default_offset: ============== ============ - Type Default + Type Default -------------- ------------ double 0.0 ============== ============ @@ -241,7 +241,7 @@ Parameters :order_ids: ============== ============ - Type Default + Type Default -------------- ------------ bool 0.0 ============== ============ diff --git a/configuration/packages/configuring-docking-server.rst b/configuration/packages/configuring-docking-server.rst index 36415bb6c7..37b13dc507 100644 --- a/configuration/packages/configuring-docking-server.rst +++ b/configuration/packages/configuring-docking-server.rst @@ -7,7 +7,7 @@ Source code on Github_. .. _Github: https://github.com/open-navigation/opennav_docking -The Docking Server in ``opennav_docking`` implements a server for docking and undocking a robot. +The Docking Server in ``opennav_docking`` implements a server for docking and undocking a robot. This can be from Charging stations (i.e. docks) or non-charging docking locations such as the end of a conveyor belt or a pallet. It uses plugin `dock` implementations for a particular platform to enable the framework to generalize to robots of many different kinematic models, charging methods, sensor modalities, charging-type, and so on. It can also handle a database of many different docking locations and dock models to handle a heterogeneous environment. @@ -21,9 +21,9 @@ Parameters :controller_frequency: ============== ============== - Type Default + Type Default -------------- -------------- - double 50.0 + double 50.0 ============== ============== Description @@ -32,9 +32,9 @@ Parameters :initial_perception_timeout: ============== ============== - Type Default + Type Default -------------- -------------- - double 5.0 + double 5.0 ============== ============== Description @@ -43,9 +43,9 @@ Parameters :wait_charge_timeout: ============== ============== - Type Default + Type Default -------------- -------------- - double 5.0 + double 5.0 ============== ============== Description @@ -54,9 +54,9 @@ Parameters :dock_approach_timeout: ============== ============== - Type Default + Type Default -------------- -------------- - double 30.0 + double 30.0 ============== ============== Description @@ -65,9 +65,9 @@ Parameters :undock_linear_tolerance: ============== ============== - Type Default + Type Default -------------- -------------- - double 0.05 + double 0.05 ============== ============== Description @@ -76,9 +76,9 @@ Parameters :undock_angular_tolerance: ============== ============== - Type Default + Type Default -------------- -------------- - double 0.05 + double 0.05 ============== ============== Description @@ -87,9 +87,9 @@ Parameters :max_retries: ============== ============== - Type Default + Type Default -------------- -------------- - int 3 + int 3 ============== ============== Description @@ -98,9 +98,9 @@ Parameters :base_frame: ============== ============== - Type Default + Type Default -------------- -------------- - string "base_link" + string "base_link" ============== ============== Description @@ -109,9 +109,9 @@ Parameters :fixed_frame: ============== ============== - Type Default + Type Default -------------- -------------- - string "odom" + string "odom" ============== ============== Description @@ -120,9 +120,9 @@ Parameters :dock_backwards: ============== ============== - Type Default + Type Default -------------- -------------- - bool false + bool false ============== ============== Description @@ -131,9 +131,9 @@ Parameters :dock_prestaging_tolerance: ============== ============== - Type Default + Type Default -------------- -------------- - double 0.5 + double 0.5 ============== ============== Description @@ -142,9 +142,9 @@ Parameters :dock_plugins: ============== ============== - Type Default + Type Default -------------- -------------- - vector N/A + vector N/A ============== ============== Description @@ -153,9 +153,9 @@ Parameters :dock_database: ============== ============== - Type Default + Type Default -------------- -------------- - string N/A + string N/A ============== ============== Description @@ -165,9 +165,9 @@ Parameters :docks: ============== ============== - Type Default + Type Default -------------- -------------- - vector N/A + vector N/A ============== ============== Description @@ -176,9 +176,9 @@ Parameters :navigator_bt_xml: ============== ============== - Type Default + Type Default -------------- -------------- - string "" + string "" ============== ============== Description @@ -187,9 +187,9 @@ Parameters :controller.k_phi: ============== ============== - Type Default + Type Default -------------- -------------- - double 3.0 + double 3.0 ============== ============== Description @@ -198,9 +198,9 @@ Parameters :controller.k_delta: ============== ============== - Type Default + Type Default -------------- -------------- - double 2.0 + double 2.0 ============== ============== Description @@ -209,9 +209,9 @@ Parameters :controller.beta: ============== ============== - Type Default + Type Default -------------- -------------- - double 0.4 + double 0.4 ============== ============== Description @@ -220,9 +220,9 @@ Parameters :controller.lambda: ============== ============== - Type Default + Type Default -------------- -------------- - double 2.0 + double 2.0 ============== ============== Description @@ -231,9 +231,9 @@ Parameters :controller.v_linear_min: ============== ============== - Type Default + Type Default -------------- -------------- - double 0.1 + double 0.1 ============== ============== Description @@ -242,9 +242,9 @@ Parameters :controller.v_linear_max: ============== ============== - Type Default + Type Default -------------- -------------- - double 0.24 + double 0.24 ============== ============== Description @@ -253,9 +253,9 @@ Parameters :controller.v_angular_max: ============== ============== - Type Default + Type Default -------------- -------------- - double 0.75 + double 0.75 ============== ============== Description @@ -264,9 +264,9 @@ Parameters :controller.slowdown_radius: ============== ============== - Type Default + Type Default -------------- -------------- - double 0.25 + double 0.25 ============== ============== Description @@ -275,9 +275,9 @@ Parameters :controller.use_collision_detection: ============== ============== - Type Default + Type Default -------------- -------------- - bool true + bool true ============== ============== Description @@ -286,9 +286,9 @@ Parameters :controller.costmap_topic: ============== =========================== - Type Default + Type Default -------------- --------------------------- - string "local_costmap/costmap_raw" + string "local_costmap/costmap_raw" ============== =========================== Description @@ -297,9 +297,9 @@ Parameters :controller.footprint_topic: ============== =================================== - Type Default + Type Default -------------- ----------------------------------- - string "local_costmap/published_footprint" + string "local_costmap/published_footprint" ============== =================================== Description @@ -361,7 +361,7 @@ Simple Charging Dock is a provided charging dock plugin that can handle many doc :.staging_x_offset: ============== ============== - Type Default + Type Default -------------- -------------- double -0.7 ============== ============== @@ -372,7 +372,7 @@ Simple Charging Dock is a provided charging dock plugin that can handle many doc :.staging_yaw_offset: ============== ============== - Type Default + Type Default -------------- -------------- double 0.0 ============== ============== @@ -383,9 +383,9 @@ Simple Charging Dock is a provided charging dock plugin that can handle many doc :.use_battery_status: ============== ============== - Type Default + Type Default -------------- -------------- - bool true + bool true ============== ============== Description @@ -394,9 +394,9 @@ Simple Charging Dock is a provided charging dock plugin that can handle many doc :.use_external_detection_pose: ============== ============== - Type Default + Type Default -------------- -------------- - bool false + bool false ============== ============== Description @@ -405,9 +405,9 @@ Simple Charging Dock is a provided charging dock plugin that can handle many doc :.external_detection_timeout: ============== ============== - Type Default + Type Default -------------- -------------- - double 1.0 + double 1.0 ============== ============== Description @@ -417,9 +417,9 @@ Simple Charging Dock is a provided charging dock plugin that can handle many doc :.external_detection_translation_x: ============== ============== - Type Default + Type Default -------------- -------------- - double -0.20 + double -0.20 ============== ============== Description @@ -428,9 +428,9 @@ Simple Charging Dock is a provided charging dock plugin that can handle many doc :.external_detection_translation_y: ============== ============== - Type Default + Type Default -------------- -------------- - double 0.0 + double 0.0 ============== ============== Description @@ -439,9 +439,9 @@ Simple Charging Dock is a provided charging dock plugin that can handle many doc :.external_detection_rotation_yaw: ============== ============== - Type Default + Type Default -------------- -------------- - double 0.0 + double 0.0 ============== ============== Description @@ -450,9 +450,9 @@ Simple Charging Dock is a provided charging dock plugin that can handle many doc :.external_detection_rotation_pitch: ============== ============== - Type Default + Type Default -------------- -------------- - double 1.57 + double 1.57 ============== ============== Description @@ -461,9 +461,9 @@ Simple Charging Dock is a provided charging dock plugin that can handle many doc :.external_detection_rotation_roll: ============== ============== - Type Default + Type Default -------------- -------------- - double -1.57 + double -1.57 ============== ============== Description @@ -472,9 +472,9 @@ Simple Charging Dock is a provided charging dock plugin that can handle many doc :.filter_coef: ============== ============== - Type Default + Type Default -------------- -------------- - double 0.1 + double 0.1 ============== ============== Description @@ -483,7 +483,7 @@ Simple Charging Dock is a provided charging dock plugin that can handle many doc :.charging_threshold: ============== ============== - Type Default + Type Default -------------- -------------- double 0.5 ============== ============== @@ -494,7 +494,7 @@ Simple Charging Dock is a provided charging dock plugin that can handle many doc :.use_stall_detection: ============== ============== - Type Default + Type Default -------------- -------------- bool false ============== ============== @@ -505,7 +505,7 @@ Simple Charging Dock is a provided charging dock plugin that can handle many doc :.stall_joint_names: ============== ============== - Type Default + Type Default -------------- -------------- vector N/A ============== ============== @@ -516,7 +516,7 @@ Simple Charging Dock is a provided charging dock plugin that can handle many doc :.stall_velocity_threshold: ============== ============== - Type Default + Type Default -------------- -------------- double 1.0 ============== ============== @@ -527,7 +527,7 @@ Simple Charging Dock is a provided charging dock plugin that can handle many doc :.stall_effort_threshold: ============== ============== - Type Default + Type Default -------------- -------------- double 1.0 ============== ============== @@ -538,7 +538,7 @@ Simple Charging Dock is a provided charging dock plugin that can handle many doc :.docking_threshold: ============== ============== - Type Default + Type Default -------------- -------------- double 0.05 ============== ============== diff --git a/configuration/packages/configuring-dwb-controller.rst b/configuration/packages/configuring-dwb-controller.rst index b3fb7a8962..8c17e86d7a 100644 --- a/configuration/packages/configuring-dwb-controller.rst +++ b/configuration/packages/configuring-dwb-controller.rst @@ -117,4 +117,3 @@ Example RotateToGoal.scale: 32.0 RotateToGoal.slowing_factor: 5.0 RotateToGoal.lookahead_time: -1.0 - diff --git a/configuration/packages/configuring-graceful-motion-controller.rst b/configuration/packages/configuring-graceful-motion-controller.rst index dd052a8015..01bdc6519d 100644 --- a/configuration/packages/configuring-graceful-motion-controller.rst +++ b/configuration/packages/configuring-graceful-motion-controller.rst @@ -17,9 +17,9 @@ Graceful Controller Parameters :transform_tolerance: ============== =========================== - Type Default + Type Default -------------- --------------------------- - double 0.1 + double 0.1 ============== =========================== Description @@ -28,7 +28,7 @@ Graceful Controller Parameters :max_lookahead: ============== ============================= - Type Default + Type Default -------------- ----------------------------- double 1.0 ============== ============================= @@ -39,7 +39,7 @@ Graceful Controller Parameters :min_lookahead: ============== ============================= - Type Default + Type Default -------------- ----------------------------- double 0.25 ============== ============================= @@ -61,7 +61,7 @@ Graceful Controller Parameters :k_phi: ============== ============================= - Type Default + Type Default -------------- ----------------------------- double 2.0 ============== ============================= @@ -72,7 +72,7 @@ Graceful Controller Parameters :k_delta: ============== ============================= - Type Default + Type Default -------------- ----------------------------- double 1.0 ============== ============================= @@ -83,7 +83,7 @@ Graceful Controller Parameters :beta: ============== ============================= - Type Default + Type Default -------------- ----------------------------- double 0.4 ============== ============================= @@ -94,9 +94,9 @@ Graceful Controller Parameters :lambda: ============== ============================= - Type Default + Type Default -------------- ----------------------------- - double 2.0 + double 2.0 ============== ============================= Description @@ -105,9 +105,9 @@ Graceful Controller Parameters :v_linear_min: ============== ============================= - Type Default + Type Default -------------- ----------------------------- - double 0.1 + double 0.1 ============== ============================= Description @@ -116,9 +116,9 @@ Graceful Controller Parameters :v_linear_max: ============== ============================= - Type Default + Type Default -------------- ----------------------------- - double 0.5 + double 0.5 ============== ============================= Description @@ -127,9 +127,9 @@ Graceful Controller Parameters :v_angular_max: ============== ============================= - Type Default + Type Default -------------- ----------------------------- - double 1.0 + double 1.0 ============== ============================= Description @@ -138,7 +138,7 @@ Graceful Controller Parameters :v_angular_min_in_place: ============== ============================= - Type Default + Type Default -------------- ----------------------------- double 0.25 ============== ============================= @@ -149,9 +149,9 @@ Graceful Controller Parameters :slowdown_radius: ============== ============================= - Type Default + Type Default -------------- ----------------------------- - double 1.5 + double 1.5 ============== ============================= Description @@ -160,9 +160,9 @@ Graceful Controller Parameters :initial_rotation: ============== ============================= - Type Default + Type Default -------------- ----------------------------- - bool true + bool true ============== ============================= Description @@ -171,7 +171,7 @@ Graceful Controller Parameters :initial_rotation_tolerance: ============== ============================= - Type Default + Type Default -------------- ----------------------------- double 0.75 ============== ============================= @@ -182,9 +182,9 @@ Graceful Controller Parameters :prefer_final_rotation: ============== ============================= - Type Default + Type Default -------------- ----------------------------- - bool true + bool true ============== ============================= Description @@ -193,9 +193,9 @@ Graceful Controller Parameters :rotation_scaling_factor: ============== ============================= - Type Default + Type Default -------------- ----------------------------- - double 0.5 + double 0.5 ============== ============================= Description @@ -204,9 +204,9 @@ Graceful Controller Parameters :allow_backward: ============== ============================= - Type Default + Type Default -------------- ----------------------------- - bool false + bool false ============== ============================= Description @@ -215,7 +215,7 @@ Graceful Controller Parameters :in_place_collision_tolerance: ============== ============================= - Type Default + Type Default -------------- ----------------------------- double 0.1 ============== ============================= diff --git a/configuration/packages/configuring-map-server.rst b/configuration/packages/configuring-map-server.rst index fec595bc51..daaa722366 100644 --- a/configuration/packages/configuring-map-server.rst +++ b/configuration/packages/configuring-map-server.rst @@ -146,7 +146,7 @@ Costmap Filter Info Server Parameters Description Multiplier of ``OccupancyGrid`` mask value -> filter space value linear conversion which is being proceeded as: ``filter_space_value = base + multiplier * mask_value`` - + :bond_heartbeat_period: ============== ============================= diff --git a/configuration/packages/configuring-mppic.rst b/configuration/packages/configuring-mppic.rst index 8a1c067671..a87ebe1005 100644 --- a/configuration/packages/configuring-mppic.rst +++ b/configuration/packages/configuring-mppic.rst @@ -33,9 +33,9 @@ MPPI Parameters :motion_model: ============== =========================== - Type Default + Type Default -------------- --------------------------- - string "DiffDrive" + string "DiffDrive" ============== =========================== Description @@ -44,9 +44,9 @@ MPPI Parameters :critics: ============== =========================== - Type Default + Type Default -------------- --------------------------- - string vector N/A + string vector N/A ============== =========================== Description @@ -55,9 +55,9 @@ MPPI Parameters :iteration_count: ============== =========================== - Type Default + Type Default -------------- --------------------------- - int 1 + int 1 ============== =========================== Description @@ -66,9 +66,9 @@ MPPI Parameters :batch_size: ============== =========================== - Type Default + Type Default -------------- --------------------------- - int 1000 + int 1000 ============== =========================== Description @@ -77,9 +77,9 @@ MPPI Parameters :time_steps: ============== =========================== - Type Default + Type Default -------------- --------------------------- - int 56 + int 56 ============== =========================== Description @@ -88,9 +88,9 @@ MPPI Parameters :model_dt: ============== =========================== - Type Default + Type Default -------------- --------------------------- - double 0.05 + double 0.05 ============== =========================== Description @@ -99,9 +99,9 @@ MPPI Parameters :vx_std: ============== =========================== - Type Default + Type Default -------------- --------------------------- - double 0.2 + double 0.2 ============== =========================== Description @@ -110,9 +110,9 @@ MPPI Parameters :vy_std: ============== =========================== - Type Default + Type Default -------------- --------------------------- - double 0.2 + double 0.2 ============== =========================== Description @@ -121,9 +121,9 @@ MPPI Parameters :wz_std: ============== =========================== - Type Default + Type Default -------------- --------------------------- - double 0.2 + double 0.2 ============== =========================== Description @@ -132,9 +132,9 @@ MPPI Parameters :vx_max: ============== =========================== - Type Default + Type Default -------------- --------------------------- - double 0.5 + double 0.5 ============== =========================== Description @@ -143,9 +143,9 @@ MPPI Parameters :vy_max: ============== =========================== - Type Default + Type Default -------------- --------------------------- - double 0.5 + double 0.5 ============== =========================== Description @@ -154,9 +154,9 @@ MPPI Parameters :vx_min: ============== =========================== - Type Default + Type Default -------------- --------------------------- - double -0.35 + double -0.35 ============== =========================== Description @@ -165,9 +165,9 @@ MPPI Parameters :wz_max: ============== =========================== - Type Default + Type Default -------------- --------------------------- - double 1.9 + double 1.9 ============== =========================== Description @@ -176,9 +176,9 @@ MPPI Parameters :ax_max: ============== =========================== - Type Default + Type Default -------------- --------------------------- - double 3.0 + double 3.0 ============== =========================== Description @@ -187,9 +187,9 @@ MPPI Parameters :ay_max: ============== =========================== - Type Default + Type Default -------------- --------------------------- - double 3.0 + double 3.0 ============== =========================== Description @@ -198,9 +198,9 @@ MPPI Parameters :ax_min: ============== =========================== - Type Default + Type Default -------------- --------------------------- - double -3.0 + double -3.0 ============== =========================== Description @@ -209,9 +209,9 @@ MPPI Parameters :az_max: ============== =========================== - Type Default + Type Default -------------- --------------------------- - double 3.5 + double 3.5 ============== =========================== Description @@ -220,7 +220,7 @@ MPPI Parameters :temperature: ============== =========================== - Type Default + Type Default -------------- --------------------------- double 0.3 ============== =========================== @@ -231,18 +231,18 @@ MPPI Parameters :gamma: ============== =========================== - Type Default + Type Default -------------- --------------------------- double 0.015 ============== =========================== Description - A trade-off between smoothness (high) and low energy (low). This is a complex parameter that likely won't need to be changed from the default. See Section 3D-2 in "Information Theoretic Model Predictive Control: Theory and Applications to Autonomous Driving" for detailed information. + A trade-off between smoothness (high) and low energy (low). This is a complex parameter that likely won't need to be changed from the default. See Section 3D-2 in "Information Theoretic Model Predictive Control: Theory and Applications to Autonomous Driving" for detailed information. :visualize: ============== =========================== - Type Default + Type Default -------------- --------------------------- bool false ============== =========================== @@ -253,7 +253,7 @@ MPPI Parameters :retry_attempt_limit: ============== =========================== - Type Default + Type Default -------------- --------------------------- int 1 ============== =========================== @@ -264,7 +264,7 @@ MPPI Parameters :reset_period: ============== =========================== - Type Default + Type Default -------------- --------------------------- double 1.0 ============== =========================== @@ -275,9 +275,9 @@ MPPI Parameters :regenerate_noises: ============== =========================== - Type Default + Type Default -------------- --------------------------- - bool false + bool false ============== =========================== Description @@ -289,7 +289,7 @@ Trajectory Visualization :trajectory_step: ============== =========================== - Type Default + Type Default -------------- --------------------------- int 5 ============== =========================== @@ -300,13 +300,13 @@ Trajectory Visualization :time_step: ============== =========================== - Type Default + Type Default -------------- --------------------------- int 3 ============== =========================== Description - The step between points on trajectories to visualize to downsample trajectory density. + The step between points on trajectories to visualize to downsample trajectory density. Path Handler ------------ @@ -314,7 +314,7 @@ Path Handler :transform_tolerance: ============== =========================== - Type Default + Type Default -------------- --------------------------- double 0.1 ============== =========================== @@ -325,7 +325,7 @@ Path Handler :prune_distance: ============== =========================== - Type Default + Type Default -------------- --------------------------- double 1.5 ============== =========================== @@ -336,7 +336,7 @@ Path Handler :max_robot_pose_search_dist: ============== =========================== - Type Default + Type Default -------------- --------------------------- double Costmap size / 2 ============== =========================== @@ -347,7 +347,7 @@ Path Handler :enforce_path_inversion: ============== =========================== - Type Default + Type Default -------------- --------------------------- bool false ============== =========================== @@ -358,7 +358,7 @@ Path Handler :inversion_xy_tolerance: ============== =========================== - Type Default + Type Default -------------- --------------------------- double 0.2 ============== =========================== @@ -369,7 +369,7 @@ Path Handler :inversion_yaw_tolerance: ============== =========================== - Type Default + Type Default -------------- --------------------------- double 0.4 ============== =========================== @@ -383,7 +383,7 @@ Ackermann Motion Model :min_turning_r: ============== =========================== - Type Default + Type Default -------------- --------------------------- double 0.2 ============== =========================== @@ -400,7 +400,7 @@ This critic penalizes trajectories that have components outside of the set dynam :cost_weight: ============== =========================== - Type Default + Type Default -------------- --------------------------- double 4.0 ============== =========================== @@ -411,13 +411,13 @@ This critic penalizes trajectories that have components outside of the set dynam :cost_power: ============== =========================== - Type Default + Type Default -------------- --------------------------- int 1 ============== =========================== Description - Power order to apply to term. + Power order to apply to term. Goal Angle Critic ----------------- @@ -427,7 +427,7 @@ This critic incentivizes navigating to achieve the angle of the goal posewhen in :cost_weight: ============== =========================== - Type Default + Type Default -------------- --------------------------- double 3.0 ============== =========================== @@ -438,18 +438,18 @@ This critic incentivizes navigating to achieve the angle of the goal posewhen in :cost_power: ============== =========================== - Type Default + Type Default -------------- --------------------------- int 1 ============== =========================== Description - Power order to apply to term. + Power order to apply to term. :threshold_to_consider: ============== =========================== - Type Default + Type Default -------------- --------------------------- double 0.5 ============== =========================== @@ -465,7 +465,7 @@ This critic incentivizes navigating spatially towards the goal when in reasonabl :cost_weight: ============== =========================== - Type Default + Type Default -------------- --------------------------- double 5.0 ============== =========================== @@ -476,18 +476,18 @@ This critic incentivizes navigating spatially towards the goal when in reasonabl :cost_power: ============== =========================== - Type Default + Type Default -------------- --------------------------- int 1 ============== =========================== Description - Power order to apply to term. + Power order to apply to term. :threshold_to_consider: ============== =========================== - Type Default + Type Default -------------- --------------------------- double 1.4 ============== =========================== @@ -503,7 +503,7 @@ This critic incentivizes navigating away from obstacles and critical collisions :critical_weight: ============== =========================== - Type Default + Type Default -------------- --------------------------- double 20.0 ============== =========================== @@ -514,7 +514,7 @@ This critic incentivizes navigating away from obstacles and critical collisions :repulsion_weight: ============== =========================== - Type Default + Type Default -------------- --------------------------- double 1.5 ============== =========================== @@ -525,7 +525,7 @@ This critic incentivizes navigating away from obstacles and critical collisions :cost_power: ============== =========================== - Type Default + Type Default -------------- --------------------------- int 1 ============== =========================== @@ -536,7 +536,7 @@ This critic incentivizes navigating away from obstacles and critical collisions :consider_footprint: ============== =========================== - Type Default + Type Default -------------- --------------------------- bool false ============== =========================== @@ -547,7 +547,7 @@ This critic incentivizes navigating away from obstacles and critical collisions :collision_cost: ============== =========================== - Type Default + Type Default -------------- --------------------------- double 100000.0 ============== =========================== @@ -558,7 +558,7 @@ This critic incentivizes navigating away from obstacles and critical collisions :collision_margin_distance: ============== =========================== - Type Default + Type Default -------------- --------------------------- double 0.10 ============== =========================== @@ -569,7 +569,7 @@ This critic incentivizes navigating away from obstacles and critical collisions :near_goal_distance: ============== =========================== - Type Default + Type Default -------------- --------------------------- double 0.50 ============== =========================== @@ -580,7 +580,7 @@ This critic incentivizes navigating away from obstacles and critical collisions :cost_scaling_factor: ============== =========================== - Type Default + Type Default -------------- --------------------------- double 10.0 ============== =========================== @@ -591,7 +591,7 @@ This critic incentivizes navigating away from obstacles and critical collisions :inflation_radius: ============== =========================== - Type Default + Type Default -------------- --------------------------- double 0.55 ============== =========================== @@ -619,7 +619,7 @@ This critic incentivizes navigating away from obstacles and critical collisions :cost_weight: ============== =========================== - Type Default + Type Default -------------- --------------------------- double 3.81 ============== =========================== @@ -630,7 +630,7 @@ This critic incentivizes navigating away from obstacles and critical collisions :cost_power: ============== =========================== - Type Default + Type Default -------------- --------------------------- int 1 ============== =========================== @@ -641,7 +641,7 @@ This critic incentivizes navigating away from obstacles and critical collisions :consider_footprint: ============== =========================== - Type Default + Type Default -------------- --------------------------- bool false ============== =========================== @@ -652,7 +652,7 @@ This critic incentivizes navigating away from obstacles and critical collisions :collision_cost: ============== =========================== - Type Default + Type Default -------------- --------------------------- double 1000000.0 ============== =========================== @@ -663,7 +663,7 @@ This critic incentivizes navigating away from obstacles and critical collisions :critical_cost: ============== =========================== - Type Default + Type Default -------------- --------------------------- double 300.0 ============== =========================== @@ -675,7 +675,7 @@ This critic incentivizes navigating away from obstacles and critical collisions :near_goal_distance: ============== =========================== - Type Default + Type Default -------------- --------------------------- double 0.50 ============== =========================== @@ -697,7 +697,7 @@ This critic incentivizes navigating away from obstacles and critical collisions :trajectory_point_step: ============== =========================== - Type Default + Type Default -------------- --------------------------- int 2 ============== =========================== @@ -713,7 +713,7 @@ This critic incentivizes aligning with the global path, if relevant. It does not :cost_weight: ============== =========================== - Type Default + Type Default -------------- --------------------------- double 10.0 ============== =========================== @@ -724,18 +724,18 @@ This critic incentivizes aligning with the global path, if relevant. It does not :cost_power: ============== =========================== - Type Default + Type Default -------------- --------------------------- int 1 ============== =========================== Description - Power order to apply to term. + Power order to apply to term. :threshold_to_consider: ============== =========================== - Type Default + Type Default -------------- --------------------------- double 0.5 ============== =========================== @@ -746,7 +746,7 @@ This critic incentivizes aligning with the global path, if relevant. It does not :offset_from_furthest: ============== =========================== - Type Default + Type Default -------------- --------------------------- int 20 ============== =========================== @@ -757,7 +757,7 @@ This critic incentivizes aligning with the global path, if relevant. It does not :max_path_occupancy_ratio: ============== =========================== - Type Default + Type Default -------------- --------------------------- double 0.07 ============== =========================== @@ -768,7 +768,7 @@ This critic incentivizes aligning with the global path, if relevant. It does not :use_path_orientations: ============== =========================== - Type Default + Type Default -------------- --------------------------- bool false ============== =========================== @@ -779,7 +779,7 @@ This critic incentivizes aligning with the global path, if relevant. It does not :trajectory_point_step: ============== =========================== - Type Default + Type Default -------------- --------------------------- int 4 ============== =========================== @@ -796,7 +796,7 @@ This critic penalizes trajectories at a high relative angle to the path. This he :cost_weight: ============== =========================== - Type Default + Type Default -------------- --------------------------- double 2.2 ============== =========================== @@ -807,7 +807,7 @@ This critic penalizes trajectories at a high relative angle to the path. This he :cost_power: ============== =========================== - Type Default + Type Default -------------- --------------------------- int 1 ============== =========================== @@ -818,7 +818,7 @@ This critic penalizes trajectories at a high relative angle to the path. This he :threshold_to_consider: ============== =========================== - Type Default + Type Default -------------- --------------------------- double 0.5 ============== =========================== @@ -829,7 +829,7 @@ This critic penalizes trajectories at a high relative angle to the path. This he :offset_from_furthest: ============== =========================== - Type Default + Type Default -------------- --------------------------- int 20 ============== =========================== @@ -840,7 +840,7 @@ This critic penalizes trajectories at a high relative angle to the path. This he :max_angle_to_furthest: ============== =========================== - Type Default + Type Default -------------- --------------------------- double 0.785398 ============== =========================== @@ -851,7 +851,7 @@ This critic penalizes trajectories at a high relative angle to the path. This he :mode: ============== =========================== - Type Default + Type Default -------------- --------------------------- int 0 ============== =========================== @@ -868,7 +868,7 @@ This critic incentivizes making progress along the path. This is what drives the :cost_weight: ============== =========================== - Type Default + Type Default -------------- --------------------------- double 5.0 ============== =========================== @@ -879,7 +879,7 @@ This critic incentivizes making progress along the path. This is what drives the :cost_power: ============== =========================== - Type Default + Type Default -------------- --------------------------- int 1 ============== =========================== @@ -890,7 +890,7 @@ This critic incentivizes making progress along the path. This is what drives the :threshold_to_consider: ============== =========================== - Type Default + Type Default -------------- --------------------------- double 1.4 ============== =========================== @@ -901,7 +901,7 @@ This critic incentivizes making progress along the path. This is what drives the :offset_from_furthest: ============== =========================== - Type Default + Type Default -------------- --------------------------- int 6 ============== =========================== @@ -917,7 +917,7 @@ This critic incentivizes moving in the forward direction, rather than reversing. :cost_weight: ============== =========================== - Type Default + Type Default -------------- --------------------------- double 5.0 ============== =========================== @@ -928,7 +928,7 @@ This critic incentivizes moving in the forward direction, rather than reversing. :cost_power: ============== =========================== - Type Default + Type Default -------------- --------------------------- int 1 ============== =========================== @@ -939,7 +939,7 @@ This critic incentivizes moving in the forward direction, rather than reversing. :threshold_to_consider: ============== =========================== - Type Default + Type Default -------------- --------------------------- double 0.5 ============== =========================== @@ -955,7 +955,7 @@ This critic penalizes unnecessary 'twisting' with holonomic vehicles. It adds a :cost_weight: ============== =========================== - Type Default + Type Default -------------- --------------------------- double 10.0 ============== =========================== @@ -966,7 +966,7 @@ This critic penalizes unnecessary 'twisting' with holonomic vehicles. It adds a :cost_power: ============== =========================== - Type Default + Type Default -------------- --------------------------- int 1 ============== =========================== @@ -982,7 +982,7 @@ This critic penalizes velocities that fall below the deadband threshold, helping :cost_weight: =============== =========================== - Type Default + Type Default --------------- --------------------------- double 35.0 =============== =========================== @@ -993,7 +993,7 @@ This critic penalizes velocities that fall below the deadband threshold, helping :cost_power: =============== =========================== - Type Default + Type Default --------------- --------------------------- int 1 =============== =========================== @@ -1004,7 +1004,7 @@ This critic penalizes velocities that fall below the deadband threshold, helping :deadband_velocities: =============== =========================== - Type Default + Type Default --------------- --------------------------- array of double [0.05, 0.05, 0.05] =============== =========================== @@ -1149,10 +1149,10 @@ The Path Follow critic cannot drive velocities greater than the projectable dist Obstacle, Inflation Layer, and Path Following --------------------------------------------- -There also exists a relationship between the costmap configurations and the Obstacle critic configurations. If the Obstacle critic is not well tuned with the costmap parameters (inflation radius, scale) it can cause the robot to wobble significantly as it attempts to take finitely lower-cost trajectories with a slightly lower cost in exchange for jerky motion. It may also perform awkward maneuvers when in free-space to try to maximize time in a small pocket of 0-cost over a more natural motion which involves moving into some low-costed region. Finally, it may generally refuse to go into costed space at all when starting in a free 0-cost space if the gain is set disproportionately higher than the Path Follow scoring to encourage the robot to move along the path. This is due to the critic cost of staying in free space becoming more attractive than entering even lightly costed space in exchange for progression along the task. +There also exists a relationship between the costmap configurations and the Obstacle critic configurations. If the Obstacle critic is not well tuned with the costmap parameters (inflation radius, scale) it can cause the robot to wobble significantly as it attempts to take finitely lower-cost trajectories with a slightly lower cost in exchange for jerky motion. It may also perform awkward maneuvers when in free-space to try to maximize time in a small pocket of 0-cost over a more natural motion which involves moving into some low-costed region. Finally, it may generally refuse to go into costed space at all when starting in a free 0-cost space if the gain is set disproportionately higher than the Path Follow scoring to encourage the robot to move along the path. This is due to the critic cost of staying in free space becoming more attractive than entering even lightly costed space in exchange for progression along the task. Thus, care should be taken to select weights of the obstacle critic in conjunction with the costmap inflation radius and scale so that a robot does not have such issues. How I (Steve, your friendly neighborhood navigator) tuned this was to first create the appropriate obstacle critic behavior desirable in conjunction with the inflation layer parameters. Its worth noting that the Obstacle critic converts the cost into a distance from obstacles, so the nature of the distribution of costs in the inflation isn't overly significant. However, the inflation radius and the scale will define the cost at the end of the distribution where free-space meets the lowest cost value within the radius. So testing for quality behavior when going over that threshold should be considered. As you increase or decrease your weights on the Obstacle, you may notice the aforementioned behaviors (e.g. won't overcome free to non-free threshold). To overcome them, increase the FollowPath critic cost to increase the desire for the trajectory planner to continue moving towards the goal. Make sure to not overshoot this though, keep them balanced. A desirable outcome is smooth motion roughly in the center of spaces without significant close interactions with obstacles. It shouldn't be perfectly following a path yet nor should the output velocity be wobbling jaggedly. -Once you have your obstacle avoidance behavior tuned and matched with an appropriate path following penalty, tune the Path Align critic to align with the path. If you design exact-path-alignment behavior, its possible to skip the obstacle critic step as highly tuning the system to follow the path will give it less ability to deviate to avoid obstacles (though it'll slow and stop). Tuning the critic weight for the Obstacle critic high will do the job to avoid near-collisions but the repulsion weight is largely unnecessary to you. For others wanting more dynamic behavior, it *can* be beneficial to slowly lower the weight on the obstacle critic to give the path alignment critic some more room to work. If your path was generated with a cost-aware planner (like all provided by Nav2) and providing paths sufficiently far from obstacles for your satisfaction, the impact of a slightly reduced Obstacle critic with a Path Alignment critic will do you well. Not over-weighting the path align critic will allow the robot to deviate from the path to get around dynamic obstacles in the scene or other obstacles not previous considered during path planning. It is subjective as to the best behavior for your application, but it has been shown that MPPI can be an exact path tracker and/or avoid dynamic obstacles very fluidly and everywhere in between. The defaults provided are in the generally right regime for a balanced initial trade-off. +Once you have your obstacle avoidance behavior tuned and matched with an appropriate path following penalty, tune the Path Align critic to align with the path. If you design exact-path-alignment behavior, its possible to skip the obstacle critic step as highly tuning the system to follow the path will give it less ability to deviate to avoid obstacles (though it'll slow and stop). Tuning the critic weight for the Obstacle critic high will do the job to avoid near-collisions but the repulsion weight is largely unnecessary to you. For others wanting more dynamic behavior, it *can* be beneficial to slowly lower the weight on the obstacle critic to give the path alignment critic some more room to work. If your path was generated with a cost-aware planner (like all provided by Nav2) and providing paths sufficiently far from obstacles for your satisfaction, the impact of a slightly reduced Obstacle critic with a Path Alignment critic will do you well. Not over-weighting the path align critic will allow the robot to deviate from the path to get around dynamic obstacles in the scene or other obstacles not previous considered during path planning. It is subjective as to the best behavior for your application, but it has been shown that MPPI can be an exact path tracker and/or avoid dynamic obstacles very fluidly and everywhere in between. The defaults provided are in the generally right regime for a balanced initial trade-off. diff --git a/configuration/packages/configuring-navfn.rst b/configuration/packages/configuring-navfn.rst index 3835f9b7dc..c3efaa23e2 100644 --- a/configuration/packages/configuring-navfn.rst +++ b/configuration/packages/configuring-navfn.rst @@ -19,7 +19,7 @@ Parameters ============== ======= Type Default -------------- ------- - double 0.5 + double 0.5 ============== ======= Description @@ -28,9 +28,9 @@ Parameters :````.use_astar: ==== ======= - Type Default + Type Default ---- ------- - bool False + bool False ==== ======= Description @@ -39,25 +39,25 @@ Parameters :````.allow_unknown: ==== ======= - Type Default + Type Default ---- ------- - bool True + bool True ==== ======= Description Whether to allow planning in unknown space. - + :````.use_final_approach_orientation: ====== ======= - Type Default + Type Default ------ ------- - bool false + bool false ====== ======= Description If true, the last pose of the path generated by the planner will have its orientation set to the approach orientation, i.e. the orientation of the vector connecting the last two points of the path - + Example ******* .. code-block:: yaml diff --git a/configuration/packages/configuring-planner-server.rst b/configuration/packages/configuring-planner-server.rst index 81042ed30c..752ac77c9c 100644 --- a/configuration/packages/configuring-planner-server.rst +++ b/configuration/packages/configuring-planner-server.rst @@ -17,9 +17,9 @@ Parameters :planner_plugins: ============== ============== - Type Default + Type Default -------------- -------------- - vector ['GridBased'] + vector ['GridBased'] ============== ============== Description @@ -52,7 +52,7 @@ Parameters :action_server_result_timeout: - ====== ======= ======= + ====== ======= ======= Type Default Unit ------ ------- ------- double 10.0 seconds @@ -61,9 +61,9 @@ Parameters Description The timeout value (in seconds) for action servers to discard a goal handle if a result has not been produced. This used to default to 15 minutes in rcl but was changed to 10 seconds in this `PR #1012 `_, which may be less than - some actions in Nav2 take to run. For most applications, this should not need to be adjusted as long as the actions within the server do not exceed this deadline. + some actions in Nav2 take to run. For most applications, this should not need to be adjusted as long as the actions within the server do not exceed this deadline. This issue has been raised with OSRF to find another solution to avoid active goal timeouts for bookkeeping, so this is a semi-temporary workaround - + :bond_heartbeat_period: ============== ============================= diff --git a/configuration/packages/configuring-regulated-pp.rst b/configuration/packages/configuring-regulated-pp.rst index 38a726997d..ab048b00c3 100644 --- a/configuration/packages/configuring-regulated-pp.rst +++ b/configuration/packages/configuring-regulated-pp.rst @@ -25,9 +25,9 @@ Regulated Pure Pursuit Parameters :desired_linear_vel: ============== =========================== - Type Default + Type Default -------------- --------------------------- - double 0.5 + double 0.5 ============== =========================== Description @@ -36,7 +36,7 @@ Regulated Pure Pursuit Parameters :lookahead_dist: ============== ============================= - Type Default + Type Default -------------- ----------------------------- double 0.6 ============== ============================= @@ -47,9 +47,9 @@ Regulated Pure Pursuit Parameters :min_lookahead_dist: ============== ============================= - Type Default + Type Default -------------- ----------------------------- - double 0.3 + double 0.3 ============== ============================= Description @@ -58,9 +58,9 @@ Regulated Pure Pursuit Parameters :max_lookahead_dist: ============== ============================= - Type Default + Type Default -------------- ----------------------------- - double 0.9 + double 0.9 ============== ============================= Description @@ -69,7 +69,7 @@ Regulated Pure Pursuit Parameters :lookahead_time: ============== ============================= - Type Default + Type Default -------------- ----------------------------- double 1.5 ============== ============================= @@ -80,9 +80,9 @@ Regulated Pure Pursuit Parameters :rotate_to_heading_angular_vel: ============== ============================= - Type Default + Type Default -------------- ----------------------------- - double 1.8 + double 1.8 ============== ============================= Description @@ -91,9 +91,9 @@ Regulated Pure Pursuit Parameters :transform_tolerance: ============== ============================= - Type Default + Type Default -------------- ----------------------------- - double 0.1 + double 0.1 ============== ============================= Description @@ -102,9 +102,9 @@ Regulated Pure Pursuit Parameters :use_velocity_scaled_lookahead_dist: ============== ============================= - Type Default + Type Default -------------- ----------------------------- - bool false + bool false ============== ============================= Description @@ -113,31 +113,31 @@ Regulated Pure Pursuit Parameters :min_approach_linear_velocity: ============== ============================= - Type Default + Type Default -------------- ----------------------------- - double 0.05 + double 0.05 ============== ============================= Description - The minimum velocity (m/s) threshold to apply when approaching the goal to ensure progress. Must be ``> 0.01``. + The minimum velocity (m/s) threshold to apply when approaching the goal to ensure progress. Must be ``> 0.01``. :approach_velocity_scaling_dist: ============== ============================= - Type Default + Type Default -------------- ----------------------------- - double 0.6 + double 0.6 ============== ============================= Description - The distance (m) left on the path at which to start slowing down. Should be less than the half the costmap width. + The distance (m) left on the path at which to start slowing down. Should be less than the half the costmap width. :use_collision_detection: ============== ============================= - Type Default + Type Default -------------- ----------------------------- - bool true + bool true ============== ============================= Description @@ -146,9 +146,9 @@ Regulated Pure Pursuit Parameters :max_allowed_time_to_collision_up_to_carrot: ============== ============================= - Type Default + Type Default -------------- ----------------------------- - double 1.0 + double 1.0 ============== ============================= Description @@ -157,9 +157,9 @@ Regulated Pure Pursuit Parameters :use_regulated_linear_velocity_scaling: ============== ============================= - Type Default + Type Default -------------- ----------------------------- - bool true + bool true ============== ============================= Description @@ -168,9 +168,9 @@ Regulated Pure Pursuit Parameters :use_cost_regulated_linear_velocity_scaling: ============== ============================= - Type Default + Type Default -------------- ----------------------------- - bool true + bool true ============== ============================= Description @@ -179,9 +179,9 @@ Regulated Pure Pursuit Parameters :regulated_linear_scaling_min_radius: ============== ============================= - Type Default + Type Default -------------- ----------------------------- - double 0.90 + double 0.90 ============== ============================= Description @@ -190,20 +190,20 @@ Regulated Pure Pursuit Parameters :regulated_linear_scaling_min_speed: ============== ============================= - Type Default + Type Default -------------- ----------------------------- - double 0.25 + double 0.25 ============== ============================= Description - The minimum speed (m/s) for which any of the regulated heuristics can send, to ensure process is still achievable even in high cost spaces with high curvature. Must be ``> 0.1``. + The minimum speed (m/s) for which any of the regulated heuristics can send, to ensure process is still achievable even in high cost spaces with high curvature. Must be ``> 0.1``. :use_fixed_curvature_lookahead: ============== ============================= - Type Default + Type Default -------------- ----------------------------- - bool false + bool false ============== ============================= Description @@ -212,9 +212,9 @@ Regulated Pure Pursuit Parameters :curvature_lookahead_dist: ============== ============================= - Type Default + Type Default -------------- ----------------------------- - double 0.6 + double 0.6 ============== ============================= Description @@ -223,22 +223,22 @@ Regulated Pure Pursuit Parameters :use_rotate_to_heading: ============== ============================= - Type Default + Type Default -------------- ----------------------------- - bool true + bool true ============== ============================= Description - Whether to enable rotating to rough heading and goal orientation when using holonomic planners. Recommended on for all robot types that can rotate in place. + Whether to enable rotating to rough heading and goal orientation when using holonomic planners. Recommended on for all robot types that can rotate in place. Note: both ``use_rotate_to_heading`` and ``allow_reversing`` cannot be set to ``true`` at the same time as it would result in ambiguous situations. :allow_reversing: ============== ============================= - Type Default + Type Default -------------- ----------------------------- - bool false + bool false ============== ============================= Description @@ -247,9 +247,9 @@ Regulated Pure Pursuit Parameters :rotate_to_heading_min_angle: ============== ============================= - Type Default + Type Default -------------- ----------------------------- - double 0.785 + double 0.785 ============== ============================= Description @@ -258,9 +258,9 @@ Regulated Pure Pursuit Parameters :max_angular_accel: ============== ============================= - Type Default + Type Default -------------- ----------------------------- - double 3.2 + double 3.2 ============== ============================= Description diff --git a/configuration/packages/configuring-rotation-shim-controller.rst b/configuration/packages/configuring-rotation-shim-controller.rst index 6e28a1dce1..c6d3af8894 100644 --- a/configuration/packages/configuring-rotation-shim-controller.rst +++ b/configuration/packages/configuring-rotation-shim-controller.rst @@ -7,7 +7,7 @@ Source code on Github_. .. _Github: https://github.com/ros-navigation/navigation2/tree/main/nav2_rotation_shim_controller -The ``nav2_rotation_shim_controller`` will check the rough heading difference with respect to the robot and a newly received path. If within a threshold, it will pass the request onto the ``primary_controller`` to execute the task. If it is outside of the threshold, this controller will rotate the robot in place towards that path heading. Once it is within the tolerance, it will then pass off control-execution from this rotation shim controller onto the primary controller plugin. At this point, the robot's main plugin will take control for a smooth hand off into the task. +The ``nav2_rotation_shim_controller`` will check the rough heading difference with respect to the robot and a newly received path. If within a threshold, it will pass the request onto the ``primary_controller`` to execute the task. If it is outside of the threshold, this controller will rotate the robot in place towards that path heading. Once it is within the tolerance, it will then pass off control-execution from this rotation shim controller onto the primary controller plugin. At this point, the robot's main plugin will take control for a smooth hand off into the task. When the ``rotate_to_goal_heading`` parameter is set to true, this controller is also able to take back control of the robot when reaching the XY goal tolerance of the goal checker. In this case, the robot will rotate towards the goal heading until the goal checker validate the goal and ends the current navigation task. @@ -15,7 +15,7 @@ The ``RotationShimController`` is most suitable for: - Robots that can rotate in place, such as differential and omnidirectional robots. - Preference to rotate in place when starting to track a new path that is at a significantly different heading than the robot's current heading -- or when tuning your controller for its task makes tight rotations difficult. -- Using planners that are non-kinematically feasible, such as NavFn, Theta\*, or Smac 2D (Feasible planners such as Smac Hybrid-A* and State Lattice will start search from the robot's actual starting heading, requiring no rotation since their paths are guaranteed drivable by physical constraints). +- Using planners that are non-kinematically feasible, such as NavFn, Theta\*, or Smac 2D (Feasible planners such as Smac Hybrid-A* and State Lattice will start search from the robot's actual starting heading, requiring no rotation since their paths are guaranteed drivable by physical constraints). See the package's ``README`` for more complete information. @@ -33,7 +33,7 @@ Rotation Shim Controller Parameters :angular_dist_threshold: ============== =========================== - Type Default + Type Default -------------- --------------------------- double 0.785 ============== =========================== @@ -44,7 +44,7 @@ Rotation Shim Controller Parameters :angular_disengage_threshold: ============== =========================== - Type Default + Type Default -------------- --------------------------- double 0.3925 ============== =========================== @@ -55,7 +55,7 @@ Rotation Shim Controller Parameters :forward_sampling_distance: ============== ============================= - Type Default + Type Default -------------- ----------------------------- double 0.5 ============== ============================= @@ -66,9 +66,9 @@ Rotation Shim Controller Parameters :rotate_to_heading_angular_vel: ============== ============================= - Type Default + Type Default -------------- ----------------------------- - double 1.8 + double 1.8 ============== ============================= Description @@ -77,9 +77,9 @@ Rotation Shim Controller Parameters :primary_controller: ============== ============================= - Type Default + Type Default -------------- ----------------------------- - string N/A + string N/A ============== ============================= Description @@ -88,7 +88,7 @@ Rotation Shim Controller Parameters :max_angular_accel: ============== ============================= - Type Default + Type Default -------------- ----------------------------- double 3.2 ============== ============================= @@ -99,7 +99,7 @@ Rotation Shim Controller Parameters :simulate_ahead_time: ============== ============================= - Type Default + Type Default -------------- ----------------------------- double 1.0 ============== ============================= diff --git a/configuration/packages/configuring-savitzky-golay-smoother.rst b/configuration/packages/configuring-savitzky-golay-smoother.rst index a45880081b..ca4e1674b8 100644 --- a/configuration/packages/configuring-savitzky-golay-smoother.rst +++ b/configuration/packages/configuring-savitzky-golay-smoother.rst @@ -22,9 +22,9 @@ Savitzky-Golay Smoother Parameters :do_refinement: ============== =========================== - Type Default + Type Default -------------- --------------------------- - bool True + bool True ============== =========================== Description @@ -33,9 +33,9 @@ Savitzky-Golay Smoother Parameters :refinement_num: ============== =========================== - Type Default + Type Default -------------- --------------------------- - int 2 + int 2 ============== =========================== Description diff --git a/configuration/packages/configuring-simple-smoother.rst b/configuration/packages/configuring-simple-smoother.rst index 41f926ab9e..333f8fce1a 100644 --- a/configuration/packages/configuring-simple-smoother.rst +++ b/configuration/packages/configuring-simple-smoother.rst @@ -9,7 +9,7 @@ Source code on Github_. The Simple Smoother is a Smoother Server plugin that will take in an input path and smooth it using a simple and fast smoothing technique. It weights the initial path points and the smoothed path points to create a balanced result where the path retains its high level characteristics but reduces oscillations or jagged features. -It is recommended this is paired ONLY with infeasible (e.g. 2D) planners, since this algorithm will break any kinematically feasible conditions. It is recommended users use the Constrained Smoother plugin instead with feasible plans. +It is recommended this is paired ONLY with infeasible (e.g. 2D) planners, since this algorithm will break any kinematically feasible conditions. It is recommended users use the Constrained Smoother plugin instead with feasible plans. Simple Smoother Parameters ************************** @@ -17,20 +17,20 @@ Simple Smoother Parameters :tolerance: ============== =========================== - Type Default + Type Default -------------- --------------------------- - double 1.0e-10 + double 1.0e-10 ============== =========================== Description - Change in parameter values across path to terminate smoothing + Change in parameter values across path to terminate smoothing :do_refinement: ============== =========================== - Type Default + Type Default -------------- --------------------------- - bool True + bool True ============== =========================== Description @@ -39,9 +39,9 @@ Simple Smoother Parameters :refinement_num: ============== =========================== - Type Default + Type Default -------------- --------------------------- - int 2 + int 2 ============== =========================== Description @@ -50,9 +50,9 @@ Simple Smoother Parameters :max_its: ============== =========================== - Type Default + Type Default -------------- --------------------------- - int 1000 + int 1000 ============== =========================== Description @@ -61,9 +61,9 @@ Simple Smoother Parameters :w_data: ============== =========================== - Type Default + Type Default -------------- --------------------------- - double 0.2 + double 0.2 ============== =========================== Description @@ -72,7 +72,7 @@ Simple Smoother Parameters :w_smooth: ============== =========================== - Type Default + Type Default -------------- --------------------------- double 0.3 ============== =========================== diff --git a/configuration/packages/configuring-smac-planner.rst b/configuration/packages/configuring-smac-planner.rst index 136d7cb3b2..3d940fb43f 100644 --- a/configuration/packages/configuring-smac-planner.rst +++ b/configuration/packages/configuring-smac-planner.rst @@ -28,7 +28,7 @@ The ``nav2_smac_planner`` package contains an optimized templated A* search algo We support circular differential-drive and omni-directional drive robots using the ``SmacPlanner2D`` planner which implements a cost-aware A* planner. We support car-like (ackermann) and legged vehicles using the ``SmacPlannerHybrid`` plugin which implements a Hybrid-A* planner. We support non-circular, arbitrary shaped, any model vehicles using the ``SmacPlannerLattice`` plugin which implements a State Lattice planner (e.g. omni, diff, ackermann, legged, custom). It contains control sets and generators for ackermann, legged, differential drive and omnidirectional vehicles, but you may provide your own for another robot type or to have different planning behaviors. -The last two plugins are both **kinematically feasible** and support **reversing**. They have performance similar to its 2D counter parts like 2D-A* and NavFn via highly optimized heuristic functions and efficient programming. An example of the 3 planners can be seen below, planning a roughly 75 m path. +The last two plugins are both **kinematically feasible** and support **reversing**. They have performance similar to its 2D counter parts like 2D-A* and NavFn via highly optimized heuristic functions and efficient programming. An example of the 3 planners can be seen below, planning a roughly 75 m path. - Hybrid-A* computed the path in 144ms - State Lattice computed the path in 113ms diff --git a/configuration/packages/configuring-smoother-server.rst b/configuration/packages/configuring-smoother-server.rst index 532dc41a66..318ff18ae8 100644 --- a/configuration/packages/configuring-smoother-server.rst +++ b/configuration/packages/configuring-smoother-server.rst @@ -16,9 +16,9 @@ Smoother Server Parameters :costmap_topic: ============== =========================== - Type Default + Type Default -------------- --------------------------- - string "global_costmap/costmap_raw" + string "global_costmap/costmap_raw" ============== =========================== Description @@ -27,9 +27,9 @@ Smoother Server Parameters :footprint_topic: ============== =================================== - Type Default + Type Default -------------- ----------------------------------- - string "global_costmap/published_footprint" + string "global_costmap/published_footprint" ============== =================================== Description @@ -38,9 +38,9 @@ Smoother Server Parameters :transform_tolerance: ============== ============================= - Type Default + Type Default -------------- ----------------------------- - double 0.1 + double 0.1 ============== ============================= Description @@ -48,7 +48,7 @@ Smoother Server Parameters :action_server_result_timeout: - ====== ======= ======= + ====== ======= ======= Type Default Unit ------ ------- ------- double 10.0 seconds @@ -57,15 +57,15 @@ Smoother Server Parameters Description The timeout value (in seconds) for action servers to discard a goal handle if a result has not been produced. This used to default to 15 minutes in rcl but was changed to 10 seconds in this `PR #1012 `_, which may be less than - some actions in Nav2 take to run. For most applications, this should not need to be adjusted as long as the actions within the server do not exceed this deadline. + some actions in Nav2 take to run. For most applications, this should not need to be adjusted as long as the actions within the server do not exceed this deadline. This issue has been raised with OSRF to find another solution to avoid active goal timeouts for bookkeeping, so this is a semi-temporary workaround :robot_base_frame: ============== ============================= - Type Default + Type Default -------------- ----------------------------- - string "base_link" + string "base_link" ============== ============================= Description @@ -74,7 +74,7 @@ Smoother Server Parameters :smoother_plugins: ============== ================================= - Type Default + Type Default -------------- --------------------------------- vector {"nav2_smoother::SimpleSmoother"} ============== ================================= @@ -98,7 +98,7 @@ Smoother Server Parameters plugin: "nav2_smoother::SimpleSmoother" .. - + :bond_heartbeat_period: ============== ============================= diff --git a/configuration/packages/configuring-thetastar.rst b/configuration/packages/configuring-thetastar.rst index 5bf01797d7..362520ff25 100644 --- a/configuration/packages/configuring-thetastar.rst +++ b/configuration/packages/configuring-thetastar.rst @@ -9,7 +9,7 @@ Theta Star Planner Theta Star Planner implements the Theta* path planner meant to plan any-angled line-segment focused paths using A*. -For the below example the planner took ~46ms (averaged value) to compute the path of 87.5m - +For the below example the planner took ~46ms (averaged value) to compute the path of 87.5m - .. image:: thetastar/00-37.png :width: 640px @@ -24,36 +24,36 @@ Parameters The parameters of the planner are: -:````.how_many_corners: +:````.how_many_corners: ============== ======= Type Default -------------- ------- - int 8 + int 8 ============== ======= Description To choose between 4-connected (up, down, left, right) and 8-connected (all the adjacent cells) graph expansions, the accepted values are 4 and 8 -:```` .w_euc_cost: +:```` .w_euc_cost: ============== ======= Type Default -------------- ------- - double 1.0 + double 1.0 ============== ======= Description - Weight applied on the length of the path. + Weight applied on the length of the path. -:````.w_traversal_cost: - +:````.w_traversal_cost: + ============== ======= Type Default -------------- ------- - double 2.0 + double 2.0 ============== ======= Description @@ -62,9 +62,9 @@ The parameters of the planner are: :````.use_final_approach_orientation: ====== ======= - Type Default + Type Default ------ ------- - bool false + bool false ====== ======= Description @@ -73,9 +73,9 @@ The parameters of the planner are: :````.allow_unknown: ==== ======= - Type Default + Type Default ---- ------- - bool True + bool True ==== ======= Description @@ -84,9 +84,9 @@ The parameters of the planner are: :````.terminal_checking_interval: ==== ======= - Type Default + Type Default ---- ------- - int 5000 + int 5000 ==== ======= Description @@ -94,13 +94,13 @@ The parameters of the planner are: .. Note:: Do go through the README file available on this repo's link to develop a better understanding of how you could tune this planner. - This planner requires you to tune the `cost_scaling_factor` parameter of your costmap too, to get good results. + This planner requires you to tune the `cost_scaling_factor` parameter of your costmap too, to get good results. Example ******* .. code-block:: yaml - + planner_server: ros__parameters: expected_planner_frequency: 20.0 diff --git a/configuration/packages/configuring-velocity-smoother.rst b/configuration/packages/configuring-velocity-smoother.rst index 26a9fc3dad..0e4f0a2908 100644 --- a/configuration/packages/configuring-velocity-smoother.rst +++ b/configuration/packages/configuring-velocity-smoother.rst @@ -21,7 +21,7 @@ Velocity Smoother Parameters ============== ======= Type Default -------------- ------- - bool false + bool false ============== ======= Description @@ -30,7 +30,7 @@ Velocity Smoother Parameters :smoothing_frequency: ============== =========================== - Type Default + Type Default -------------- --------------------------- double 20.0 ============== =========================== @@ -41,7 +41,7 @@ Velocity Smoother Parameters :scale_velocities: ============== =========================== - Type Default + Type Default -------------- --------------------------- bool false ============== =========================== @@ -52,7 +52,7 @@ Velocity Smoother Parameters :feedback: ============== =========================== - Type Default + Type Default -------------- --------------------------- string "OPEN_LOOP" ============== =========================== @@ -63,7 +63,7 @@ Velocity Smoother Parameters :max_velocity: ============== =========================== - Type Default + Type Default -------------- --------------------------- vector [0.5, 0.0, 2.5] ============== =========================== @@ -74,7 +74,7 @@ Velocity Smoother Parameters :min_velocity: ============== =========================== - Type Default + Type Default -------------- --------------------------- vector [-0.5, 0.0, -2.5] ============== =========================== @@ -85,7 +85,7 @@ Velocity Smoother Parameters :deadband_velocity: ============== =========================== - Type Default + Type Default -------------- --------------------------- vector [0.0, 0.0, 0.0] ============== =========================== @@ -96,7 +96,7 @@ Velocity Smoother Parameters :velocity_timeout: ============== =========================== - Type Default + Type Default -------------- --------------------------- double 1.0 ============== =========================== @@ -107,7 +107,7 @@ Velocity Smoother Parameters :max_accel: ============== =========================== - Type Default + Type Default -------------- --------------------------- vector [2.5, 0.0, 3.2] ============== =========================== @@ -118,7 +118,7 @@ Velocity Smoother Parameters :max_decel: ============== =========================== - Type Default + Type Default -------------- --------------------------- vector [-2.5, 0.0, -3.2] ============== =========================== @@ -129,7 +129,7 @@ Velocity Smoother Parameters :odom_topic: ============== =========================== - Type Default + Type Default -------------- --------------------------- string "odom" ============== =========================== @@ -140,7 +140,7 @@ Velocity Smoother Parameters :odom_duration: ============== =========================== - Type Default + Type Default -------------- --------------------------- double 0.1 ============== =========================== diff --git a/configuration/packages/configuring-waypoint-follower.rst b/configuration/packages/configuring-waypoint-follower.rst index ac113d764a..29ec8a77bc 100644 --- a/configuration/packages/configuring-waypoint-follower.rst +++ b/configuration/packages/configuring-waypoint-follower.rst @@ -18,9 +18,9 @@ Parameters :stop_on_failure: ==== ======= - Type Default + Type Default ---- ------- - bool true + bool true ==== ======= Description @@ -29,9 +29,9 @@ Parameters :loop_rate: ==== ======= - Type Default + Type Default ---- ------- - int 20 + int 20 ==== ======= Description @@ -51,7 +51,7 @@ Parameters :action_server_result_timeout: - ====== ======= ======= + ====== ======= ======= Type Default Unit ------ ------- ------- double 900.0 seconds @@ -60,7 +60,7 @@ Parameters Description The timeout value (in seconds) for action servers to discard a goal handle if a result has not been produced. This used to default to 15 minutes in rcl but was changed to 10 seconds in this `PR #1012 `_, which may be less than - some actions in Nav2 take to run. For most applications, this should not need to be adjusted as long as the actions within the server do not exceed this deadline. + some actions in Nav2 take to run. For most applications, this should not need to be adjusted as long as the actions within the server do not exceed this deadline. This issue has been raised with OSRF to find another solution to avoid active goal timeouts for bookkeeping, so this is a semi-temporary workaround :bond_heartbeat_period: diff --git a/configuration/packages/costmap-plugins/inflation.rst b/configuration/packages/costmap-plugins/inflation.rst index 5828715292..0ad9918cbb 100644 --- a/configuration/packages/costmap-plugins/inflation.rst +++ b/configuration/packages/costmap-plugins/inflation.rst @@ -11,9 +11,9 @@ This layer places an exponential decay functions around obstacles to increase co :````.enabled: ==== ======= - Type Default + Type Default ---- ------- - bool True + bool True ==== ======= Description @@ -22,9 +22,9 @@ This layer places an exponential decay functions around obstacles to increase co :````.inflation_radius: ====== ======= - Type Default + Type Default ------ ------- - double 0.55 + double 0.55 ====== ======= Description @@ -33,9 +33,9 @@ This layer places an exponential decay functions around obstacles to increase co :````.cost_scaling_factor: ====== ======= - Type Default + Type Default ------ ------- - double 10.0 + double 10.0 ====== ======= Description @@ -45,9 +45,9 @@ This layer places an exponential decay functions around obstacles to increase co :````.inflate_unknown: ==== ======= - Type Default + Type Default ---- ------- - bool False + bool False ==== ======= Description @@ -57,9 +57,9 @@ This layer places an exponential decay functions around obstacles to increase co :````.inflate_around_unknown: ==== ======= - Type Default + Type Default ---- ------- - bool False + bool False ==== ======= Description diff --git a/configuration/packages/costmap-plugins/keepout_filter.rst b/configuration/packages/costmap-plugins/keepout_filter.rst index eb6746ec3f..3a8445d9e7 100644 --- a/configuration/packages/costmap-plugins/keepout_filter.rst +++ b/configuration/packages/costmap-plugins/keepout_filter.rst @@ -5,7 +5,7 @@ Keepout Filter Parameters Keepout Filter - is a Costmap Filter that enforces robot to avoid keepout areas or stay on preferred lanes, by updating corresponding costmap layer using filter mask information. -Note: As Costmap Filters does not have the inflation layer applied to them (since inflation is not sensible for a speed or other non-occupation zone type), it may be beneficial to add a separate inflation layer into the vector of filters when using only a keepout zone. Some planners (e.g. Smac Feasible) will use the cost of the center point for a collision checking optimization before doing full SE2 footprint checks. Without inflation, the planner will not respect the Keepout Zone on it extremities -- but will still respect it for the robot centers. If you wish to have a Keepout Zone for any part of the robot base while using a feasible planner, please enable the inflation layer. +Note: As Costmap Filters does not have the inflation layer applied to them (since inflation is not sensible for a speed or other non-occupation zone type), it may be beneficial to add a separate inflation layer into the vector of filters when using only a keepout zone. Some planners (e.g. Smac Feasible) will use the cost of the center point for a collision checking optimization before doing full SE2 footprint checks. Without inflation, the planner will not respect the Keepout Zone on it extremities -- but will still respect it for the robot centers. If you wish to have a Keepout Zone for any part of the robot base while using a feasible planner, please enable the inflation layer. ``: is the corresponding plugin name selected for this type. diff --git a/configuration/packages/costmap-plugins/obstacle.rst b/configuration/packages/costmap-plugins/obstacle.rst index 037f0662d1..40e3d9a099 100644 --- a/configuration/packages/costmap-plugins/obstacle.rst +++ b/configuration/packages/costmap-plugins/obstacle.rst @@ -12,9 +12,9 @@ This costmap layer implements a plugin that uses 2D raycasting for 2D lidars, de :````.enabled: ==== ======= - Type Default + Type Default ---- ------- - bool True + bool True ==== ======= Description @@ -23,9 +23,9 @@ This costmap layer implements a plugin that uses 2D raycasting for 2D lidars, de :````.footprint_clearing_enabled: ==== ======= - Type Default + Type Default ---- ------- - bool True + bool True ==== ======= Description @@ -34,9 +34,9 @@ This costmap layer implements a plugin that uses 2D raycasting for 2D lidars, de :````.max_obstacle_height: ====== ======= - Type Default + Type Default ------ ------- - double 2.0 + double 2.0 ====== ======= Description @@ -45,9 +45,9 @@ This costmap layer implements a plugin that uses 2D raycasting for 2D lidars, de :````.combination_method: ====== ======= - Type Default + Type Default ------ ------- - int 1 + int 1 ====== ======= Description @@ -55,9 +55,9 @@ This costmap layer implements a plugin that uses 2D raycasting for 2D lidars, de | 0 - Overwrite: Overwrite master costmap with every valid observation. - | 1 - Max: Sets the new value to the maximum of the master_grid's value and this layer's value. + | 1 - Max: Sets the new value to the maximum of the master_grid's value and this layer's value. | This is the default. - + | 2 - MaxWithoutUnknownOverwrite: Sets the new value to the maximum of the master_grid's | value and this layer's value. If the master value is NO_INFORMATION, it is NOT overwritten. | It can be used to make sure that the static map is the dominant source of information, and @@ -67,9 +67,9 @@ This costmap layer implements a plugin that uses 2D raycasting for 2D lidars, de :````.observation_sources: ============== ======= - Type Default + Type Default -------------- ------- - vector {""} + vector {""} ============== ======= Description @@ -78,9 +78,9 @@ This costmap layer implements a plugin that uses 2D raycasting for 2D lidars, de :````. ````.topic: ====== ======= - Type Default + Type Default ------ ------- - string "" + string "" ====== ======= Description @@ -97,9 +97,9 @@ This costmap layer implements a plugin that uses 2D raycasting for 2D lidars, de :````. ````.sensor_frame: ====== ======= - Type Default + Type Default ------ ------- - string "" + string "" ====== ======= Description @@ -108,9 +108,9 @@ This costmap layer implements a plugin that uses 2D raycasting for 2D lidars, de :````. ````.observation_persistence: ====== ======= - Type Default + Type Default ------ ------- - double 0.0 + double 0.0 ====== ======= Description @@ -119,9 +119,9 @@ This costmap layer implements a plugin that uses 2D raycasting for 2D lidars, de :````. ````.expected_update_rate: ====== ======= - Type Default + Type Default ------ ------- - double 0.0 + double 0.0 ====== ======= Description @@ -130,9 +130,9 @@ This costmap layer implements a plugin that uses 2D raycasting for 2D lidars, de :````. ````.data_type: ====== =========== - Type Default + Type Default ------ ----------- - string "LaserScan" + string "LaserScan" ====== =========== Description @@ -141,9 +141,9 @@ This costmap layer implements a plugin that uses 2D raycasting for 2D lidars, de :````. ````.min_obstacle_height: ====== ======= - Type Default + Type Default ------ ------- - double 0.0 + double 0.0 ====== ======= Description @@ -152,9 +152,9 @@ This costmap layer implements a plugin that uses 2D raycasting for 2D lidars, de :````. ````.max_obstacle_height: ====== ======= - Type Default + Type Default ------ ------- - double 0.0 + double 0.0 ====== ======= Description @@ -163,9 +163,9 @@ This costmap layer implements a plugin that uses 2D raycasting for 2D lidars, de :````. ````.inf_is_valid: ====== ======= - Type Default + Type Default ------ ------- - bool False + bool False ====== ======= Description @@ -174,9 +174,9 @@ This costmap layer implements a plugin that uses 2D raycasting for 2D lidars, de :````. ````.marking: ====== ======= - Type Default + Type Default ------ ------- - bool True + bool True ====== ======= Description @@ -185,9 +185,9 @@ This costmap layer implements a plugin that uses 2D raycasting for 2D lidars, de :````. ````.clearing: ====== ======= - Type Default + Type Default ------ ------- - bool False + bool False ====== ======= Description @@ -196,9 +196,9 @@ This costmap layer implements a plugin that uses 2D raycasting for 2D lidars, de :````. ````.obstacle_max_range: ====== ======= - Type Default + Type Default ------ ------- - double 2.5 + double 2.5 ====== ======= Description @@ -207,9 +207,9 @@ This costmap layer implements a plugin that uses 2D raycasting for 2D lidars, de :````. ````.obstacle_min_range: ====== ======= - Type Default + Type Default ------ ------- - double 0.0 + double 0.0 ====== ======= Description @@ -218,9 +218,9 @@ This costmap layer implements a plugin that uses 2D raycasting for 2D lidars, de :````. ````.raytrace_max_range: ====== ======= - Type Default + Type Default ------ ------- - double 3.0 + double 3.0 ====== ======= Description @@ -229,9 +229,9 @@ This costmap layer implements a plugin that uses 2D raycasting for 2D lidars, de :````. ````.raytrace_min_range: ====== ======= - Type Default + Type Default ------ ------- - double 0.0 + double 0.0 ====== ======= Description diff --git a/configuration/packages/costmap-plugins/plugin_container.rst b/configuration/packages/costmap-plugins/plugin_container.rst index 50fab01c06..d64e8a3f47 100644 --- a/configuration/packages/costmap-plugins/plugin_container.rst +++ b/configuration/packages/costmap-plugins/plugin_container.rst @@ -3,16 +3,16 @@ Plugin Container Layer Parameters ================================= -This implements a costmap layer which combines costmap layers within a submap, which can then be integrated with other submaps in the same parent costmap. An example would be the use of different inflation layers for different sensors, objects, or static layers +This implements a costmap layer which combines costmap layers within a submap, which can then be integrated with other submaps in the same parent costmap. An example would be the use of different inflation layers for different sensors, objects, or static layers ```` is the corresponding plugin name selected for this type. :````.enabled: ==== ======= - Type Default + Type Default ---- ------- - bool True + bool True ==== ======= Description @@ -92,4 +92,3 @@ The above example settings, when applied to the Nav2 turtlebot simulation would :alt: Costmap generated by plugin container layer Costmap generated by turtlebot using example plugin container layer settings - diff --git a/configuration/packages/costmap-plugins/static.rst b/configuration/packages/costmap-plugins/static.rst index a0ea89d4fc..ee3fce7b7a 100644 --- a/configuration/packages/costmap-plugins/static.rst +++ b/configuration/packages/costmap-plugins/static.rst @@ -3,16 +3,16 @@ Static Layer Parameters ======================= -This implements a costmap layer taking in a map from either SLAM or ``map_server`` (or other) to place into the costmap. It resizes the costmap to its size and places the static obstacles on the planning space. +This implements a costmap layer taking in a map from either SLAM or ``map_server`` (or other) to place into the costmap. It resizes the costmap to its size and places the static obstacles on the planning space. ```` is the corresponding plugin name selected for this type. :````.enabled: ==== ======= - Type Default + Type Default ---- ------- - bool True + bool True ==== ======= Description @@ -21,9 +21,9 @@ This implements a costmap layer taking in a map from either SLAM or ``map_server :````.footprint_clearing_enabled: ==== ======= - Type Default + Type Default ---- ------- - bool False + bool False ==== ======= Description @@ -32,22 +32,22 @@ This implements a costmap layer taking in a map from either SLAM or ``map_server :````.restore_cleared_footprint: ==== ======= - Type Default + Type Default ---- ------- - bool True + bool True ==== ======= Description - Restore map after clearing the area the footprint occupied. - + Restore map after clearing the area the footprint occupied. + If ``footprint_clearing_enabled`` is false, this parameter is ignored. :````.subscribe_to_updates: ==== ======= - Type Default + Type Default ---- ------- - bool False + bool False ==== ======= Description @@ -56,9 +56,9 @@ This implements a costmap layer taking in a map from either SLAM or ``map_server :````.map_subscribe_transient_local: ==== ======= - Type Default + Type Default ---- ------- - bool True + bool True ==== ======= Description @@ -67,9 +67,9 @@ This implements a costmap layer taking in a map from either SLAM or ``map_server :````.transform_tolerance: ====== ======= - Type Default + Type Default ------ ------- - double 0.0 + double 0.0 ====== ======= Description diff --git a/configuration/packages/costmap-plugins/voxel.rst b/configuration/packages/costmap-plugins/voxel.rst index a34c82997c..55580f7503 100644 --- a/configuration/packages/costmap-plugins/voxel.rst +++ b/configuration/packages/costmap-plugins/voxel.rst @@ -12,9 +12,9 @@ This costmap layer implements a plugin that uses 3D raycasting for depth, 3D, or :````.enabled: ==== ======= - Type Default + Type Default ---- ------- - bool True + bool True ==== ======= Description @@ -23,9 +23,9 @@ This costmap layer implements a plugin that uses 3D raycasting for depth, 3D, or :````.footprint_clearing_enabled: ==== ======= - Type Default + Type Default ---- ------- - bool True + bool True ==== ======= Description @@ -34,9 +34,9 @@ This costmap layer implements a plugin that uses 3D raycasting for depth, 3D, or :````.max_obstacle_height: ====== ======= - Type Default + Type Default ------ ------- - double 2.0 + double 2.0 ====== ======= Description @@ -45,9 +45,9 @@ This costmap layer implements a plugin that uses 3D raycasting for depth, 3D, or :````.z_voxels: ====== ======= - Type Default + Type Default ------ ------- - int 10 + int 10 ====== ======= Description @@ -56,9 +56,9 @@ This costmap layer implements a plugin that uses 3D raycasting for depth, 3D, or :````.origin_z: ====== ======= - Type Default + Type Default ------ ------- - double 0.0 + double 0.0 ====== ======= Description @@ -67,9 +67,9 @@ This costmap layer implements a plugin that uses 3D raycasting for depth, 3D, or :````.z_resolution: ====== ======= - Type Default + Type Default ------ ------- - double 0.2 + double 0.2 ====== ======= Description @@ -78,9 +78,9 @@ This costmap layer implements a plugin that uses 3D raycasting for depth, 3D, or :````.unknown_threshold: ====== ======= - Type Default + Type Default ------ ------- - int 15 + int 15 ====== ======= Description @@ -89,9 +89,9 @@ This costmap layer implements a plugin that uses 3D raycasting for depth, 3D, or :````.mark_threshold: ====== ======= - Type Default + Type Default ------ ------- - int 0 + int 0 ====== ======= Description @@ -100,9 +100,9 @@ This costmap layer implements a plugin that uses 3D raycasting for depth, 3D, or :````.combination_method: ====== ======= - Type Default + Type Default ------ ------- - int 1 + int 1 ====== ======= Description @@ -110,9 +110,9 @@ This costmap layer implements a plugin that uses 3D raycasting for depth, 3D, or | 0 - Overwrite: Overwrite master costmap with every valid observation. - | 1 - Max: Sets the new value to the maximum of the master_grid's value and this layer's value. + | 1 - Max: Sets the new value to the maximum of the master_grid's value and this layer's value. | This is the default. - + | 2 - MaxWithoutUnknownOverwrite: Sets the new value to the maximum of the master_grid's | value and this layer's value. If the master value is NO_INFORMATION, it is NOT overwritten. | It can be used to make sure that the static map is the dominant source of information, and @@ -121,9 +121,9 @@ This costmap layer implements a plugin that uses 3D raycasting for depth, 3D, or :````.publish_voxel_map: ==== ======= - Type Default + Type Default ---- ------- - bool False + bool False ==== ======= Description @@ -132,9 +132,9 @@ This costmap layer implements a plugin that uses 3D raycasting for depth, 3D, or :````.observation_sources: ============== ======= - Type Default + Type Default -------------- ------- - vector {""} + vector {""} ============== ======= Description @@ -143,9 +143,9 @@ This costmap layer implements a plugin that uses 3D raycasting for depth, 3D, or :````. ````.topic: ====== ======= - Type Default + Type Default ------ ------- - string "" + string "" ====== ======= Description @@ -162,9 +162,9 @@ This costmap layer implements a plugin that uses 3D raycasting for depth, 3D, or :````. ````.sensor_frame: ====== ======= - Type Default + Type Default ------ ------- - string "" + string "" ====== ======= Description @@ -173,9 +173,9 @@ This costmap layer implements a plugin that uses 3D raycasting for depth, 3D, or :````. ````.observation_persistence: ====== ======= - Type Default + Type Default ------ ------- - double 0.0 + double 0.0 ====== ======= Description @@ -184,9 +184,9 @@ This costmap layer implements a plugin that uses 3D raycasting for depth, 3D, or :````. ````.expected_update_rate: ====== ======= - Type Default + Type Default ------ ------- - double 0.0 + double 0.0 ====== ======= Description @@ -195,9 +195,9 @@ This costmap layer implements a plugin that uses 3D raycasting for depth, 3D, or :````. ````.data_type: ====== =========== - Type Default + Type Default ------ ----------- - string "LaserScan" + string "LaserScan" ====== =========== Description @@ -206,9 +206,9 @@ This costmap layer implements a plugin that uses 3D raycasting for depth, 3D, or :````. ````.min_obstacle_height: ====== ======= - Type Default + Type Default ------ ------- - double 0.0 + double 0.0 ====== ======= Description @@ -217,9 +217,9 @@ This costmap layer implements a plugin that uses 3D raycasting for depth, 3D, or :````. ````.max_obstacle_height: ====== ======= - Type Default + Type Default ------ ------- - double 0.0 + double 0.0 ====== ======= Description @@ -228,9 +228,9 @@ This costmap layer implements a plugin that uses 3D raycasting for depth, 3D, or :````. ````.inf_is_valid: ====== ======= - Type Default + Type Default ------ ------- - bool False + bool False ====== ======= Description @@ -239,9 +239,9 @@ This costmap layer implements a plugin that uses 3D raycasting for depth, 3D, or :````. ````.marking: ====== ======= - Type Default + Type Default ------ ------- - bool True + bool True ====== ======= Description @@ -250,9 +250,9 @@ This costmap layer implements a plugin that uses 3D raycasting for depth, 3D, or :````. ````.clearing: ====== ======= - Type Default + Type Default ------ ------- - bool False + bool False ====== ======= Description @@ -261,9 +261,9 @@ This costmap layer implements a plugin that uses 3D raycasting for depth, 3D, or :````. ````.obstacle_max_range: ====== ======= - Type Default + Type Default ------ ------- - double 2.5 + double 2.5 ====== ======= Description @@ -272,9 +272,9 @@ This costmap layer implements a plugin that uses 3D raycasting for depth, 3D, or :````. ````.obstacle_min_range: ====== ======= - Type Default + Type Default ------ ------- - double 0.0 + double 0.0 ====== ======= Description @@ -283,9 +283,9 @@ This costmap layer implements a plugin that uses 3D raycasting for depth, 3D, or :````. ````.raytrace_max_range: ====== ======= - Type Default + Type Default ------ ------- - double 3.0 + double 3.0 ====== ======= Description @@ -294,9 +294,9 @@ This costmap layer implements a plugin that uses 3D raycasting for depth, 3D, or :````. ````.raytrace_min_range: ====== ======= - Type Default + Type Default ------ ------- - double 0.0 + double 0.0 ====== ======= Description diff --git a/configuration/packages/dwb-params/controller.rst b/configuration/packages/dwb-params/controller.rst index 4a6aa954aa..68daf5bad4 100644 --- a/configuration/packages/dwb-params/controller.rst +++ b/configuration/packages/dwb-params/controller.rst @@ -13,7 +13,7 @@ Parameters ============== ======= Type Default -------------- ------- - vector N/A + vector N/A ============== ======= Description @@ -22,9 +22,9 @@ Parameters :````.default_critic_namespaces: ============== =============== - Type Default + Type Default -------------- --------------- - vector ["dwb_critics"] + vector ["dwb_critics"] ============== =============== Description @@ -35,7 +35,7 @@ Parameters ==== ======= Type Default ---- ------- - bool true + bool true ==== ======= Description @@ -46,7 +46,7 @@ Parameters ==== ======= Type Default ---- ------- - bool true + bool true ==== ======= Description @@ -57,7 +57,7 @@ Parameters ====== ======= Type Default ------ ------- - double 2.0 + double 2.0 ====== ======= Description @@ -77,9 +77,9 @@ Parameters :````.debug_trajectory_details: ==== ======= - Type Default + Type Default ---- ------- - bool false + bool false ==== ======= Description @@ -88,9 +88,9 @@ Parameters :````.trajectory_generator_name: ====== ========================================== - Type Default + Type Default ------ ------------------------------------------ - string "dwb_plugins::StandardTrajectoryGenerator" + string "dwb_plugins::StandardTrajectoryGenerator" ====== ========================================== Description @@ -99,9 +99,9 @@ Parameters :````.goal_checker_name: ============== ================================ - Type Default + Type Default -------------- -------------------------------- - string "dwb_plugins::SimpleGoalChecker" + string "dwb_plugins::SimpleGoalChecker" ============== ================================ Description @@ -110,9 +110,9 @@ Parameters :````.transform_tolerance: ============== ============================= - Type Default + Type Default -------------- ----------------------------- - double 0.1 + double 0.1 ============== ============================= Description @@ -121,9 +121,9 @@ Parameters :````.short_circuit_trajectory_evaluation: ============== ============================= - Type Default + Type Default -------------- ----------------------------- - bool true + bool true ============== ============================= Description @@ -132,9 +132,9 @@ Parameters :````.path_distance_bias (Legacy): ============== ============================= - Type Default + Type Default -------------- ----------------------------- - double N/A + double N/A ============== ============================= Description @@ -143,9 +143,9 @@ Parameters :````.goal_distance_bias (Legacy): ============== ============================= - Type Default + Type Default -------------- ----------------------------- - double N/A + double N/A ============== ============================= Description @@ -154,9 +154,9 @@ Parameters :````.occdist_scale (Legacy): ============== ============================= - Type Default + Type Default -------------- ----------------------------- - double N/A + double N/A ============== ============================= Description @@ -165,9 +165,9 @@ Parameters :````.max_scaling_factor (Legacy): ============== ============================= - Type Default + Type Default -------------- ----------------------------- - double N/A + double N/A ============== ============================= Description @@ -176,9 +176,9 @@ Parameters :````.scaling_speed (Legacy): ============== ============================= - Type Default + Type Default -------------- ----------------------------- - double N/A + double N/A ============== ============================= Description @@ -187,9 +187,9 @@ Parameters :````.PathAlign.scale: ============== ============================= - Type Default + Type Default -------------- ----------------------------- - double 32.0 + double 32.0 ============== ============================= Description @@ -198,9 +198,9 @@ Parameters :````.GoalAlign.scale: ============== ============================= - Type Default + Type Default -------------- ----------------------------- - double 24.0 + double 24.0 ============== ============================= Description @@ -209,9 +209,9 @@ Parameters :````.PathDist.scale: ============== ============================= - Type Default + Type Default -------------- ----------------------------- - double 32.0 + double 32.0 ============== ============================= Description @@ -220,9 +220,9 @@ Parameters :````.GoalDist.scale: ============== ============================= - Type Default + Type Default -------------- ----------------------------- - double 24.0 + double 24.0 ============== ============================= Description diff --git a/configuration/packages/dwb-params/iterator.rst b/configuration/packages/dwb-params/iterator.rst index 7be270795d..c6f50ce384 100644 --- a/configuration/packages/dwb-params/iterator.rst +++ b/configuration/packages/dwb-params/iterator.rst @@ -13,7 +13,7 @@ Parameters ==== ======= Type Default ---- ------- - int 20 + int 20 ==== ======= Description @@ -24,7 +24,7 @@ Parameters ==== ======= Type Default ---- ------- - int 5 + int 5 ==== ======= Description @@ -35,7 +35,7 @@ Parameters ==== ======= Type Default ---- ------- - int 20 + int 20 ==== ======= Description diff --git a/configuration/packages/dwb-params/kinematic.rst b/configuration/packages/dwb-params/kinematic.rst index 3932279325..94174f27c8 100644 --- a/configuration/packages/dwb-params/kinematic.rst +++ b/configuration/packages/dwb-params/kinematic.rst @@ -13,7 +13,7 @@ Parameters ====== ======= Type Default ------ ------- - double 0.0 + double 0.0 ====== ======= Description @@ -24,7 +24,7 @@ Parameters ====== ======= Type Default ------ ------- - double 0.0 + double 0.0 ====== ======= Description @@ -35,7 +35,7 @@ Parameters ====== ======= Type Default ------ ------- - double 0.0 + double 0.0 ====== ======= Description @@ -46,7 +46,7 @@ Parameters ====== ======= Type Default ------ ------- - double 0.0 + double 0.0 ====== ======= Description @@ -57,7 +57,7 @@ Parameters ====== ======= Type Default ------ ------- - double 0.0 + double 0.0 ====== ======= Description @@ -68,7 +68,7 @@ Parameters ====== ======= Type Default ------ ------- - double 0.0 + double 0.0 ====== ======= Description @@ -79,7 +79,7 @@ Parameters ====== ======= Type Default ------ ------- - double 0.0 + double 0.0 ====== ======= Description @@ -90,7 +90,7 @@ Parameters ====== ======= Type Default ------ ------- - double 0.0 + double 0.0 ====== ======= Description @@ -101,7 +101,7 @@ Parameters ====== ======= Type Default ------ ------- - double 0.0 + double 0.0 ====== ======= Description @@ -112,7 +112,7 @@ Parameters ====== ======= Type Default ------ ------- - double 0.0 + double 0.0 ====== ======= Description @@ -123,7 +123,7 @@ Parameters ====== ======= Type Default ------ ------- - double 0.0 + double 0.0 ====== ======= Description @@ -134,7 +134,7 @@ Parameters ====== ======= Type Default ------ ------- - double 0.0 + double 0.0 ====== ======= Description @@ -145,7 +145,7 @@ Parameters ====== ======= Type Default ------ ------- - double 0.0 + double 0.0 ====== ======= Description @@ -160,4 +160,4 @@ Parameters ====== ======= Description - Maximum deceleration rotation (rad/s^2). \ No newline at end of file + Maximum deceleration rotation (rad/s^2). diff --git a/configuration/packages/dwb-params/visualization.rst b/configuration/packages/dwb-params/visualization.rst index 523440b773..183cabdb78 100644 --- a/configuration/packages/dwb-params/visualization.rst +++ b/configuration/packages/dwb-params/visualization.rst @@ -13,7 +13,7 @@ Parameters ==== ======= Type Default ---- ------- - bool true + bool true ==== ======= Description @@ -24,7 +24,7 @@ Parameters ==== ======= Type Default ---- ------- - bool true + bool true ==== ======= Description @@ -35,7 +35,7 @@ Parameters ==== ======= Type Default ---- ------- - bool true + bool true ==== ======= Description @@ -46,7 +46,7 @@ Parameters ==== ======= Type Default ---- ------- - bool true + bool true ==== ======= Description @@ -57,7 +57,7 @@ Parameters ==== ======= Type Default ---- ------- - bool true + bool true ==== ======= Description @@ -68,7 +68,7 @@ Parameters ==== ======= Type Default ---- ------- - bool false + bool false ==== ======= Description @@ -79,7 +79,7 @@ Parameters ============== ======= Type Default -------------- ------- - double 0.1 + double 0.1 ============== ======= Description diff --git a/configuration/packages/dwb-plugins/limited_accel_generator.rst b/configuration/packages/dwb-plugins/limited_accel_generator.rst index 17ceef2494..62217d7796 100644 --- a/configuration/packages/dwb-plugins/limited_accel_generator.rst +++ b/configuration/packages/dwb-plugins/limited_accel_generator.rst @@ -15,6 +15,6 @@ Parameters ------ ------- double 1.7 ====== ======= - + Description Time to simulate ahead by (s). diff --git a/configuration/packages/dwb-plugins/standard_traj_generator.rst b/configuration/packages/dwb-plugins/standard_traj_generator.rst index 3f098301ea..b6e6f85046 100644 --- a/configuration/packages/dwb-plugins/standard_traj_generator.rst +++ b/configuration/packages/dwb-plugins/standard_traj_generator.rst @@ -15,7 +15,7 @@ Parameters ------ ------- double 1.7 ====== ======= - + Description Time to simulate ahead by (s). @@ -26,7 +26,7 @@ Parameters ---- ------- bool false ==== ======= - + Description If true, forward simulate by time. If False, forward simulate by linear and angular granularity. @@ -37,7 +37,7 @@ Parameters ------ ------- double 0.5 ====== ======= - + Description Time ahead to project. @@ -48,7 +48,7 @@ Parameters ------ ------- double 0.5 ====== ======= - + Description Linear distance forward to project. @@ -59,7 +59,7 @@ Parameters ------ ------- double 0.025 ====== ======= - + Description Angular distance to project. @@ -70,7 +70,7 @@ Parameters ---- ------- bool true ==== ======= - + Description Whether to include the last pose in the trajectory. @@ -81,6 +81,6 @@ Parameters ---- ------- bool false ==== ======= - + Description Whether to limit velocity command in trajectory using sampled velocity instead of the commanded velocity. diff --git a/configuration/packages/nav2_controller-plugins/pose_progress_checker.rst b/configuration/packages/nav2_controller-plugins/pose_progress_checker.rst index f3c52dd797..17e101590f 100644 --- a/configuration/packages/nav2_controller-plugins/pose_progress_checker.rst +++ b/configuration/packages/nav2_controller-plugins/pose_progress_checker.rst @@ -42,4 +42,3 @@ Parameters Description Maximum amount of time a robot has to move the minimum radius or the mnimum angle (s). - diff --git a/configuration/packages/nav2_controller-plugins/simple_goal_checker.rst b/configuration/packages/nav2_controller-plugins/simple_goal_checker.rst index d346f23f01..531f69cc76 100644 --- a/configuration/packages/nav2_controller-plugins/simple_goal_checker.rst +++ b/configuration/packages/nav2_controller-plugins/simple_goal_checker.rst @@ -17,7 +17,7 @@ Parameters ------ ------- double 0.25 ====== ======= - + Description Tolerance to meet goal completion criteria (m). @@ -28,7 +28,7 @@ Parameters ------ ------- double 0.25 ====== ======= - + Description Tolerance to meet goal completion criteria (rad). @@ -37,8 +37,8 @@ Parameters ==== ======= Type Default ---- ------- - bool true + bool true ==== ======= - + Description Whether to check for XY position tolerance after rotating to goal orientation in case of minor localization changes. diff --git a/configuration/packages/nav2_controller-plugins/simple_progress_checker.rst b/configuration/packages/nav2_controller-plugins/simple_progress_checker.rst index 410dd7cccb..48bcfd0ffb 100644 --- a/configuration/packages/nav2_controller-plugins/simple_progress_checker.rst +++ b/configuration/packages/nav2_controller-plugins/simple_progress_checker.rst @@ -31,4 +31,3 @@ Parameters Description Maximum amount of time a robot has to move the minimum radius (s). - diff --git a/configuration/packages/nav2_controller-plugins/stopped_goal_checker.rst b/configuration/packages/nav2_controller-plugins/stopped_goal_checker.rst index d91c60ff34..eea4cf73c7 100644 --- a/configuration/packages/nav2_controller-plugins/stopped_goal_checker.rst +++ b/configuration/packages/nav2_controller-plugins/stopped_goal_checker.rst @@ -17,7 +17,7 @@ Parameters ------ ------- double 0.25 ====== ======= - + Description Velocity below is considered to be stopped at tolerance met (m/s). @@ -28,7 +28,7 @@ Parameters ------ ------- double 0.25 ====== ======= - + Description Velocity below is considered to be stopped at tolerance met (rad/s). @@ -39,7 +39,7 @@ Parameters ------ ------- double 0.25 ====== ======= - + Description Tolerance to meet goal completion criteria (m). @@ -50,7 +50,7 @@ Parameters ------ ------- double 0.25 ====== ======= - + Description Tolerance to meet goal completion criteria (rad). @@ -59,8 +59,8 @@ Parameters ==== ======= Type Default ---- ------- - bool true + bool true ==== ======= - + Description Whether to check for XY position tolerance after rotating to goal orientation in case of minor localization changes. diff --git a/configuration/packages/nav2_waypoint_follower-plugins/input_at_waypoint.rst b/configuration/packages/nav2_waypoint_follower-plugins/input_at_waypoint.rst index 5f998480e7..3afecc21aa 100644 --- a/configuration/packages/nav2_waypoint_follower-plugins/input_at_waypoint.rst +++ b/configuration/packages/nav2_waypoint_follower-plugins/input_at_waypoint.rst @@ -13,9 +13,9 @@ Parameters :````.enabled: ============== ============================= - Type Default + Type Default -------------- ----------------------------- - bool true + bool true ============== ============================= Description @@ -25,9 +25,9 @@ Parameters :````.timeout: ============== ============================= - Type Default + Type Default -------------- ----------------------------- - double 10.0 + double 10.0 ============== ============================= Description @@ -36,9 +36,9 @@ Parameters :````.input_topic: ============== ============================= - Type Default + Type Default -------------- ----------------------------- - string "input_at_waypoint/input" + string "input_at_waypoint/input" ============== ============================= Description diff --git a/configuration/packages/nav2_waypoint_follower-plugins/photo_at_waypoint.rst b/configuration/packages/nav2_waypoint_follower-plugins/photo_at_waypoint.rst index 86d78d4a9b..05a96f8157 100644 --- a/configuration/packages/nav2_waypoint_follower-plugins/photo_at_waypoint.rst +++ b/configuration/packages/nav2_waypoint_follower-plugins/photo_at_waypoint.rst @@ -3,8 +3,8 @@ PhotoAtWaypoint =============== -Run-time plugin that takes photos at waypoint arrivals when using waypoint follower node. Saves the taken photos to specified directory. The name for taken photos are determined by -the waypoint index and timestamp(seconds). For instance ``/home/atas/0_1602582820.png`` is an sample taken image, where ``0_1602582820`` is the file name determined by waypoint +Run-time plugin that takes photos at waypoint arrivals when using waypoint follower node. Saves the taken photos to specified directory. The name for taken photos are determined by +the waypoint index and timestamp(seconds). For instance ``/home/atas/0_1602582820.png`` is an sample taken image, where ``0_1602582820`` is the file name determined by waypoint index and time stamp. The leading digit in file name implies the waypoint index and the rest of digits at righthand side implies the time stamp when the photo was taken. Parameters @@ -15,9 +15,9 @@ Parameters :````.enabled: ============== ============================= - Type Default + Type Default -------------- ----------------------------- - bool true + bool true ============== ============================= Description @@ -27,9 +27,9 @@ Parameters :````.camera_image_topic_name: ============== ============================= - Type Default + Type Default -------------- ----------------------------- - string "/camera/color/image_raw" + string "/camera/color/image_raw" ============== ============================= Description @@ -38,9 +38,9 @@ Parameters :````.save_images_dir: ============== ============================= - Type Default + Type Default -------------- ----------------------------- - string "/tmp/waypoint_images" + string "/tmp/waypoint_images" ============== ============================= Description @@ -49,9 +49,9 @@ Parameters :````.image_format: ============== ============================= - Type Default + Type Default -------------- ----------------------------- - string "png" + string "png" ============== ============================= Description diff --git a/configuration/packages/nav2_waypoint_follower-plugins/wait_at_waypoint.rst b/configuration/packages/nav2_waypoint_follower-plugins/wait_at_waypoint.rst index 4cc548d6d8..dcfbc90f5f 100644 --- a/configuration/packages/nav2_waypoint_follower-plugins/wait_at_waypoint.rst +++ b/configuration/packages/nav2_waypoint_follower-plugins/wait_at_waypoint.rst @@ -13,9 +13,9 @@ Parameters :````.enabled: ============== ============================= - Type Default + Type Default -------------- ----------------------------- - bool true + bool true ============== ============================= Description @@ -25,11 +25,10 @@ Parameters :````.waypoint_pause_duration: ============== ============================= - Type Default + Type Default -------------- ----------------------------- - int 0 + int 0 ============== ============================= Description Amount of time in milliseconds, for robot to sleep/wait after each waypoint is reached. If zero, robot will directly continue to next waypoint. - diff --git a/configuration/packages/smac/configuring-smac-2d.rst b/configuration/packages/smac/configuring-smac-2d.rst index fa2e6256a9..bd585296ad 100644 --- a/configuration/packages/smac/configuring-smac-2d.rst +++ b/configuration/packages/smac/configuring-smac-2d.rst @@ -20,7 +20,7 @@ Parameters ============== ======= Type Default -------------- ------- - double 0.125 + double 0.125 ============== ======= Description @@ -29,9 +29,9 @@ Parameters :````.downsample_costmap: ==== ======= - Type Default + Type Default ---- ------- - bool False + bool False ==== ======= Description @@ -40,9 +40,9 @@ Parameters :````.downsampling_factor: ==== ======= - Type Default + Type Default ---- ------- - int 1 + int 1 ==== ======= Description @@ -51,9 +51,9 @@ Parameters :````.allow_unknown: ==== ======= - Type Default + Type Default ---- ------- - bool True + bool True ==== ======= Description @@ -62,9 +62,9 @@ Parameters :````.max_iterations: ==== ======= - Type Default + Type Default ---- ------- - int 1000000 + int 1000000 ==== ======= Description @@ -73,9 +73,9 @@ Parameters :````.max_on_approach_iterations: ==== ======= - Type Default + Type Default ---- ------- - int 1000 + int 1000 ==== ======= Description @@ -84,9 +84,9 @@ Parameters :````.terminal_checking_interval: ==== ======= - Type Default + Type Default ---- ------- - int 5000 + int 5000 ==== ======= Description @@ -95,9 +95,9 @@ Parameters :````.max_planning_time: ====== ======= - Type Default + Type Default ------ ------- - double 2.0 + double 2.0 ====== ======= Description @@ -106,9 +106,9 @@ Parameters :````.cost_travel_multiplier: ====== ======= - Type Default + Type Default ------ ------- - double 2.0 + double 2.0 ====== ======= Description @@ -117,9 +117,9 @@ Parameters :````.use_final_approach_orientation: ====== ======= - Type Default + Type Default ------ ------- - bool false + bool false ====== ======= Description @@ -128,9 +128,9 @@ Parameters :````.smoother.max_iterations: ====== ======= - Type Default + Type Default ------ ------- - int 1000 + int 1000 ====== ======= Description @@ -139,9 +139,9 @@ Parameters :````.smoother.w_smooth: ====== ======= - Type Default + Type Default ------ ------- - double 0.3 + double 0.3 ====== ======= Description @@ -150,9 +150,9 @@ Parameters :````.smoother.w_data: ====== ======= - Type Default + Type Default ------ ------- - double 0.2 + double 0.2 ====== ======= Description @@ -161,9 +161,9 @@ Parameters :````.smoother.tolerance: ====== ======= - Type Default + Type Default ------ ------- - double 1e-10 + double 1e-10 ====== ======= Description diff --git a/configuration/packages/smac/configuring-smac-hybrid.rst b/configuration/packages/smac/configuring-smac-hybrid.rst index 5992ac2602..fc4042e9d4 100644 --- a/configuration/packages/smac/configuring-smac-hybrid.rst +++ b/configuration/packages/smac/configuring-smac-hybrid.rst @@ -8,7 +8,7 @@ Smac Hybrid-A* Planner :alt: Paths generated by the Smac Hybrid-A* :width: 640px -This plugin implements a cost-aware Hybrid-A* global path planner with motion primitives proportionally sized to the minimum required to leave a user's costmap cell allowing for finite moves. +This plugin implements a cost-aware Hybrid-A* global path planner with motion primitives proportionally sized to the minimum required to leave a user's costmap cell allowing for finite moves. ```` is the corresponding planner plugin ID selected for this type. @@ -18,9 +18,9 @@ Parameters :````.downsample_costmap: ==== ======= - Type Default + Type Default ---- ------- - bool False + bool False ==== ======= Description @@ -29,9 +29,9 @@ Parameters :````.downsampling_factor: ==== ======= - Type Default + Type Default ---- ------- - int 1 + int 1 ==== ======= Description @@ -40,20 +40,20 @@ Parameters :````.allow_unknown: ==== ======= - Type Default + Type Default ---- ------- - bool True + bool True ==== ======= Description Whether to allow traversing/search in unknown space. - + :````.tolerance: ====== ======= - Type Default + Type Default ------ ------- - double 0.25 + double 0.25 ====== ======= Description @@ -62,9 +62,9 @@ Parameters :````.max_iterations: ==== ======= - Type Default + Type Default ---- ------- - int 1000000 + int 1000000 ==== ======= Description @@ -73,9 +73,9 @@ Parameters :````.max_on_approach_iterations: ==== ======= - Type Default + Type Default ---- ------- - int 1000 + int 1000 ==== ======= Description @@ -84,9 +84,9 @@ Parameters :````.terminal_checking_interval: ==== ======= - Type Default + Type Default ---- ------- - int 5000 + int 5000 ==== ======= Description @@ -95,9 +95,9 @@ Parameters :````.max_planning_time: ====== ======= - Type Default + Type Default ------ ------- - double 5.0 + double 5.0 ====== ======= Description @@ -106,9 +106,9 @@ Parameters :````.analytic_expansion_ratio: ====== ======= - Type Default + Type Default ------ ------- - double 3.5 + double 3.5 ====== ======= Description @@ -117,9 +117,9 @@ Parameters :````.analytic_expansion_max_length: ====== ======= - Type Default + Type Default ------ ------- - double 3.0 + double 3.0 ====== ======= Description @@ -128,9 +128,9 @@ Parameters :````.analytic_expansion_max_cost: ====== ======= - Type Default + Type Default ------ ------- - double 200.0 + double 200.0 ====== ======= Description @@ -139,20 +139,20 @@ Parameters :````.analytic_expansion_max_cost_override: ====== ======= - Type Default + Type Default ------ ------- - bool false + bool false ====== ======= Description - For Hybrid/Lattice nodes: Whether or not to override the maximum cost setting if within critical distance to goal (ie probably required). If expansion is within 2*pi*min_r of the goal, then it will override the max cost if ``false``. + For Hybrid/Lattice nodes: Whether or not to override the maximum cost setting if within critical distance to goal (ie probably required). If expansion is within 2*pi*min_r of the goal, then it will override the max cost if ``false``. :````.motion_model_for_search: ====== ======= - Type Default + Type Default ------ ------- - string "DUBIN" + string "DUBIN" ====== ======= Description @@ -161,9 +161,9 @@ Parameters :````.angle_quantization_bins: ==== ======= - Type Default + Type Default ---- ------- - int 72 + int 72 ==== ======= Description @@ -172,9 +172,9 @@ Parameters :````.minimum_turning_radius: ====== ======= - Type Default + Type Default ------ ------- - double 0.4 + double 0.4 ====== ======= Description @@ -183,9 +183,9 @@ Parameters :````.reverse_penalty: ====== ======= - Type Default + Type Default ------ ------- - double 2.0 + double 2.0 ====== ======= Description @@ -194,9 +194,9 @@ Parameters :````.change_penalty: ====== ======= - Type Default + Type Default ------ ------- - double 0.0 + double 0.0 ====== ======= Description @@ -205,9 +205,9 @@ Parameters :````.non_straight_penalty: ====== ======= - Type Default + Type Default ------ ------- - double 1.20 + double 1.20 ====== ======= Description @@ -216,9 +216,9 @@ Parameters :````.cost_penalty: ====== ======= - Type Default + Type Default ------ ------- - double 2.0 + double 2.0 ====== ======= Description @@ -227,20 +227,20 @@ Parameters :````.retrospective_penalty: ====== ======= - Type Default + Type Default ------ ------- - double 0.015 + double 0.015 ====== ======= Description - Heuristic penalty to apply to SE2 node penalty. Causes Hybrid-A* to prefer later maneuvers before earlier ones along the path. Saves search time since earlier (shorter) branches are not expanded until it is necessary. Must be >= 0.0 and <= 1.0. Must be `0.0` to be fully admissible. + Heuristic penalty to apply to SE2 node penalty. Causes Hybrid-A* to prefer later maneuvers before earlier ones along the path. Saves search time since earlier (shorter) branches are not expanded until it is necessary. Must be >= 0.0 and <= 1.0. Must be `0.0` to be fully admissible. :````.lookup_table_size: ====== ======= - Type Default + Type Default ------ ------- - double 20.0 + double 20.0 ====== ======= Description @@ -249,9 +249,9 @@ Parameters :````.debug_visualizations: ====== ======= - Type Default + Type Default ------ ------- - bool false + bool false ====== ======= Description @@ -260,9 +260,9 @@ Parameters :````.cache_obstacle_heuristic: ====== ======= - Type Default + Type Default ------ ------- - bool false + bool false ====== ======= Description @@ -271,9 +271,9 @@ Parameters :````.allow_primitive_interpolation: ====== ======= - Type Default + Type Default ------ ------- - bool false + bool false ====== ======= Description @@ -282,9 +282,9 @@ Parameters :````.downsample_obstacle_heuristic: ====== ======= - Type Default + Type Default ------ ------- - bool true + bool true ====== ======= Description @@ -293,9 +293,9 @@ Parameters :````.use_quadratic_cost_penalty: ====== ======= - Type Default + Type Default ------ ------- - bool false + bool false ====== ======= Description @@ -304,9 +304,9 @@ Parameters :````.smooth_path: ====== ======= - Type Default + Type Default ------ ------- - bool true + bool true ====== ======= Description @@ -315,9 +315,9 @@ Parameters :````.smoother.max_iterations: ====== ======= - Type Default + Type Default ------ ------- - int 1000 + int 1000 ====== ======= Description @@ -326,9 +326,9 @@ Parameters :````.smoother.w_smooth: ====== ======= - Type Default + Type Default ------ ------- - double 0.3 + double 0.3 ====== ======= Description @@ -337,9 +337,9 @@ Parameters :````.smoother.w_data: ====== ======= - Type Default + Type Default ------ ------- - double 0.2 + double 0.2 ====== ======= Description @@ -348,9 +348,9 @@ Parameters :````.smoother.tolerance: ====== ======= - Type Default + Type Default ------ ------- - double 1e-10 + double 1e-10 ====== ======= Description @@ -359,9 +359,9 @@ Parameters :````.smoother.do_refinement: ====== ======= - Type Default + Type Default ------ ------- - bool true + bool true ====== ======= Description @@ -370,9 +370,9 @@ Parameters :````.smoother.refinement_num: ============== =========================== - Type Default + Type Default -------------- --------------------------- - int 2 + int 2 ============== =========================== Description @@ -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 subsequent 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 diff --git a/configuration/packages/smac/configuring-smac-lattice.rst b/configuration/packages/smac/configuring-smac-lattice.rst index 200bf510dc..29c366f7ae 100644 --- a/configuration/packages/smac/configuring-smac-lattice.rst +++ b/configuration/packages/smac/configuring-smac-lattice.rst @@ -22,9 +22,9 @@ Parameters :````.allow_unknown: ==== ======= - Type Default + Type Default ---- ------- - bool True + bool True ==== ======= Description @@ -33,9 +33,9 @@ Parameters :````.tolerance: ====== ======= - Type Default + Type Default ------ ------- - double 0.25 + double 0.25 ====== ======= Description @@ -44,20 +44,20 @@ Parameters :````.max_iterations: ==== ======= - Type Default + Type Default ---- ------- - int 1000000 + int 1000000 ==== ======= Description Maximum number of search iterations before failing to limit compute time, disabled by -1. - + :````.max_on_approach_iterations: ==== ======= - Type Default + Type Default ---- ------- - int 1000 + int 1000 ==== ======= Description @@ -66,9 +66,9 @@ Parameters :````.terminal_checking_interval: ==== ======= - Type Default + Type Default ---- ------- - int 5000 + int 5000 ==== ======= Description @@ -77,9 +77,9 @@ Parameters :````.max_planning_time: ====== ======= - Type Default + Type Default ------ ------- - double 5.0 + double 5.0 ====== ======= Description @@ -88,9 +88,9 @@ Parameters :````.analytic_expansion_ratio: ====== ======= - Type Default + Type Default ------ ------- - double 3.5 + double 3.5 ====== ======= Description @@ -99,9 +99,9 @@ Parameters :````.analytic_expansion_max_length: ====== ======= - Type Default + Type Default ------ ------- - double 3.0 + double 3.0 ====== ======= Description @@ -110,9 +110,9 @@ Parameters :````.analytic_expansion_max_cost: ====== ======= - Type Default + Type Default ------ ------- - double 200.0 + double 200.0 ====== ======= Description @@ -121,20 +121,20 @@ Parameters :````.analytic_expansion_max_cost_override: ====== ======= - Type Default + Type Default ------ ------- - bool false + bool false ====== ======= Description - For Hybrid/Lattice nodes: Whether or not to override the maximum cost setting if within critical distance to goal (ie probably required). If expansion is within 2*pi*min_r of the goal, then it will override the max cost if ``false``. + For Hybrid/Lattice nodes: Whether or not to override the maximum cost setting if within critical distance to goal (ie probably required). If expansion is within 2*pi*min_r of the goal, then it will override the max cost if ``false``. :````.reverse_penalty: ====== ======= - Type Default + Type Default ------ ------- - double 2.0 + double 2.0 ====== ======= Description @@ -143,9 +143,9 @@ Parameters :````.change_penalty: ====== ======= - Type Default + Type Default ------ ------- - double 0.05 + double 0.05 ====== ======= Description @@ -154,9 +154,9 @@ Parameters :````.non_straight_penalty: ====== ======= - Type Default + Type Default ------ ------- - double 1.05 + double 1.05 ====== ======= Description @@ -165,9 +165,9 @@ Parameters :````.cost_penalty: ====== ======= - Type Default + Type Default ------ ------- - double 2.0 + double 2.0 ====== ======= Description @@ -176,9 +176,9 @@ Parameters :````.rotation_penalty: ====== ======= - Type Default + Type Default ------ ------- - double 5.0 + double 5.0 ====== ======= Description @@ -187,20 +187,20 @@ Parameters :````.retrospective_penalty: ====== ======= - Type Default + Type Default ------ ------- - double 0.015 + double 0.015 ====== ======= Description - Heuristic penalty to apply to SE2 node penalty. Causes State Lattice to prefer later maneuvers before earlier ones along the path. Saves search time since earlier (shorter) branches are not expanded until it is necessary. Must be >= 0.0 and <= 1.0. Must be `0.0` to be fully admissible. + Heuristic penalty to apply to SE2 node penalty. Causes State Lattice to prefer later maneuvers before earlier ones along the path. Saves search time since earlier (shorter) branches are not expanded until it is necessary. Must be >= 0.0 and <= 1.0. Must be `0.0` to be fully admissible. :````.lattice_filepath: ====== ======= - Type Default + Type Default ------ ------- - string "" + string "" ====== ======= Description @@ -209,9 +209,9 @@ Parameters :````.lookup_table_size: ====== ======= - Type Default + Type Default ------ ------- - double 20.0 + double 20.0 ====== ======= Description @@ -220,9 +220,9 @@ Parameters :````.cache_obstacle_heuristic: ====== ======= - Type Default + Type Default ------ ------- - bool false + bool false ====== ======= Description @@ -231,9 +231,9 @@ Parameters :````.allow_reverse_expansion: ====== ======= - Type Default + Type Default ------ ------- - bool false + bool false ====== ======= Description @@ -243,9 +243,9 @@ Parameters :````.debug_visualizations: ====== ======= - Type Default + Type Default ------ ------- - bool false + bool false ====== ======= Description @@ -254,9 +254,9 @@ Parameters :````.smooth_path: ====== ======= - Type Default + Type Default ------ ------- - bool true + bool true ====== ======= Description @@ -265,9 +265,9 @@ Parameters :````.smoother.max_iterations: ====== ======= - Type Default + Type Default ------ ------- - int 1000 + int 1000 ====== ======= Description @@ -276,9 +276,9 @@ Parameters :````.smoother.w_smooth: ====== ======= - Type Default + Type Default ------ ------- - double 0.3 + double 0.3 ====== ======= Description @@ -287,9 +287,9 @@ Parameters :````.smoother.w_data: ====== ======= - Type Default + Type Default ------ ------- - double 0.2 + double 0.2 ====== ======= Description @@ -298,9 +298,9 @@ Parameters :````.smoother.tolerance: ====== ======= - Type Default + Type Default ------ ------- - double 1e-10 + double 1e-10 ====== ======= Description @@ -309,9 +309,9 @@ Parameters :````.smoother.do_refinement: ====== ======= - Type Default + Type Default ------ ------- - bool true + bool true ====== ======= Description @@ -320,9 +320,9 @@ Parameters :````.smoother.refinement_num: ============== =========================== - Type Default + Type Default -------------- --------------------------- - int 2 + int 2 ============== =========================== Description diff --git a/configuration/packages/trajectory_critics/base_obstacle.rst b/configuration/packages/trajectory_critics/base_obstacle.rst index ae481c6bd9..c5e7b2442d 100644 --- a/configuration/packages/trajectory_critics/base_obstacle.rst +++ b/configuration/packages/trajectory_critics/base_obstacle.rst @@ -3,7 +3,7 @@ BaseObstacleCritic ================== -Scores a trajectory based on where the path passes over the costmap. +Scores a trajectory based on where the path passes over the costmap. To use this properly, you must use the inflation layer in costmap to expand obstacles by the robot's radius. Parameters @@ -18,9 +18,9 @@ Parameters ==== ======= Type Default ---- ------- - bool false + bool false ==== ======= - + Description Whether to allow for scores to be summed up. @@ -29,8 +29,8 @@ Parameters ====== ======= Type Default ------ ------- - double 1.0 + double 1.0 ====== ======= - + Description Weighed scale for critic. diff --git a/configuration/packages/trajectory_critics/goal_align.rst b/configuration/packages/trajectory_critics/goal_align.rst index cae4ddd985..3daa4a09bd 100644 --- a/configuration/packages/trajectory_critics/goal_align.rst +++ b/configuration/packages/trajectory_critics/goal_align.rst @@ -17,9 +17,9 @@ Parameters ====== ======= Type Default ------ ------- - double 0.325 + double 0.325 ====== ======= - + Description Point in front of robot to look ahead to compute angular change from. @@ -28,9 +28,9 @@ Parameters ====== ======= Type Default ------ ------- - string "last" + string "last" ====== ======= - + Description last, sum, or product combination methods. @@ -39,8 +39,8 @@ Parameters ====== ======= Type Default ------ ------- - double 1.0 + double 1.0 ====== ======= - + Description Weighed scale for critic. diff --git a/configuration/packages/trajectory_critics/goal_dist.rst b/configuration/packages/trajectory_critics/goal_dist.rst index 93801e2a45..1c19f8043d 100644 --- a/configuration/packages/trajectory_critics/goal_dist.rst +++ b/configuration/packages/trajectory_critics/goal_dist.rst @@ -18,9 +18,9 @@ Parameters ====== ======= Type Default ------ ------- - string "last" + string "last" ====== ======= - + Description last, sum, or product combination methods. @@ -29,8 +29,8 @@ Parameters ====== ======= Type Default ------ ------- - double 1.0 + double 1.0 ====== ======= - + Description Weighed scale for critic. diff --git a/configuration/packages/trajectory_critics/obstacle_footprint.rst b/configuration/packages/trajectory_critics/obstacle_footprint.rst index 747963330d..e870d3d290 100644 --- a/configuration/packages/trajectory_critics/obstacle_footprint.rst +++ b/configuration/packages/trajectory_critics/obstacle_footprint.rst @@ -18,9 +18,9 @@ Parameters ==== ======= Type Default ---- ------- - bool false + bool false ==== ======= - + Description Whether to allow for scores to be summed up. @@ -29,8 +29,8 @@ Parameters ====== ======= Type Default ------ ------- - double 1.0 + double 1.0 ====== ======= - + Description Weighed scale for critic. diff --git a/configuration/packages/trajectory_critics/oscillation.rst b/configuration/packages/trajectory_critics/oscillation.rst index 09d577b953..fc9d788177 100644 --- a/configuration/packages/trajectory_critics/oscillation.rst +++ b/configuration/packages/trajectory_critics/oscillation.rst @@ -18,9 +18,9 @@ Parameters ====== ======= Type Default ------ ------- - double 0.05 + double 0.05 ====== ======= - + Description Minimum distance to move to reset oscillation watchdog (m). @@ -29,9 +29,9 @@ Parameters ====== ======= Type Default ------ ------- - double 0.2 + double 0.2 ====== ======= - + Description Minimum angular distance to move to reset watchdog (rad). @@ -40,9 +40,9 @@ Parameters ====== ======= Type Default ------ ------- - double -1 + double -1 ====== ======= - + Description Duration when a reset may be called. If -1, cannot be reset.. @@ -52,9 +52,9 @@ Parameters ====== ======= Type Default ------ ------- - double 0.05 + double 0.05 ====== ======= - + Description Threshold to check in the X velocity direction. @@ -63,8 +63,8 @@ Parameters ====== ======= Type Default ------ ------- - double 1.0 + double 1.0 ====== ======= - + Description Weighed scale for critic. diff --git a/configuration/packages/trajectory_critics/path_align.rst b/configuration/packages/trajectory_critics/path_align.rst index 84eab94902..6a35bcb91b 100644 --- a/configuration/packages/trajectory_critics/path_align.rst +++ b/configuration/packages/trajectory_critics/path_align.rst @@ -16,9 +16,9 @@ Parameters ====== ======= Type Default ------ ------- - double 0.325 + double 0.325 ====== ======= - + Description Point in front of robot to look ahead to compute angular change from. @@ -27,9 +27,9 @@ Parameters ====== ======= Type Default ------ ------- - string "last" + string "last" ====== ======= - + Description last, sum, or product combination methods. @@ -38,8 +38,8 @@ Parameters ====== ======= Type Default ------ ------- - double 1.0 + double 1.0 ====== ======= - + Description Weighed scale for critic. diff --git a/configuration/packages/trajectory_critics/path_dist.rst b/configuration/packages/trajectory_critics/path_dist.rst index db796397d7..1e6d949458 100644 --- a/configuration/packages/trajectory_critics/path_dist.rst +++ b/configuration/packages/trajectory_critics/path_dist.rst @@ -16,9 +16,9 @@ Parameters ====== ======= Type Default ------ ------- - string "last" + string "last" ====== ======= - + Description last, sum, or product combination methods. @@ -27,8 +27,8 @@ Parameters ====== ======= Type Default ------ ------- - double 1.0 + double 1.0 ====== ======= - + Description Weighed scale for critic. diff --git a/configuration/packages/trajectory_critics/prefer_forward.rst b/configuration/packages/trajectory_critics/prefer_forward.rst index 4eac5fce42..9a6753ef7b 100644 --- a/configuration/packages/trajectory_critics/prefer_forward.rst +++ b/configuration/packages/trajectory_critics/prefer_forward.rst @@ -18,9 +18,9 @@ Parameters ====== ======= Type Default ------ ------- - double 1.0 + double 1.0 ====== ======= - + Description Penalty to apply to backward motion. @@ -29,9 +29,9 @@ Parameters ====== ======= Type Default ------ ------- - double 0.1 + double 0.1 ====== ======= - + Description Minimum X velocity before penalty. @@ -40,9 +40,9 @@ Parameters ====== ======= Type Default ------ ------- - double 0.2 + double 0.2 ====== ======= - + Description Minimum angular velocity before applying penalty. @@ -51,9 +51,9 @@ Parameters ====== ======= Type Default ------ ------- - double 10.0 + double 10.0 ====== ======= - + Description Weight for angular velocity component. @@ -62,8 +62,8 @@ Parameters ====== ======= Type Default ------ ------- - double 1.0 + double 1.0 ====== ======= - + Description Weighed scale for critic. diff --git a/configuration/packages/trajectory_critics/rotate_to_goal.rst b/configuration/packages/trajectory_critics/rotate_to_goal.rst index d81059c358..41534449c8 100644 --- a/configuration/packages/trajectory_critics/rotate_to_goal.rst +++ b/configuration/packages/trajectory_critics/rotate_to_goal.rst @@ -18,9 +18,9 @@ Parameters ====== ======= Type Default ------ ------- - double 0.25 + double 0.25 ====== ======= - + Description Tolerance to meet goal completion criteria (m). @@ -29,9 +29,9 @@ Parameters ====== ======= Type Default ------ ------- - double 0.25 + double 0.25 ====== ======= - + Description Velocity below is considered to be stopped at tolerance met (rad/s). @@ -40,9 +40,9 @@ Parameters ====== ======= Type Default ------ ------- - double 5.0 + double 5.0 ====== ======= - + Description Factor to slow robot motion by while rotating to goal. @@ -51,9 +51,9 @@ Parameters ====== ======= Type Default ------ ------- - double -1 + double -1 ====== ======= - + Description If > 0, amount of time to look forward for a collision for.. @@ -62,8 +62,8 @@ Parameters ====== ======= Type Default ------ ------- - double 1.0 + double 1.0 ====== ======= - + Description Weighed scale for critic. diff --git a/configuration/packages/trajectory_critics/twirling.rst b/configuration/packages/trajectory_critics/twirling.rst index f983b32c75..45d3f31078 100644 --- a/configuration/packages/trajectory_critics/twirling.rst +++ b/configuration/packages/trajectory_critics/twirling.rst @@ -17,8 +17,8 @@ Parameters ====== ======= Type Default ------ ------- - double 1.0 + double 1.0 ====== ======= - + Description Weighed scale for critic. diff --git a/development_guides/involvement_docs/index.rst b/development_guides/involvement_docs/index.rst index c7103f295e..452c657fdd 100644 --- a/development_guides/involvement_docs/index.rst +++ b/development_guides/involvement_docs/index.rst @@ -128,4 +128,3 @@ agreement is shown below and at http://developercertificate.org/. sign-off) is maintained indefinitely and may be redistributed consistent with this project or the open source license(s) involved. - diff --git a/getting_started/index.rst b/getting_started/index.rst index 6053972d82..86906a8282 100644 --- a/getting_started/index.rst +++ b/getting_started/index.rst @@ -63,9 +63,9 @@ Running the Example .. code-block:: bash ros2 launch nav2_bringup tb3_simulation_launch.py headless:=False - + .. note:: - + ``headless`` defaults to true; if not set to false, gzclient (the 3d view) is not started. This launch file will launch Nav2 with the AMCL localizer in the diff --git a/index.rst b/index.rst index 654a3786ba..9a1e7ef7c1 100644 --- a/index.rst +++ b/index.rst @@ -57,7 +57,7 @@ map source if utilizing the Static Costmap Layer, a BT XML file, and any relevan sources. It will then provide valid velocity commands for the motors of a holonomic or non-holonomic robot to follow when properly configured. We currently support all of the major robot types: holonomic, differential-drive, legged, and ackermann (car-like) base types! We support -them uniquely with both circular and arbitrarily-shaped robots for SE2 collision checking. +them uniquely with both circular and arbitrarily-shaped robots for SE2 collision checking. It has tools to: @@ -68,10 +68,10 @@ It has tools to: - Control the robot to follows the path and dynamically adjust to avoid collision - Smooth plans to be more continuous, smooth, and/or feasible - Convert sensor data into an environmental model of the world -- Build complicated and highly-customizable robot behaviors using behavior trees +- Build complicated and highly-customizable robot behaviors using behavior trees - Conduct pre-defined behaviors in case of failure, human intervention, or other - Follow sequential waypoints comprising a mission -- Manage the system's program lifecycle and watchdog for the servers +- Manage the system's program lifecycle and watchdog for the servers - Easy dynamically loaded plugins for creating customized algorithms, behaviors and so on - Monitor raw sensor data for imminent collision or dangerous situation - Python3 API to interact with Nav2 and its internal task servers in a pythonic manner @@ -83,7 +83,7 @@ It has tools to: :align: center :alt: Navigation2 Block Diagram -We also provide a set of starting plugins to get you going. +We also provide a set of starting plugins to get you going. A list of all plugins can be found on :ref:`plugins` - but they include algorithms for the spanning cross section of common behaviors and robot platform types. Related Projects @@ -135,7 +135,7 @@ Robotics and Autonomous Systems, 2023 .. code-block:: bash @article{macenski2023survey, - title={From the desks of ROS maintainers: A survey of modern & capable mobile robotics algorithms in the robot operating system 2}, + title={From the desks of ROS maintainers: A survey of modern & capable mobile robotics algorithms in the robot operating system 2}, author={S. Macenski, T. Moore, DV Lu, A. Merzlyakov, M. Ferguson}, year={2023}, journal = {Robotics and Autonomous Systems} @@ -149,7 +149,7 @@ S. Macenski, M. Booker, J. Wallace, .. code-block:: bash @article{macenski2024smac, - title={Open-Source, Cost-Aware Kinematically Feasible Planning for Mobile and Surface Robotics}, + title={Open-Source, Cost-Aware Kinematically Feasible Planning for Mobile and Surface Robotics}, author={Steve Macenski and Matthew Booker and Josh Wallace}, year={2024}, journal = {Arxiv} @@ -157,14 +157,14 @@ S. Macenski, M. Booker, J. Wallace, Regulated Pure Pursuit Controller: -S. Macenski, S. Singh, F. Martin, J. Gines, +S. Macenski, S. Singh, F. Martin, J. Gines, `Regulated Pure Pursuit for Robot Path Tracking `_, Autonomous Robots, 2023. .. code-block:: bash @article{macenski2023regulated, - title={Regulated Pure Pursuit for Robot Path Tracking}, + title={Regulated Pure Pursuit for Robot Path Tracking}, author={Steve Macenski and Shrijit Singh and Francisco Martin and Jonatan Gines}, year={2023}, journal = {Autonomous Robots} diff --git a/migration/Foxy.rst b/migration/Foxy.rst index 169b822c87..ea049875ab 100644 --- a/migration/Foxy.rst +++ b/migration/Foxy.rst @@ -26,9 +26,9 @@ NavigateThroughPoses and ComputePathThroughPoses Actions Added The ``NavigateThroughPoses`` action has been added analog to the ``NavigateToPose``. Rather than going to a single position, this Action will allow a user to specify a number of hard intermediary pose constraints between the start and final pose to plan through. The new ``ComputePathThroughPoses`` action has been added to the ``planner_server`` to process these requests through ``N goal_poses``. -The ``ComputePathThroughPoses`` action server will take in a set of ``N`` goals to achieve, plan through each pose and concatenate the output path for use in navigation. The controller and navigator know nothing about the semantics of the generated path, so the robot will not stop or slow on approach to these goals. It will rather continue through each pose as it were any other point on the path continuously. When paired with the ``SmacPlanner``, this feature can be used to generate **completely kinematically feasible trajectories through pose constraints**. +The ``ComputePathThroughPoses`` action server will take in a set of ``N`` goals to achieve, plan through each pose and concatenate the output path for use in navigation. The controller and navigator know nothing about the semantics of the generated path, so the robot will not stop or slow on approach to these goals. It will rather continue through each pose as it were any other point on the path continuously. When paired with the ``SmacPlanner``, this feature can be used to generate **completely kinematically feasible trajectories through pose constraints**. -If you wish to stop at each goal pose, consider using the waypoint follower instead, which will stop and allow a user to optionally execute a task plugin at each pose. +If you wish to stop at each goal pose, consider using the waypoint follower instead, which will stop and allow a user to optionally execute a task plugin at each pose. ComputePathToPose BT-node Interface Changes ******************************************* @@ -74,7 +74,7 @@ For example: you could use for some specific navigation motion a more precise go - The previous usage of the ``goal_checker_plugin`` parameter to declare the controller_server goal_checker is now obsolete and removed. -- The controller_server parameters now support the declaration of a list of goal checkers ``goal_checker_plugins`` mapped to unique identifier names, such as is the case with ``FollowPath`` and ``GridBased`` for the controller and planner plugins, respectively. +- The controller_server parameters now support the declaration of a list of goal checkers ``goal_checker_plugins`` mapped to unique identifier names, such as is the case with ``FollowPath`` and ``GridBased`` for the controller and planner plugins, respectively. - The specification of the selected goal checker is mandatory when more than one checker is defined in the controller_server parameter configuration. If only one goal_checker is configured in the controller_server it is selected by default even if no goal_checker is specified. @@ -107,16 +107,16 @@ Enabled by default. New Plugins *********** -``nav2_waypoint_follower`` has an action server that takes in a list of waypoints to follow and follow them in order. In some cases we might want robot to +``nav2_waypoint_follower`` has an action server that takes in a list of waypoints to follow and follow them in order. In some cases we might want robot to perform some tasks/behaviours at arrivals of these waypoints. In order to perform such tasks, a generic plugin interface `WaypointTaskExecutor` has been added to ``nav2_core``. -Users can inherit from this interface to implement their own plugin to perform more specific tasks at waypoint arrivals for their needs. +Users can inherit from this interface to implement their own plugin to perform more specific tasks at waypoint arrivals for their needs. -Several example implementations are included in ``nav2_waypoint_follower``. ``WaitAtWaypoint`` and ``PhotoAtWaypoint`` plusings are included in +Several example implementations are included in ``nav2_waypoint_follower``. ``WaitAtWaypoint`` and ``PhotoAtWaypoint`` plusings are included in ``nav2_waypoint_follower`` as run-time loadable plugins. ``WaitAtWaypoint`` simply lets robot to pause for a specified amount of time in milliseconds, at waypoint arrivals. While ``PhotoAtWaypoint`` takes photos at waypoint arrivals and saves the taken photos to specified directory, the format for taken photos also can be configured through parameters. All major image formats such as ``png``, ``jpeg``, ``jpg`` etc. are supported, the default format is ``png``. -Loading a plugin of this type is done through ``nav2_bringup/params/nav2_param.yaml``, by specifying plugin's name, type and it's used parameters. +Loading a plugin of this type is done through ``nav2_bringup/params/nav2_param.yaml``, by specifying plugin's name, type and it's used parameters. .. code-block:: yaml @@ -193,7 +193,7 @@ Standard time units in parameters ********************************* To follow the SI units outlined in REP-103 to the "T" nodes below were modified to use seconds consistently in every parameter. Under each node name you can see which parameters changed to seconds instead of using milliseconds. -- lifecycle manager +- lifecycle manager - ``bond_timeout_ms`` became ``bond_timeout`` in seconds @@ -216,9 +216,9 @@ Raytracing functionality was modified to include a minimum range parameter from - ``raytrace_max_range`` controls the maximum range to which ray tracing clears obstacles from the costmap - voxel_layer plugin - + - ``raytrace_min_range`` controls the minimum range from which ray tracing clears obstacles from the costmap - + - ``raytrace_max_range`` controls the maximum range to which ray tracing clears obstacles from the costmap Obstacle Marking Parameters @@ -269,7 +269,7 @@ Original GitHub tickets: - `RemovePassedGoals `_ - `ComputePathThroughPoses `_ -Additionally, behavior tree nodes were modified to contain their own local executors to spin for actions, topics, services, etc to ensure that each behavior tree node is independent of each other (e.g. spinning in one BT node doesn't trigger a callback in another). +Additionally, behavior tree nodes were modified to contain their own local executors to spin for actions, topics, services, etc to ensure that each behavior tree node is independent of each other (e.g. spinning in one BT node doesn't trigger a callback in another). sensor_msgs/PointCloud to sensor_msgs/PointCloud2 Change ******************************************************** @@ -290,7 +290,7 @@ Removed BT XML Launch Configurations ************************************ The launch python configurations for CLI setting of the behavior tree XML file has been removed. Instead, you should use the yaml files to set this value. If you, however, have a ``path`` to the yaml file that is inconsistent in a larger deployment, you can use the ``RewrittenYaml`` tool in your parent launch file to remap the default XML paths utilizing the ``get_shared_package_path()`` directory finder (or as you were before in python3). -The use of map subscription QoS launch configuration was also removed, use parameter file. +The use of map subscription QoS launch configuration was also removed, use parameter file. This change was introduced in this `pull request 2295 `_. Nav2 RViz Panel Action Feedback Information diff --git a/migration/Humble.rst b/migration/Humble.rst index a5c7129ef1..bd73a4b621 100644 --- a/migration/Humble.rst +++ b/migration/Humble.rst @@ -73,7 +73,7 @@ The following errors codes are supported (with more to come as necessary): Unkno The following error codes are supported (with more to come as necessary): Unknown, TF Error, Invalid Path, Patience Exceeded, Failed To Make Progress, or No Valid Control. -`PR #3251 `_ pipes the highest priority error code through the bt_navigator and defines the error code structure. +`PR #3251 `_ pipes the highest priority error code through the bt_navigator and defines the error code structure. A new parameter for the the BT Navigator called "error_code_id_names" was added to the nav2_params.yaml to define the error codes to compare. The lowest error in the "error_code_id_names" is then returned in the action request (navigate to pose, navigate through poses waypoint follower), whereas the code enums increase the higher up in the software stack - giving higher priority to lower-level failures. @@ -112,7 +112,7 @@ Changes to Map yaml file path for map_server node in Launch SmootherSelector BT Node ************************ -`PR #3283 `_ adds a BT node to set the smoother based on a topic or a default. See the configuration guide :ref:`configuring_simple_smoother` for more details. +`PR #3283 `_ adds a BT node to set the smoother based on a topic or a default. See the configuration guide :ref:`configuring_simple_smoother` for more details. Publish Costmap Layers @@ -121,12 +121,12 @@ Publish Costmap Layers Give Behavior Server Access to Both Costmaps ******************************************** -`PR #3255 `_ adds the ability for a behavior to access the local and global costmap. +`PR #3255 `_ adds the ability for a behavior to access the local and global costmap. To update behaviors, any reference to the global_frame must be updated to the local_frame parameter along with the ``configuration`` method which now takes in the local and global collision checkers. Lastly, ``getResourceInfo`` must be overridden to return ``CostmapInfoType::LOCAL``. Other options include ``GLOBAL`` if the behavior uses global costmap and/or footprint) -or ``BOTH`` if both are required. This allows us to only create and maintain the minimum amount of expensive resources. +or ``BOTH`` if both are required. This allows us to only create and maintain the minimum amount of expensive resources. New Model Predictive Path Integral Controller ********************************************* @@ -137,7 +137,7 @@ See the README.md and :ref:`configuring_mppic` page for more detail. Behavior Tree Uses Error Codes ****************************** -`PR #3324 `_ adds three new condition nodes to check for error codes on the blackboard set by action BT nodes which contain them. +`PR #3324 `_ adds three new condition nodes to check for error codes on the blackboard set by action BT nodes which contain them. The ``AreErrorCodesPresent`` condition node allows the user to specify the error code from the server along with the error codes to match against. The ``WouldAControllerRecoveryHelp`` checks if the active error code is UNKNOWN, PATIENCE_EXCEEDED, FAILED_TO_MAKE_PROGRESS or NO_VALID_CONTROL. @@ -203,11 +203,11 @@ Beware that it is a breaking change and that configuration files will need to be IsBatteryChargingCondition BT Node ********************************** -`PR #3553 `_ adds a BT node to check if the battery is charging. See the configuration guide :ref:`bt_is_battery_charging_condition` for more details. +`PR #3553 `_ adds a BT node to check if the battery is charging. See the configuration guide :ref:`bt_is_battery_charging_condition` for more details. Behavior Server Error Codes *************************** -`PR #3569 `_ updates the behavior server plugins to provide error codes on failure. +`PR #3569 `_ updates the behavior server plugins to provide error codes on failure. - Spin: NONE: 0, UNKNOWN: 701, server error codes: 701-709 - BackUp: NONE: 0, UNKNOWN: 801, server error codes: 710-719 diff --git a/migration/Iron.rst b/migration/Iron.rst index 5af30185e8..fa8441e253 100644 --- a/migration/Iron.rst +++ b/migration/Iron.rst @@ -61,14 +61,14 @@ The Collision Monitor and Velocity Smoothers also had ``use_realtime_priority`` ``opennav_coverage`` Project **************************** -A new metapackage exists in: https://github.com/open-navigation/opennav_coverage which contains complete coverage navigator plugins, BT nodes, behavior tree demos, and coverage planning server based on ``Fields2Cover``. See that project for more information. It is on long-term trajectory for inclusion into ``Nav2``, but there are still yet a few missing features from Fields2Cover before we can integrate that into the main project to be up to snuff in terms of all the major features and capabilities users would expect from a coverage planning system. +A new metapackage exists in: https://github.com/open-navigation/opennav_coverage which contains complete coverage navigator plugins, BT nodes, behavior tree demos, and coverage planning server based on ``Fields2Cover``. See that project for more information. It is on long-term trajectory for inclusion into ``Nav2``, but there are still yet a few missing features from Fields2Cover before we can integrate that into the main project to be up to snuff in terms of all the major features and capabilities users would expect from a coverage planning system. If you'd like to see coverage planning in Nav2 directly, please consider contributing `to the as-of-yet needed features described here `_. ``opennav_docking`` Project **************************** -A new metapackage exists in: https://github.com/open-navigation/opennav_docking which contains complete automatic charging dock framework, BT nodes, plugins, and demos. +A new metapackage exists in: https://github.com/open-navigation/opennav_docking which contains complete automatic charging dock framework, BT nodes, plugins, and demos. This allows for docking of any type of robot with any type of charging dock in a repeatable and generalized way. It will be integrated into Nav2 directly soon (Update June 2024: within Nav2 stack directly ``nav2_docking``!) @@ -86,21 +86,21 @@ New option for the Voxel and Obstacle Layers `PR #3612 `_ adds a new MaxWithoutUnknownOverwrite option to combination_method parameter in Voxel and Obstacle Layers. This can be used to make sure that the static map is the dominant source of information, and easily prevent the robot to go through places that are not present in the static map. -use_interpolation RPP Parameter Depreciated +use_interpolation RPP Parameter Depreciated ******************************************* After a distribution of testing by many users, we have depreciated the use_interpolation parameter and it is now default on at all times without the ability to disable. It improves velocity smoothness and overall quality of tracking positively in all cases. Changes to MPPI Goal Critic *************************** -The MPPI Goal critic's formulation is changed to better keep up with speed on approach to goal instead of preemptively slowing too significantly. It also allows you to better use the weight to adjust the degree at which it slows more naturally. This change involves adjusting the ``threshold_to_consider`` to be the same as your prediction horizon (e.g. samples * dt * max speed) for both the goal critic and path follower critic to have a good hand-off between them without deceleration. +The MPPI Goal critic's formulation is changed to better keep up with speed on approach to goal instead of preemptively slowing too significantly. It also allows you to better use the weight to adjust the degree at which it slows more naturally. This change involves adjusting the ``threshold_to_consider`` to be the same as your prediction horizon (e.g. samples * dt * max speed) for both the goal critic and path follower critic to have a good hand-off between them without deceleration. Changes to MPPI Path Angle Critic ********************************* -MPPI's Path Angle critic now has a ``mode`` setting to adjust behavior depending on robot's desired behavioral traits. Previously, it penalized path orientations that deviated far the the robot's forward orientation to turn the robot towards sharp changes in the path. This is still default (``mode: 0``), but other modes now exist too. +MPPI's Path Angle critic now has a ``mode`` setting to adjust behavior depending on robot's desired behavioral traits. Previously, it penalized path orientations that deviated far the the robot's forward orientation to turn the robot towards sharp changes in the path. This is still default (``mode: 0``), but other modes now exist too. -``mode: 1`` sets the penalization of path's relative directions by either forward orientation or the opposite for reversing to allow for true bidirectional motion when one way or another is not preferable for a symmetric robot. This uses only the path's relative points to the robot to decide which direction to incentivize. +``mode: 1`` sets the penalization of path's relative directions by either forward orientation or the opposite for reversing to allow for true bidirectional motion when one way or another is not preferable for a symmetric robot. This uses only the path's relative points to the robot to decide which direction to incentivize. ``mode: 2`` instead uses the path's orientations when a feasible path is given from the Smac Planners or the Smoother server's algorithms. This way, the globally planned orientations are followed rather than the based solely on the path's relative points. This is useful for non-circular robots in highly confined settings where there may be restricted opportunities to change directions so following the global path's orientation are required to end in the orientation you require. @@ -127,7 +127,7 @@ New to Jazzy, MPPI is 45% faster due to a weeks long optimization campaign. Enjo Move Error Code Enumerations **************************** -`PR #3693 `_ moves the enumeration codes from the goal to the result section. +`PR #3693 `_ moves the enumeration codes from the goal to the result section. Substitution in parameter file ****************************** @@ -162,17 +162,17 @@ This PR also introduces additional analytic expansion scoring logic and edge cas Added GPS Waypoint Follower Server ********************************** -`This PR 2814 `_ adds the ``follow_gps_waypoints`` action server in ``nav2_waypoint_follower``. This server accepts a set of GPS goals instead of cartesian goals and provides all the other functionalities available on ``nav2_waypoint_follower``. A new tutorial demonstrating its functionality was also added on `PR 70 on navigation2_tutorials `_ and can be found on the General Tutorials directory on this website. +`This PR 2814 `_ adds the ``follow_gps_waypoints`` action server in ``nav2_waypoint_follower``. This server accepts a set of GPS goals instead of cartesian goals and provides all the other functionalities available on ``nav2_waypoint_follower``. A new tutorial demonstrating its functionality was also added on `PR 70 on navigation2_tutorials `_ and can be found on the General Tutorials directory on this website. Smac Planner Hybrid-A* New Features *********************************** -New features ``allow_primitive_interpolation`` which allows for more primitives in the search set, ``use_quadratic_cost_penalty`` to impact the cost penalty order in the traversal and heuristic functions, and ``downsample_obstacle_heuristic`` to optionally not downsample the obstacle heuristic's costmap were added. The default behavior will remain the same. If you would like to use these new features, please check out the Smac Planner Hybrid-A* configuration guide. +New features ``allow_primitive_interpolation`` which allows for more primitives in the search set, ``use_quadratic_cost_penalty`` to impact the cost penalty order in the traversal and heuristic functions, and ``downsample_obstacle_heuristic`` to optionally not downsample the obstacle heuristic's costmap were added. The default behavior will remain the same. If you would like to use these new features, please check out the Smac Planner Hybrid-A* configuration guide. New node in nav2_collision_monitor: Collision Detector ****************************************************** -In this `PR #3693 `_ A new node was introduced in the nav2_collision_monitor: Collision Detector. +In this `PR #3693 `_ A new node was introduced in the nav2_collision_monitor: Collision Detector. It works similarly to the Collision Monitor, but does not affect the robot's velocity. It will only inform that data from the configured sources has been detected within the configured polygons via message to the ``collision_detector_state`` topic that might be used by any external module (e.g. switching LED or sound alarm in case of collision). Dynamic enabling/disabling of sources/polygons in Collision Monitor/Detector @@ -183,7 +183,7 @@ In this `PR #3825 `_ we Expose action server's result timeout ************************************* -In this `PR #3787 `_ the timeout for action server's result was exposed in all nodes having action servers. +In this `PR #3787 `_ the timeout for action server's result was exposed in all nodes having action servers. This is because in this `PR #1012 `_ in rcl a change was introduced which makes action servers discard a goal handle if the result is not produced within 10 seconds, when the default was set to 15 minutes before. Since some actions in Nav2 may take more than 10 seconds to complete, the user has now the ability to set this value through the ``action_server_result_timeout`` parameter, which defaults to 15 minutes in the ``bt_navigators`` and ``waypoint_follower`` and to 10 seconds in all other nodes. @@ -241,7 +241,7 @@ Introduction of ``CostmapUpdate.msg`` `PR #3965 `_ introduces a new type of message - ``CostmapUpdate.msg``. It is the update message related to the ``Costmap.msg``. Now instead of sending the whole costmap in every message, such as with ``Costmap.msg``, the ``CostmapUpdate.msg`` includes only the area of the costmap that has changed since the previous update message. The ``Costmap.msg`` is sent only once at the beginning, followed by the messages of the ``CostmapUpdate.msg`` type. The idea is to mimic the ``OccupancyGrid.msg`` and ``OccupancyGridUpdate.msg`` behavior. -To activate this feature, the Costmap2D ROS parameter ``always_send_full_costmap`` has to be set to ``false``. +To activate this feature, the Costmap2D ROS parameter ``always_send_full_costmap`` has to be set to ``false``. To subscribe to ``Costmap.msg`` and ``CostmapUpdate.msg`` it is recommended to use the ``CostmapSubscriber`` class. @@ -269,7 +269,7 @@ New RViz Plugin for selecting Planners, Controllers, Goal Checkers, Progress Che The primary goal of this plugin is to facilitate the developers and easy integration testing of their configuration before deploying the robot in the intended application. -In order to facilitate the dynamic selection of the specified components, the BT selector nodes for all these components were utilized and were updated to all the relevant BT nodes. +In order to facilitate the dynamic selection of the specified components, the BT selector nodes for all these components were utilized and were updated to all the relevant BT nodes. Here we can see the working demo of the plugin: @@ -284,7 +284,7 @@ In this case, the `FollowPath` is the default controller_id. The difference betw RPP new optional ``interpolate_curvature_after_goal`` behavior and fix conflict between ``use_rotate_to_heading`` and ``allow_reversing`` ***************************************************************************************************************************************** -`In PR #4140 `_ a new optional ``interpolate_curvature_after_goal`` parameter (default ``false``) was added that activates the interpolation of a carrot after the goal in order to maintain a constant curvature lookahead distance. This is to avoid instabilities at the end of the path on the generation of the angular speed. The carrot used for the linear speed computation stays the same. +`In PR #4140 `_ a new optional ``interpolate_curvature_after_goal`` parameter (default ``false``) was added that activates the interpolation of a carrot after the goal in order to maintain a constant curvature lookahead distance. This is to avoid instabilities at the end of the path on the generation of the angular speed. The carrot used for the linear speed computation stays the same. Interpolation is based on the orientation of the vector formed by the last 2 poses of the path. Hence paths of length 1 are rejected when ``interpolate_curvature_after_goal`` is ``true``. It can be used only when ``use_fixed_curvature_lookahead: true``. @@ -302,8 +302,8 @@ New interface for ``GlobalPlanner::createPlan``: .. code-block:: cpp virtual nav_msgs::msg::Path createPlan( - const geometry_msgs::msg::PoseStamped & start, - const geometry_msgs::msg::PoseStamped & goal, + const geometry_msgs::msg::PoseStamped & start, + const geometry_msgs::msg::PoseStamped & goal, std::function cancel_checker) This is implemented for all the planners in the stack, you can check them for the example use of ``cancel_checker`` function (simply check ``cancel_checker()``). @@ -357,10 +357,10 @@ Rotation Shim Controller: new parameter ``rotate_to_goal_heading`` ****************************************************************** `PR #4332 `_ introduces usage of parameter ``rotate_to_goal_heading`` for the rotation shim controller. It allows the rotation shim controller to take back control when reaching the XY goal tolerance to perform a clean rotation towards the goal heading. Some controllers will do this internally, but it is a useful option for others. -MPPI Controller: Addition of acceleration constraints +MPPI Controller: Addition of acceleration constraints ****************************************************** `PR #4352 `_ adds new parameters ``ax_max``, ``ax_min``, ``ay_max``, ``az_max`` for the MPPI controller. These parameters will enable the MPPI controller to generate local trajectories within the specified acceleration constraints. RegulatedPurePursuit Controller [RPP]: new parameter ``use_cancel_deceleration`` ******************************************************************************** -`PR #4441 `_ adds a new parameter use_cancel_deceleration for the regulated pure pursuit controllers. This parameter enables the controller to use a constant deceleration to stop the robot gracefully instead of stopping immediately when a goal is canceled. \ No newline at end of file +`PR #4441 `_ adds a new parameter use_cancel_deceleration for the regulated pure pursuit controllers. This parameter enables the controller to use a constant deceleration to stop the robot gracefully instead of stopping immediately when a goal is canceled. diff --git a/plugin_tutorials/docs/writing_new_bt_plugin.rst b/plugin_tutorials/docs/writing_new_bt_plugin.rst index 305fe75b6d..9c9bdf5949 100644 --- a/plugin_tutorials/docs/writing_new_bt_plugin.rst +++ b/plugin_tutorials/docs/writing_new_bt_plugin.rst @@ -154,7 +154,7 @@ Plugins are loaded at runtime, and if they are not visible, then our BT Navigato In BehaviorTree.CPP, exporting and loading plugins is handled by the ``BT_REGISTER_NODES`` macro. .. code-block:: c++ - + BT_REGISTER_NODES(factory) { BT::NodeBuilder builder = @@ -195,7 +195,7 @@ In order for the BT Navigator node to discover the plugin we've just registered, default_nav_to_pose_bt_xml: replace/with/path/to/bt.xml # or $(find-pkg-share my_package)/behavior_tree/my_nav_to_pose_bt.xml default_nav_through_poses_bt_xml: replace/with/path/to/bt.xml # or $(find-pkg-share my_package)/behavior_tree/my_nav_through_poses_bt.xml plugin_lib_names: - - nav2_back_up_action_bt_node # other plugin + - nav2_back_up_action_bt_node # other plugin - nav2_wait_action_bt_node # our new plugin 4- Run Your Custom plugin diff --git a/plugin_tutorials/docs/writing_new_costmap2d_plugin.rst b/plugin_tutorials/docs/writing_new_costmap2d_plugin.rst index aaf82678d8..778789dd71 100644 --- a/plugin_tutorials/docs/writing_new_costmap2d_plugin.rst +++ b/plugin_tutorials/docs/writing_new_costmap2d_plugin.rst @@ -40,7 +40,7 @@ The plugin class ``nav2_gradient_costmap_plugin::GradientLayer`` is inherited fr namespace nav2_gradient_costmap_plugin { - + class GradientLayer : public nav2_costmap_2d::Layer The basic class provides the set of virtual methods API for working with costmap layers in a plugin. These methods are called at runtime by ``LayeredCostmap``. The list of methods, their description, and necessity to have these methods in plugin's code is presented in the table below: diff --git a/plugin_tutorials/docs/writing_new_nav2controller_plugin.rst b/plugin_tutorials/docs/writing_new_nav2controller_plugin.rst index 07d3a42152..fb498ecac6 100644 --- a/plugin_tutorials/docs/writing_new_nav2controller_plugin.rst +++ b/plugin_tutorials/docs/writing_new_nav2controller_plugin.rst @@ -18,7 +18,7 @@ Overview This tutorial shows how to create your own controller `plugin `_. -In this tutorial, we will be implementing the pure pursuit path tracking algorithm based on this `paper `_. +In this tutorial, we will be implementing the pure pursuit path tracking algorithm based on this `paper `_. It is recommended you go through it. Note: This tutorial is based on a previously existing simplified version of the Regulated Pure Pursuit controller now in the Nav2 stack. @@ -38,7 +38,7 @@ Tutorial Steps 1- Create a new Controller Plugin --------------------------------- -We will be implementing the pure pursuit controller. The annotated code in this tutorial can be found in `navigation_tutorials `_ repository +We will be implementing the pure pursuit controller. The annotated code in this tutorial can be found in `navigation_tutorials `_ repository as the ``nav2_pure_pursuit_controller``. This package can be considered as a reference for writing your own controller plugin. Our example plugin class ``nav2_pure_pursuit_controller::PurePursuitController`` inherits from the base class ``nav2_core::Controller``. The base class provides a @@ -127,16 +127,16 @@ In controllers, ``configure()`` method must set member variables from ROS parame transform_tolerance_ = rclcpp::Duration::from_seconds(transform_tolerance); } -Here, ``plugin_name_ + ".desired_linear_vel"`` is fetching the ROS parameter ``desired_linear_vel`` which is specific to our controller. +Here, ``plugin_name_ + ".desired_linear_vel"`` is fetching the ROS parameter ``desired_linear_vel`` which is specific to our controller. Nav2 allows loading of multiple plugins, and to keep things organized, each plugin is mapped to some ID/name. -Now, if we want to retrieve the parameters for that specific plugin, we use ``.`` as done in the above snippet. -For example, our example controller is mapped to the name ``FollowPath`` and to retrieve the ``desired_linear_vel`` parameter, which is specific to "FollowPath”, -we used ``FollowPath.desired_linear_vel``. In other words, ``FollowPath`` is used as a namespace for plugin-specific parameters. +Now, if we want to retrieve the parameters for that specific plugin, we use ``.`` as done in the above snippet. +For example, our example controller is mapped to the name ``FollowPath`` and to retrieve the ``desired_linear_vel`` parameter, which is specific to "FollowPath”, +we used ``FollowPath.desired_linear_vel``. In other words, ``FollowPath`` is used as a namespace for plugin-specific parameters. We will see more on this when we discuss the parameters file (or params file). The passed-in arguments are stored in member variables so that they can be used at a later stage if needed. -In ``setPlan()`` method, we receive the updated global path for the robot to follow. In our example, we transform the received global path into +In ``setPlan()`` method, we receive the updated global path for the robot to follow. In our example, we transform the received global path into the frame of the robot and then store this transformed global path for later use. .. code-block:: c++ @@ -201,8 +201,8 @@ The remaining methods are not used, but it's mandatory to override them. As per 2- Exporting the controller plugin ---------------------------------- -Now that we have created our custom controller, we need to export our controller plugin so that it will 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 them. In ROS 2, exporting and loading +Now that we have created our custom controller, we need to export our controller plugin so that it will 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 them. In ROS 2, exporting and loading plugins is handled by ``pluginlib``. Coming back to our tutorial, class ``nav2_pure_pursuit_controller::PurePursuitController`` is loaded dynamically as ``nav2_core::Controller`` which is our base class. @@ -210,7 +210,7 @@ Coming back to our tutorial, class ``nav2_pure_pursuit_controller::PurePursuitCo 1. To export the controller, we need to provide two lines .. code-block:: c++ - + #include "pluginlib/class_list_macros.hpp" PLUGINLIB_EXPORT_CLASS(nav2_pure_pursuit_controller::PurePursuitController, nav2_core::Controller) @@ -272,7 +272,7 @@ To enable the plugin, we need to modify the ``nav2_params.yaml`` file as below max_angular_vel: 1.0 transform_tolerance: 1.0 -In the above snippet, you can observe the mapping of our ``nav2_pure_pursuit_controller::PurePursuitController`` controller to its id ``FollowPath``. +In the above snippet, you can observe the mapping of our ``nav2_pure_pursuit_controller::PurePursuitController`` controller to its id ``FollowPath``. To pass plugin-specific parameters we have used ``.``. 4- Run Pure Pursuit Controller plugin @@ -284,6 +284,6 @@ Run Turtlebot3 simulation with enabled Nav2. Detailed instructions on how to mak $ ros2 launch nav2_bringup tb3_simulation_launch.py params_file:=/path/to/your_params_file.yaml -Then goto RViz and click on the "2D Pose Estimate" button at the top and point the location on the map as it was described in :ref:`getting_started`. -The robot will localize on the map and then click on the "Nav2 goal" and click on the pose where you want your robot to navigate to. +Then goto RViz and click on the "2D Pose Estimate" button at the top and point the location on the map as it was described in :ref:`getting_started`. +The robot will localize on the map and then click on the "Nav2 goal" and click on the pose where you want your robot to navigate to. After that controller will make the robot follow the global path. diff --git a/plugin_tutorials/docs/writing_new_nav2planner_plugin.rst b/plugin_tutorials/docs/writing_new_nav2planner_plugin.rst index 646547e658..b9a6a8c2b4 100644 --- a/plugin_tutorials/docs/writing_new_nav2planner_plugin.rst +++ b/plugin_tutorials/docs/writing_new_nav2planner_plugin.rst @@ -143,7 +143,7 @@ Coming back to our tutorial, class ``nav2_straightline_planner::StraightLine`` i 1. To export the planner, we need to provide two lines .. code-block:: c++ - + #include "pluginlib/class_list_macros.hpp" PLUGINLIB_EXPORT_CLASS(nav2_straightline_planner::StraightLine, nav2_core::GlobalPlanner) diff --git a/plugin_tutorials/docs/writing_new_navigator_plugin.rst b/plugin_tutorials/docs/writing_new_navigator_plugin.rst index fff8d4d567..a4d54271f5 100644 --- a/plugin_tutorials/docs/writing_new_navigator_plugin.rst +++ b/plugin_tutorials/docs/writing_new_navigator_plugin.rst @@ -14,7 +14,7 @@ This tutorial shows how to create your own behavior-tree navigator `plugin .``. 4- Run plugin @@ -349,6 +349,6 @@ Run Turtlebot3 simulation with enabled Nav2. Detailed instructions on how to mak $ ros2 launch nav2_bringup tb3_simulation_launch.py params_file:=/path/to/your_params_file.yaml -Then goto RViz and click on the "2D Pose Estimate" button at the top and point the location on the map as it was described in :ref:`getting_started`. -The robot will localize on the map and then click on the "Nav2 goal" and click on the pose where you want your robot to navigate to. +Then goto RViz and click on the "2D Pose Estimate" button at the top and point the location on the map as it was described in :ref:`getting_started`. +The robot will localize on the map and then click on the "Nav2 goal" and click on the pose where you want your robot to navigate to. After that navigator will take over with the behavior tree XML file behavior definition provided to it. diff --git a/setup_guides/footprint/setup_footprint.rst b/setup_guides/footprint/setup_footprint.rst index 00d1daa758..fc9889a9da 100644 --- a/setup_guides/footprint/setup_footprint.rst +++ b/setup_guides/footprint/setup_footprint.rst @@ -3,21 +3,21 @@ Setting Up the Robot's Footprint ################################ -In this guide, we will discuss how to configure the footprint of your robot for the navigation algorithms used by Nav2. We will also show a sample footprint configuration on ``sam_bot``, the simulated robot that we have been building in this series of setup guides. Lastly, we will also show the visualization of ``sam_bot``'s footprint in RViz to ensure that we have set it up correctly. +In this guide, we will discuss how to configure the footprint of your robot for the navigation algorithms used by Nav2. We will also show a sample footprint configuration on ``sam_bot``, the simulated robot that we have been building in this series of setup guides. Lastly, we will also show the visualization of ``sam_bot``'s footprint in RViz to ensure that we have set it up correctly. Footprint Introduction ********************** -The footprint outlines the robot's 2D shape when projected to the ground and is primarily used by Nav2 to avoid collisions during planning. The algorithms involved in this task makes sure that the robot does not collide with the obstacles in the costmap while it computes the robot's paths or plans. +The footprint outlines the robot's 2D shape when projected to the ground and is primarily used by Nav2 to avoid collisions during planning. The algorithms involved in this task makes sure that the robot does not collide with the obstacles in the costmap while it computes the robot's paths or plans. The footprint is set up using the ``footprint`` or ``robot_radius`` parameter of the global and local costmaps which we tackled in the previous tutorials (:ref:`Setting Up Sensors Guide`). The value defined in the ``footprint`` parameter is an ordered vector of 2-D points defining the robot's footprint with the ``base_link`` frame as the origin. The first and last points in the vector are joined into the last line segment to close the footprint's shape. As an alternative, you may also use the ``robot_radius`` parameter wherein circular footprint is automatically generated and centered at ``base_link``. In cases both the ``footprint`` and ``robot_radius`` parameters have been defined in the configuration, the ``footprint`` is used. .. seealso:: - A section in the previous guide, :ref:`Configuring nav2_costmap_2d`, explains how to configure basic costmap parameters. Please refer to that guide for more details on costmap configuration. + A section in the previous guide, :ref:`Configuring nav2_costmap_2d`, explains how to configure basic costmap parameters. Please refer to that guide for more details on costmap configuration. -For the global costmap footprint, the decision to choose between the ``robot_radius`` (circular) or ``footprint`` (polygon) parameter depends on the robot, its environment, and the path planning algorithm you will use. Even if you are working with a non-circular robot, there may be situations where a circular footprint is acceptable. For example, path planning algorithms like `NavFn `_ assume that the robot is circular since it only checks for collision per grid cell, so it will not be necessary to outline the robot's exact shape for its footprint. On the other hand, algorithms such as `Smac Planner's Hybrid-A* `_ perform collision checking on the robot's polygon-shaped footprint if possible and necessary. Hence, it might be useful to use a polygon-shaped footprint. Another example is having a small RC car sized robot roaming a warehouse. This robot is so small it won't need to make confined maneuvers -- thusly approximating it with the largest cross-sectional radius is a good time-saving optimization. +For the global costmap footprint, the decision to choose between the ``robot_radius`` (circular) or ``footprint`` (polygon) parameter depends on the robot, its environment, and the path planning algorithm you will use. Even if you are working with a non-circular robot, there may be situations where a circular footprint is acceptable. For example, path planning algorithms like `NavFn `_ assume that the robot is circular since it only checks for collision per grid cell, so it will not be necessary to outline the robot's exact shape for its footprint. On the other hand, algorithms such as `Smac Planner's Hybrid-A* `_ perform collision checking on the robot's polygon-shaped footprint if possible and necessary. Hence, it might be useful to use a polygon-shaped footprint. Another example is having a small RC car sized robot roaming a warehouse. This robot is so small it won't need to make confined maneuvers -- thusly approximating it with the largest cross-sectional radius is a good time-saving optimization. -For the local costmap footprint, it is typical for non-circular robots to be set up with ``footprint`` (polygon). Some situations where this is not recommended is when you do not have enough computing resources to implement collision avoidance algorithms on a polygon-shaped footprint. Another possible reason to use ``robot_radius`` (circular) for the local costmap is when the robot is very small relative to its environment such that precise collision avoidance is not necessary. However, generally the local trajectory planner should use the actual footprint polygon of the robot. +For the local costmap footprint, it is typical for non-circular robots to be set up with ``footprint`` (polygon). Some situations where this is not recommended is when you do not have enough computing resources to implement collision avoidance algorithms on a polygon-shaped footprint. Another possible reason to use ``robot_radius`` (circular) for the local costmap is when the robot is very small relative to its environment such that precise collision avoidance is not necessary. However, generally the local trajectory planner should use the actual footprint polygon of the robot. Note that this can also be adjusted over time using the costmap's ``~/footprint`` topic, which will update the polygon over time as needed due to changes in the robot's state, such as movement of an attached manipulator, picking up a pallet, or other actions that adjust a robot's shape. That polygon will then automatically be used by the planners and controllers. @@ -30,9 +30,9 @@ In this section, we will configure the footprint of ``sam_bot`` such that ``foot Under the ``config`` directory, create a new file named ``nav2_params.yaml``. Next, copy the contents of `config/nav2_params.yaml `_ and paste them into the newly created file. The contents of `config/nav2_params.yaml `_ are copied from the default configuration file of Nav2 but with changes in the ``footprint`` and ``robot_radius`` parameters to match the shape of ``sam_bot``. .. seealso:: - The default configuration file for Nav2 can be found in the official `Navigation2 repository `_. + The default configuration file for Nav2 can be found in the official `Navigation2 repository `_. -Below is the code snippet from ``nav2_params.yaml`` defining the local costmap footprint. In this configuration file, the ``footprint`` parameter of the local costmap has already been set with a rectangular-shaped footprint. This box is centered at the ``base_link`` frame of ``sam_bot``. +Below is the code snippet from ``nav2_params.yaml`` defining the local costmap footprint. In this configuration file, the ``footprint`` parameter of the local costmap has already been set with a rectangular-shaped footprint. This box is centered at the ``base_link`` frame of ``sam_bot``. .. code-block:: yaml :lineno-start: 188 @@ -54,7 +54,7 @@ Build, Run and Verification *************************** We will now confirm that we have properly set up ``sam_bot``'s footprint. -First, we launch `launch/display.launch.py `_ to launch the robot state publisher, spawn ``sam_bot`` in Gazebo, and visualize ``sam_bot`` and its footprint in Rviz. The robot state publisher publishes the ``base_link`` => ``sensors`` transforms defined in ``sam_bot``'s URDF, while Gazebo's differential drive plugin publishes the ``odom`` => ``base_link`` transform. Open a new terminal and execute the lines below. +First, we launch `launch/display.launch.py `_ to launch the robot state publisher, spawn ``sam_bot`` in Gazebo, and visualize ``sam_bot`` and its footprint in Rviz. The robot state publisher publishes the ``base_link`` => ``sensors`` transforms defined in ``sam_bot``'s URDF, while Gazebo's differential drive plugin publishes the ``odom`` => ``base_link`` transform. Open a new terminal and execute the lines below. .. code-block:: shell @@ -62,7 +62,7 @@ First, we launch `launch/display.launch.py ``odom`` transform using the ``static_transform_publisher``. We publish the ``map`` => ``odom`` transform as static in this guide as a simple way to publish the transform and visualize the footprint. Open a new terminal and execute the lines below. @@ -70,7 +70,7 @@ Next, we will publish the ``map`` => ``odom`` transform using the ``static_trans ros2 run tf2_ros static_transform_publisher 0 0 0 0 0 0 map odom -The ``map`` => ``odom`` transform should now be being published and the ``map`` frame should be added in RViz without errors. +The ``map`` => ``odom`` transform should now be being published and the ``map`` frame should be added in RViz without errors. Lastly, we will launch Nav2 using the ``nav2_params.yaml`` configuration file we just made and ``navigation_launch.py``, the built-in launch file of ``nav2_bringup``. Open a new terminal and execute the following: @@ -78,11 +78,11 @@ Lastly, we will launch Nav2 using the ``nav2_params.yaml`` configuration file we ros2 launch nav2_bringup navigation_launch.py params_file:= -We should now be able to visualize the footprints in RViz, which will be discussed in the next section. +We should now be able to visualize the footprints in RViz, which will be discussed in the next section. Visualizing Footprint in RViz ***************************** -To visualize the footprint of the local costmap, click the add button at the bottom-left part of the RViz window. Under the ``By topic`` tab, select the ``Polygon`` under the ``/local_costmap/published_footprint`` topic, as shown below. +To visualize the footprint of the local costmap, click the add button at the bottom-left part of the RViz window. Under the ``By topic`` tab, select the ``Polygon`` under the ``/local_costmap/published_footprint`` topic, as shown below. .. image:: images/add_topic_local_costmap.png :align: center @@ -93,7 +93,7 @@ Set the fixed frame in RViz to ``odom`` and you should see the rectangular-shape .. image:: images/polygon_footprint.png :align: center -On the other hand, for the global costmap, click the add button at the bottom-left part of the RViz window. Go to ``By topic`` tab then select the ``Polygon`` under the ``/global_costmap/published_footprint`` topic, as shown below. +On the other hand, for the global costmap, click the add button at the bottom-left part of the RViz window. Go to ``By topic`` tab then select the ``Polygon`` under the ``/global_costmap/published_footprint`` topic, as shown below. .. image:: images/add_topic_global_costmap.png :align: center @@ -106,6 +106,6 @@ Set the fixed frame in RViz to ``map`` and you should see the circular footprint Conclusion ********** -In this guide, we have shown how to configure a circular and polygon-shaped footprint for your robot. This footprint is important since it plays a major role in Nav2's pathfinding algorithms function. +In this guide, we have shown how to configure a circular and polygon-shaped footprint for your robot. This footprint is important since it plays a major role in Nav2's pathfinding algorithms function. -As a demo, we have configured the costmap footprint parameters of ``sam_bot``. We set the local costmap to use a polygon-shaped footprint following ``sam_bot``'s shape while we set the the global costmap to use a circular footprint. Lastly, we visualized and confirmed the footprints of the local and global costmaps in RViz. +As a demo, we have configured the costmap footprint parameters of ``sam_bot``. We set the local costmap to use a polygon-shaped footprint following ``sam_bot``'s shape while we set the the global costmap to use a circular footprint. Lastly, we visualized and confirmed the footprints of the local and global costmaps in RViz. diff --git a/setup_guides/index.rst b/setup_guides/index.rst index 0ecff203ec..9d107d1673 100644 --- a/setup_guides/index.rst +++ b/setup_guides/index.rst @@ -18,7 +18,7 @@ To guide you through the first-time setup of your robot, we will be tackling the - Setup sensor sources for robot odometry - Setup sensor sources for perception - Configure round or arbitrary shaped footprints for your robot -- Select and set up planner and controller navigation plugins for your robot's navigation tasks +- Select and set up planner and controller navigation plugins for your robot's navigation tasks - Lifecycle node management for easy bringup of other related sensors or nodes There are tutorials below for the Gazebo Classic simulator and the Gazebo simulator. Gazebo Classic is used with ROS 2 Humble and previous ROS distributions, while Gazebo (Gazebo Harmonic or newer) is used with ROS 2 Jazzy or newer. @@ -27,11 +27,11 @@ There are tutorials below for the Gazebo Classic simulator and the Gazebo simula Table of Contents ================= -.. raw:: html +.. raw:: html -
+
-
+

Gazebo

diff --git a/setup_guides/odom/setup_robot_localization.rst b/setup_guides/odom/setup_robot_localization.rst index 2c6c20923f..a5ad250b73 100644 --- a/setup_guides/odom/setup_robot_localization.rst +++ b/setup_guides/odom/setup_robot_localization.rst @@ -42,7 +42,7 @@ Next, we specify the parameters of the ``ekf_node`` using a YAML file. Create a # computation until it receives at least one message from one of the inputs. It will then run continuously at the # frequency specified here, regardless of whether it receives more measurements. Defaults to 30 if unspecified. frequency: 30.0 - + # ekf_localization_node and ukf_localization_node both use a 3D omnidirectional motion model. If this parameter is # set to true, no 3D information will be used in your state estimate. Use this if you are operating in a planar # environment and want to ignore the effect of small variations in the ground plane that might otherwise be detected @@ -54,21 +54,21 @@ Next, we specify the parameters of the ``ekf_node`` using a YAML file. Create a # Whether to broadcast the transformation over the /tf topic. Defaults to true if unspecified. publish_tf: true - + # 1. Set the map_frame, odom_frame, and base_link frames to the appropriate frame names for your system. # 1a. If your system does not have a map_frame, just remove it, and make sure "world_frame" is set to the value of odom_frame. - # 2. If you are fusing continuous position data such as wheel encoder odometry, visual odometry, or IMU data, set "world_frame" + # 2. If you are fusing continuous position data such as wheel encoder odometry, visual odometry, or IMU data, set "world_frame" # to your odom_frame value. This is the default behavior for robot_localization's state estimation nodes. - # 3. If you are fusing global absolute position data that is subject to discrete jumps (e.g., GPS or position updates from landmark + # 3. If you are fusing global absolute position data that is subject to discrete jumps (e.g., GPS or position updates from landmark # observations) then: # 3a. Set your "world_frame" to your map_frame value - # 3b. MAKE SURE something else is generating the odom->base_link transform. Note that this can even be another state estimation node + # 3b. MAKE SURE something else is generating the odom->base_link transform. Note that this can even be another state estimation node # from robot_localization! However, that instance should *not* fuse the global data. map_frame: map # Defaults to "map" if unspecified odom_frame: odom # Defaults to "odom" if unspecified base_link_frame: base_link # Defaults to "base_link" if unspecified world_frame: odom # Defaults to the value of odom_frame if unspecified - + odom0: demo/odom odom0_config: [false, false, false, false, false, false, diff --git a/setup_guides/sensors/mapping_localization.rst b/setup_guides/sensors/mapping_localization.rst index ba995075a9..db1162f54a 100644 --- a/setup_guides/sensors/mapping_localization.rst +++ b/setup_guides/sensors/mapping_localization.rst @@ -3,7 +3,7 @@ Mapping and Localization Now that we have a robot with its sensors set up, we can use the obtained sensor information to build a map of the environment and to localize the robot on the map. The ``slam_toolbox`` package is a set of tools and capabilities for 2D Simultaneous Localization and Mapping (SLAM) in potentially massive maps with ROS2. It is also one of the officially supported SLAM libraries in Nav2, and we recommend to use this package in situations you need to use SLAM on your robot setup. Aside from the ``slam_toolbox``, localization can also be implemented through the ``nav2_amcl`` package. This package implements Adaptive Monte Carlo Localization (AMCL) which estimates the position and orientation of the robot in a map. Other techniques may also be available, please check Nav2 documentation for more information. -Both the ``slam_toolbox`` and ``nav2_amcl`` use information from the laser scan sensor to be able to perceive the robot's environment. Hence, to verify that they can access the laser scan sensor readings, we must make sure that they are subscribed to the correct topic that publishes the ``sensor_msgs/LaserScan`` message. This can be configured by setting their ``scan_topic`` parameters to the topic that publishes that message. It is a convention to publish the ``sensor_msgs/LaserScan`` messages to ``/scan`` topic. Thus, by default, the ``scan_topic`` parameter is set to ``/scan``. Recall that when we added the lidar sensor to ``sam_bot`` in the previous section, we set the topic to which the lidar sensor will publish the ``sensor_msgs/LaserScan`` messages as ``/scan``. +Both the ``slam_toolbox`` and ``nav2_amcl`` use information from the laser scan sensor to be able to perceive the robot's environment. Hence, to verify that they can access the laser scan sensor readings, we must make sure that they are subscribed to the correct topic that publishes the ``sensor_msgs/LaserScan`` message. This can be configured by setting their ``scan_topic`` parameters to the topic that publishes that message. It is a convention to publish the ``sensor_msgs/LaserScan`` messages to ``/scan`` topic. Thus, by default, the ``scan_topic`` parameter is set to ``/scan``. Recall that when we added the lidar sensor to ``sam_bot`` in the previous section, we set the topic to which the lidar sensor will publish the ``sensor_msgs/LaserScan`` messages as ``/scan``. In-depth discussions on the complete configuration parameters will not be a scope of our tutorials since they can be pretty complex. Instead, we recommend you to have a look at their official documentation in the links below. @@ -11,15 +11,15 @@ In-depth discussions on the complete configuration parameters will not be a scop | For the complete list of configuration parameters of ``slam_toolbox``, see the `Github repository of slam_toolbox `_. | For the complete list of configuration parameters and example configuration of ``nav2_amcl``, see the `AMCL Configuration Guide `_. - + You can also refer to the `(SLAM) Navigating While Mapping guide `_ for the tutorial on how to use Nav2 with SLAM. You can verify that ``slam_toolbox`` and ``nav2_amcl`` have been correctly setup by visualizing the map and the robot's pose in RViz, similar to what was shown in the previous section. Costmap 2D ********** -The costmap 2D package makes use of the sensor information to provide a representation of the robot's environment in the form of an occupancy grid. The cells in the occupancy grid store cost values between 0-254 which denote a cost to travel through these zones. A cost of 0 means the cell is free while a cost of 254 means that the cell is lethally occupied. Values in between these extremes are used by navigation algorithms to steer your robot away from obstacles as a potential field. Costmaps in Nav2 are implemented through the ``nav2_costmap_2d`` package. +The costmap 2D package makes use of the sensor information to provide a representation of the robot's environment in the form of an occupancy grid. The cells in the occupancy grid store cost values between 0-254 which denote a cost to travel through these zones. A cost of 0 means the cell is free while a cost of 254 means that the cell is lethally occupied. Values in between these extremes are used by navigation algorithms to steer your robot away from obstacles as a potential field. Costmaps in Nav2 are implemented through the ``nav2_costmap_2d`` package. -The costmap implementation consists of multiple layers, each of which has a certain function that contributes to a cell's overall cost. The package consists of the following layers, but are plugin-based to allow customization and new layers to be used as well: static layer, inflation layer, range layer, obstacle layer, and voxel layer. The static layer represents the map section of the costmap, obtained from the messages published to the ``/map`` topic like those produced by SLAM. The obstacle layer includes the objects detected by sensors that publish either or both the ``LaserScan`` and ``PointCloud2`` messages. The voxel layer is similar to the obstacle layer such that it can use either or both the ``LaserScan`` and ``PointCloud2`` sensor information but handles 3D data instead. The range layer allows for the inclusion of information provided by sonar and infrared sensors. Lastly, the inflation layer represents the added cost values around lethal obstacles such that our robot avoids navigating into obstacles due to the robot's geometry. In the next subsection of this tutorial, we will have some discussion about the basic configuration of the different layers in ``nav2_costmap_2d``. +The costmap implementation consists of multiple layers, each of which has a certain function that contributes to a cell's overall cost. The package consists of the following layers, but are plugin-based to allow customization and new layers to be used as well: static layer, inflation layer, range layer, obstacle layer, and voxel layer. The static layer represents the map section of the costmap, obtained from the messages published to the ``/map`` topic like those produced by SLAM. The obstacle layer includes the objects detected by sensors that publish either or both the ``LaserScan`` and ``PointCloud2`` messages. The voxel layer is similar to the obstacle layer such that it can use either or both the ``LaserScan`` and ``PointCloud2`` sensor information but handles 3D data instead. The range layer allows for the inclusion of information provided by sonar and infrared sensors. Lastly, the inflation layer represents the added cost values around lethal obstacles such that our robot avoids navigating into obstacles due to the robot's geometry. In the next subsection of this tutorial, we will have some discussion about the basic configuration of the different layers in ``nav2_costmap_2d``. The layers are integrated into the costmap through a plugin interface and then inflated using a user-specified `inflation radius `_, if the inflation layer is enabled. For a deeper discussion on costmap concepts, you can have a look at the `ROS1 costmap_2D documentation `_. Note that the ``nav2_costmap_2d`` package is mostly a straightforward ROS2 port of the ROS1 navigation stack version with minor changes required for ROS2 support and some new layer plugins. @@ -27,7 +27,7 @@ The layers are integrated into the costmap through a plugin interface and then i Configuring nav2_costmap_2d =========================== -In this subsection, we will show an example configuration of ``nav2_costmap_2d`` such that it uses the information provided by the lidar sensor of ``sam_bot``. We will show an example configuration that uses static layer, obstacle layer, voxel layer, and inflation layer. We set both the obstacle and voxel layer to use the ``LaserScan`` messages published to the ``/scan`` topic by the lidar sensor. We also set some of the basic parameters to define how the detected obstacles are reflected in the costmap. Note that this configuration is to be included in the configuration file of Nav2. +In this subsection, we will show an example configuration of ``nav2_costmap_2d`` such that it uses the information provided by the lidar sensor of ``sam_bot``. We will show an example configuration that uses static layer, obstacle layer, voxel layer, and inflation layer. We set both the obstacle and voxel layer to use the ``LaserScan`` messages published to the ``/scan`` topic by the lidar sensor. We also set some of the basic parameters to define how the detected obstacles are reflected in the costmap. Note that this configuration is to be included in the configuration file of Nav2. .. code-block:: yaml :lineno-start: 1 @@ -104,13 +104,13 @@ In this subsection, we will show an example configuration of ``nav2_costmap_2d`` inflation_radius: 0.55 always_send_full_costmap: True -In the configuration above, notice that we set the parameters for two different costmaps: ``global_costmap`` and ``local_costmap``. We set up two costmaps since the ``global_costmap`` is mainly used for long-term planning over the whole map while ``local_costmap`` is for short-term planning and collision avoidance. +In the configuration above, notice that we set the parameters for two different costmaps: ``global_costmap`` and ``local_costmap``. We set up two costmaps since the ``global_costmap`` is mainly used for long-term planning over the whole map while ``local_costmap`` is for short-term planning and collision avoidance. The layers that we use for our configuration are defined in the ``plugins`` parameter, as shown in line 13 for the ``global_costmap`` and line 50 for the ``local_costmap``. These values are set as a list of mapped layer names that also serve as namespaces for the layer parameters we set up starting at lines 14 and line 51. Note that each layer/namespace in this list must have a ``plugin`` parameter (as indicated in lines 15, 18, 32, 52, and 68) defining the type of plugin to be loaded for that specific layer. -For the static layer (lines 14-16), we set the ``map_subscribe_transient_local`` parameter to ``True``. This sets the QoS settings for the map topic. Another important parameter for the static layer is the ``map_topic`` which defines the map topic to subscribe to. This defaults to ``/map`` topic when not defined. +For the static layer (lines 14-16), we set the ``map_subscribe_transient_local`` parameter to ``True``. This sets the QoS settings for the map topic. Another important parameter for the static layer is the ``map_topic`` which defines the map topic to subscribe to. This defaults to ``/map`` topic when not defined. -For the obstacle layer (lines 17-30), we define its sensor source under the ``observation_sources`` parameter (line 20) as ``scan`` whose parameters are set up in lines 22-30. We set its ``topic`` parameter as the topic that publishes the defined sensor source and we set the ``data_type`` according to the sensor source it will use. In our configuration, the obstacle layer will use the ``LaserScan`` published by the lidar sensor to ``/scan``. +For the obstacle layer (lines 17-30), we define its sensor source under the ``observation_sources`` parameter (line 20) as ``scan`` whose parameters are set up in lines 22-30. We set its ``topic`` parameter as the topic that publishes the defined sensor source and we set the ``data_type`` according to the sensor source it will use. In our configuration, the obstacle layer will use the ``LaserScan`` published by the lidar sensor to ``/scan``. Note that the obstacle layer and voxel layer can use either or both ``LaserScan`` and ``PointCloud2`` as their ``data_type`` but it is set to ``LaserScan`` by default. The code snippet below shows an example of using both the ``LaserScan`` and ``PointCloud2`` as the sensor sources. This may be particularly useful when setting up your own physical robot. @@ -127,13 +127,13 @@ Note that the obstacle layer and voxel layer can use either or both ``LaserScan` topic: /depth_camera/points data_type: "PointCloud2" -For the other parameters of the obstacle layer, the ``max_obstacle_height`` parameter sets the maximum height of the sensor reading to return to the occupancy grid. The minimum height of the sensor reading can also be set using the ``min_obstacle_height`` parameter, which defaults to 0 since we did not set it in the configuration. The ``clearing`` parameter is used to set whether the obstacle is to be removed from the costmap or not. The clearing operation is done by raytracing through the grid. The maximum and minimum range to raytrace clear objects from the costmap is set using the ``raytrace_max_range`` and ``raytrace_min_range`` respectively. The ``marking`` parameter is used to set whether the inserted obstacle is marked into the costmap or not. We also set the maximum and minimum range to mark obstacles in the costmap through the ``obstacle_max_range`` and ``obstacle_min_range`` respectively. +For the other parameters of the obstacle layer, the ``max_obstacle_height`` parameter sets the maximum height of the sensor reading to return to the occupancy grid. The minimum height of the sensor reading can also be set using the ``min_obstacle_height`` parameter, which defaults to 0 since we did not set it in the configuration. The ``clearing`` parameter is used to set whether the obstacle is to be removed from the costmap or not. The clearing operation is done by raytracing through the grid. The maximum and minimum range to raytrace clear objects from the costmap is set using the ``raytrace_max_range`` and ``raytrace_min_range`` respectively. The ``marking`` parameter is used to set whether the inserted obstacle is marked into the costmap or not. We also set the maximum and minimum range to mark obstacles in the costmap through the ``obstacle_max_range`` and ``obstacle_min_range`` respectively. -For the inflation layer (lines 31-34 and 67-70), we set the exponential decay factor across the inflation radius using the ``cost_scaling_factor`` parameter. The value of the radius to inflate around lethal obstacles is defined using the ``inflation_radius``. +For the inflation layer (lines 31-34 and 67-70), we set the exponential decay factor across the inflation radius using the ``cost_scaling_factor`` parameter. The value of the radius to inflate around lethal obstacles is defined using the ``inflation_radius``. For the voxel layer (lines 51-66), we set the ``publish_voxel_map`` parameter to ``True`` to enable the publishing of the 3D voxel grid. The resolution of the voxels in height is defined using the ``z_resolution`` parameter, while the number of voxels in each column is defined using the ``z_voxels`` parameter. The ``mark_threshold`` parameter sets the minimum number of voxels in a column to mark as occupied in the occupancy grid. We set the ``observation_sources`` parameter of the voxel layer to ``scan``, and we set the scan parameters (in lines 61-66) similar to the parameters that we have discussed for the obstacle layer. As defined in its ``topic`` and ``data_type`` parameters, the voxel layer will use the ``LaserScan`` published on the ``/scan`` topic by the lidar scanner. -Note that the we are not using a range layer for our configuration but it may be useful for your own robot setup. For the range layer, its basic parameters are the ``topics``, ``input_sensor_type``, and ``clear_on_max_reading`` parameters. The range topics to subscribe to are defined in the ``topics`` parameter. The ``input_sensor_type`` is set to either ``ALL``, ``VARIABLE``, or ``FIXED``. The ``clear_on_max_reading`` is a boolean parameter that sets whether to clear the sensor readings on max range. Have a look at the configuration guide in the link below in case you need to set it up. +Note that the we are not using a range layer for our configuration but it may be useful for your own robot setup. For the range layer, its basic parameters are the ``topics``, ``input_sensor_type``, and ``clear_on_max_reading`` parameters. The range topics to subscribe to are defined in the ``topics`` parameter. The ``input_sensor_type`` is set to either ``ALL``, ``VARIABLE``, or ``FIXED``. The ``clear_on_max_reading`` is a boolean parameter that sets whether to clear the sensor readings on max range. Have a look at the configuration guide in the link below in case you need to set it up. .. seealso:: For more information on ``nav2_costmap_2d`` and the complete list of layer plugin parameters, see the `Costmap 2D Configuration Guide `_. @@ -150,7 +150,7 @@ After we have properly setup our robot description, odometry sensors, and necess Launching Description Nodes, RViz and Gazebo -------------------------------------------- -Let us now launch our Robot Description Nodes, RViz and Gazebo through the launch file ``display.launch.py``. Open a new terminal and execute the lines below. +Let us now launch our Robot Description Nodes, RViz and Gazebo through the launch file ``display.launch.py``. Open a new terminal and execute the lines below. .. code-block:: shell @@ -175,7 +175,7 @@ We will launch the ``async_slam_toolbox_node`` of ``slam_toolbox`` using the pac ros2 launch slam_toolbox online_async_launch.py use_sim_time:=true -The ``slam_toolbox`` should now be publishing to the ``/map`` topic and providing the ``map`` => ``odom`` transform. +The ``slam_toolbox`` should now be publishing to the ``/map`` topic and providing the ``map`` => ``odom`` transform. We can verify in RViz that the ``/map`` topic is being published. In the RViz window, click the add button at the bottom-left part then go to ``By topic`` tab then select the ``Map`` under the ``/map`` topic. You should be able to visualize the message received in the ``/map`` as shown in the image below. @@ -208,11 +208,11 @@ We will now launch Nav2 using the ``nav2_bringup``'s built-in launch file, ``nav ros2 launch nav2_bringup navigation_launch.py use_sim_time:=true -Note that the parameters of the ``nav2_costmap_2d`` that we discussed in the previous subsection are included in the default parameters of ``navigation_launch.py``. Aside from the ``nav2_costmap_2d`` parameters, it also contains parameters for the other nodes that are included in Nav2 implementation. +Note that the parameters of the ``nav2_costmap_2d`` that we discussed in the previous subsection are included in the default parameters of ``navigation_launch.py``. Aside from the ``nav2_costmap_2d`` parameters, it also contains parameters for the other nodes that are included in Nav2 implementation. After we have properly set up and launched Nav2, the ``/global_costmap`` and ``/local_costmap`` topics should now be active. -.. note:: +.. note:: To make the costmaps show up, run the 3 commands in this order #. Launching Description Nodes, RViz and Gazebo - wait a bit for everything to launch @@ -229,7 +229,7 @@ To visualize the ``global_costmap`` in RViz, click the add button at the bottom- .. image:: images/costmap_global_rviz.png :align: center -To visualize the ``local_costmap`` in RViz, select the ``Map`` under the ``/local_costmap/costmap`` topic. Set the ``color scheme`` in RViz to ``costmap`` to make it appear similar to the image below. +To visualize the ``local_costmap`` in RViz, select the ``Map`` under the ``/local_costmap/costmap`` topic. Set the ``color scheme`` in RViz to ``costmap`` to make it appear similar to the image below. .. image:: images/local_costmap_rviz.png :align: center @@ -244,7 +244,7 @@ The line above sets the topic where the the markers will be published to ``/my_m .. image:: images/add_my_marker.png :align: center - :width: 49 % + :width: 49 % Then set the ``fixed frame`` in RViz to ``odom`` and you should now see the voxels in RViz, which represent the cube and the sphere that we have in the Gazebo world: @@ -254,5 +254,5 @@ Then set the ``fixed frame`` in RViz to ``odom`` and you should now see the voxe Conclusion ********** -In this section of our robot setup guide, we have discussed the importance of sensor information for different tasks associated with Nav2. More specifically, tasks such as mapping (SLAM), localization (AMCL), and perception (costmap) tasks. +In this section of our robot setup guide, we have discussed the importance of sensor information for different tasks associated with Nav2. More specifically, tasks such as mapping (SLAM), localization (AMCL), and perception (costmap) tasks. Then, we set up a basic configuration for the ``nav2_costmap_2d`` package using different layers to produce a global and local costmap. We then verify our work by visualizing these costmaps in RViz. diff --git a/setup_guides/sensors/setup_sensors_gz.rst b/setup_guides/sensors/setup_sensors_gz.rst index 27a49cca02..e245abfad5 100644 --- a/setup_guides/sensors/setup_sensors_gz.rst +++ b/setup_guides/sensors/setup_sensors_gz.rst @@ -3,13 +3,13 @@ Setting Up Sensors - Gazebo ########################### -In this guide, we will discuss the importance of the sensors in navigating a robot safely and how to set up the sensors with Nav2. In the first half of this tutorial, we will take a brief look at commonly used sensors and common sensor messages in Nav2. Next, we will add a basic sensor setup on our previously built simulated robot, ``sam_bot``. Lastly, we will then verify the simulated sensor messages of ``sam_bot`` by visualizing them in RViz. +In this guide, we will discuss the importance of the sensors in navigating a robot safely and how to set up the sensors with Nav2. In the first half of this tutorial, we will take a brief look at commonly used sensors and common sensor messages in Nav2. Next, we will add a basic sensor setup on our previously built simulated robot, ``sam_bot``. Lastly, we will then verify the simulated sensor messages of ``sam_bot`` by visualizing them in RViz. Once sensors have been set up on a robot, their readings can be used in mapping, localization, and perception tasks. In the second half of this guide, we will first discuss how mapping and localization use the sensor data. Then, we will also take a look at one of Nav2's packages, ``nav2_costmap_2d``, which generates costmaps that will eventually be used in Nav2 path planning. We will set up basic configuration parameters for this package so it properly takes in sensor information from ``sam_bot``. Lastly, we visualize a generated costmaps in RViz to verify its received data. Sensor Introduction ******************* -Mobile robots are equipped with a multitude of sensors that allow them to see and perceive their environment. These sensors obtain information which can be used to build and maintain the map of the environment, to localize the robot on the map, and to see the obstacles in the environment. These tasks are essential to be able to safely and efficiently navigate a robot through a dynamic environment. +Mobile robots are equipped with a multitude of sensors that allow them to see and perceive their environment. These sensors obtain information which can be used to build and maintain the map of the environment, to localize the robot on the map, and to see the obstacles in the environment. These tasks are essential to be able to safely and efficiently navigate a robot through a dynamic environment. Examples of commonly used sensors are lidar, radar, RGB camera, depth camera, IMU, and GPS. To standardize the message formats of these sensors and allow for easier interoperation between vendors, ROS provides the ``sensor_msgs`` package that defines the common sensor interfaces. This also allows users to use any sensor vendor as long as it follows the standard format in ``sensor_msgs``. In the next subsection, we introduce some of commonly used messages in navigation, namely the ``sensor_msgs/LaserScan``, ``sensor_msgs/PointCloud2``, ``sensor_msgs/Range``, and ``sensor_msgs/Image``. @@ -21,7 +21,7 @@ Aside from the ``sensor_msgs`` package, there are also the ``radar_msgs`` and `` Your physical robot's sensors probably have ROS drivers written for them (e.g. a ROS node that connects to the sensors, populates data into messages, and publishes them for your robot to use) that follow the standard interface in the ``sensor_msgs`` package. The ``sensor_msgs`` package makes it easy for you to use many different sensors from different manufacturers. General software packages like Nav2 can then read these standardized messages and perform tasks independent of the sensor hardware. On simulated robots such as ``sam_bot``, Gazebo has sensor plugins which also publish their information following the ``sensor_msgs`` package. Common Sensor Messages -====================== +====================== In this subsection, we discuss some of the common types of ``sensor_msgs`` you might encounter when setting up Nav2. We will provide a brief description for each sensor, an image of it being simulated in Gazebo and the corresponding visualization of the sensor readings in RViz. @@ -57,9 +57,9 @@ This represents the sensor readings from RGB or depth camera, corresponding to R Simulating Sensors using Gazebo ******************************* -To give you a better grasp of how to set up sensors on a simulated robot, we will build up on our previous tutorials and attach sensors to our simulated robot ``sam_bot``. Similar to the previous tutorial where we used Gazebo plugins to add odometry sensors to ``sam_bot``, we will be using the Gazebo plugins to simulate a lidar sensor and a depth camera on ``sam_bot``. If you are working with a real robot, most of these steps are still required for setting up your URDF frames and it will not hurt to also add in the gazebo plugins for later use. +To give you a better grasp of how to set up sensors on a simulated robot, we will build up on our previous tutorials and attach sensors to our simulated robot ``sam_bot``. Similar to the previous tutorial where we used Gazebo plugins to add odometry sensors to ``sam_bot``, we will be using the Gazebo plugins to simulate a lidar sensor and a depth camera on ``sam_bot``. If you are working with a real robot, most of these steps are still required for setting up your URDF frames and it will not hurt to also add in the gazebo plugins for later use. -To be able to follow the rest of this section, make sure that you have properly installed Gazebo. You can follow the instructions at the `Setup and Prerequisites `_ of the previous tutorial to setup Gazebo. +To be able to follow the rest of this section, make sure that you have properly installed Gazebo. You can follow the instructions at the `Setup and Prerequisites `_ of the previous tutorial to setup Gazebo. Adding Gazebo Plugins to a URDF or SDF @@ -160,7 +160,7 @@ In your SDF add the below before the ```` line to add the lidar's link, In the code snippet above we set the sensor values of lidar_link to the simulated lidar's scan and range properties and set ``/scan`` as the topic to which it will publish the ``sensor_msgs/LaserScan`` messages. -Next, let us add a depth camera to ``sam_bot``. In your URDF paste the following lines after the ```` tag of the lidar sensor to just add the camera's link and joint. +Next, let us add a depth camera to ``sam_bot``. In your URDF paste the following lines after the ```` tag of the lidar sensor to just add the camera's link and joint. .. code-block:: xml @@ -315,7 +315,7 @@ Lastly, we can also visualize the sensor readings in RViz. To visualize the ``s :align: center :width: 400 -Next, set the ``Reliability Policy`` in RViz to ``Best Effort`` and set the ``size`` to 0.1 to see the points clearer. You should see the visualized ``LaserScan`` detection as shown below. This corresponds to the detected cube and sphere that we added to the Gazebo world. +Next, set the ``Reliability Policy`` in RViz to ``Best Effort`` and set the ``size`` to 0.1 to see the points clearer. You should see the visualized ``LaserScan`` detection as shown below. This corresponds to the detected cube and sphere that we added to the Gazebo world. .. image:: images/demo_laserscan_rviz.png :align: center @@ -338,4 +338,4 @@ You should also see the ``sensor_msgs/PointCloud2``, as shown below. Conclusion ********** -In this section of our robot setup guide, we had a discussion on the common types of sensor messages in Nav2 which standardize the message formats for different sensor vendors. We also discussed how to add sensors to a simulated robot using Gazebo and how to verify that the sensors are working correctly through RViz. +In this section of our robot setup guide, we had a discussion on the common types of sensor messages in Nav2 which standardize the message formats for different sensor vendors. We also discussed how to add sensors to a simulated robot using Gazebo and how to verify that the sensors are working correctly through RViz. diff --git a/setup_guides/sensors/setup_sensors_gz_classic.rst b/setup_guides/sensors/setup_sensors_gz_classic.rst index 587b2ca634..6877e5a46b 100644 --- a/setup_guides/sensors/setup_sensors_gz_classic.rst +++ b/setup_guides/sensors/setup_sensors_gz_classic.rst @@ -3,13 +3,13 @@ Setting Up Sensors - Gazebo Classic ################################### -In this guide, we will discuss the importance of the sensors in navigating a robot safely and how to set up the sensors with Nav2. In the first half of this tutorial, we will take a brief look at commonly used sensors and common sensor messages in Nav2. Next, we will add a basic sensor setup on our previously built simulated robot, ``sam_bot``. Lastly, we will then verify the simulated sensor messages of ``sam_bot`` by visualizing them in RViz. +In this guide, we will discuss the importance of the sensors in navigating a robot safely and how to set up the sensors with Nav2. In the first half of this tutorial, we will take a brief look at commonly used sensors and common sensor messages in Nav2. Next, we will add a basic sensor setup on our previously built simulated robot, ``sam_bot``. Lastly, we will then verify the simulated sensor messages of ``sam_bot`` by visualizing them in RViz. Once sensors have been set up on a robot, their readings can be used in mapping, localization, and perception tasks. In the second half of this guide, we will first discuss how mapping and localization use the sensor data. Then, we will also take a look at one of Nav2's packages, ``nav2_costmap_2d``, which generates costmaps that will eventually be used in Nav2 path planning. We will set up basic configuration parameters for this package so it properly takes in sensor information from ``sam_bot``. Lastly, we visualize a generated costmaps in RViz to verify its received data. Sensor Introduction ******************* -Mobile robots are equipped with a multitude of sensors that allow them to see and perceive their environment. These sensors obtain information which can be used to build and maintain the map of the environment, to localize the robot on the map, and to see the obstacles in the environment. These tasks are essential to be able to safely and efficiently navigate a robot through a dynamic environment. +Mobile robots are equipped with a multitude of sensors that allow them to see and perceive their environment. These sensors obtain information which can be used to build and maintain the map of the environment, to localize the robot on the map, and to see the obstacles in the environment. These tasks are essential to be able to safely and efficiently navigate a robot through a dynamic environment. Examples of commonly used sensors are lidar, radar, RGB camera, depth camera, IMU, and GPS. To standardize the message formats of these sensors and allow for easier interoperation between vendors, ROS provides the ``sensor_msgs`` package that defines the common sensor interfaces. This also allows users to use any sensor vendor as long as it follows the standard format in ``sensor_msgs``. In the next subsection, we introduce some of commonly used messages in navigation, namely the ``sensor_msgs/LaserScan``, ``sensor_msgs/PointCloud2``, ``sensor_msgs/Range``, and ``sensor_msgs/Image``. @@ -21,7 +21,7 @@ Aside from the ``sensor_msgs`` package, there are also the ``radar_msgs`` and `` Your physical robot's sensors probably have ROS drivers written for them (e.g. a ROS node that connects to the sensors, populates data into messages, and publishes them for your robot to use) that follow the standard interface in the ``sensor_msgs`` package. The ``sensor_msgs`` package makes it easy for you to use many different sensors from different manufacturers. General software packages like Nav2 can then read these standardized messages and perform tasks independent of the sensor hardware. On simulated robots such as ``sam_bot``, Gazebo has sensor plugins which also publish their information following the ``sensor_msgs`` package. Common Sensor Messages -====================== +====================== In this subsection, we discuss some of the common types of ``sensor_msgs`` you might encounter when setting up Nav2. We will provide a brief description for each sensor, an image of it being simulated in Gazebo and the corresponding visualization of the sensor readings in RViz. @@ -57,9 +57,9 @@ This represents the sensor readings from RGB or depth camera, corresponding to R Simulating Sensors using Gazebo Classic *************************************** -To give you a better grasp of how to set up sensors on a simulated robot, we will build up on our previous tutorials and attach sensors to our simulated robot ``sam_bot``. Similar to the previous tutorial where we used Gazebo plugins to add odometry sensors to ``sam_bot``, we will be using the Gazebo plugins to simulate a lidar sensor and a depth camera on ``sam_bot``. If you are working with a real robot, most of these steps are still required for setting up your URDF frames and it will not hurt to also add in the gazebo plugins for later use. +To give you a better grasp of how to set up sensors on a simulated robot, we will build up on our previous tutorials and attach sensors to our simulated robot ``sam_bot``. Similar to the previous tutorial where we used Gazebo plugins to add odometry sensors to ``sam_bot``, we will be using the Gazebo plugins to simulate a lidar sensor and a depth camera on ``sam_bot``. If you are working with a real robot, most of these steps are still required for setting up your URDF frames and it will not hurt to also add in the gazebo plugins for later use. -To be able to follow the rest of this section, make sure that you have properly installed Gazebo. You can follow the instructions at the `Setup and Prerequisites `_ of the previous tutorial to setup Gazebo. +To be able to follow the rest of this section, make sure that you have properly installed Gazebo. You can follow the instructions at the `Setup and Prerequisites `_ of the previous tutorial to setup Gazebo. Adding Gazebo Plugins to a URDF @@ -91,13 +91,13 @@ Let us first add a lidar sensor to ``sam_bot``. Open the URDF file, `src/descrip - + - + true @@ -135,7 +135,7 @@ Let us first add a lidar sensor to ``sam_bot``. Open the URDF file, `src/descrip In the code snippet above, we create a ``lidar_link`` which will be referenced by the ``gazebo_ros_ray_sensor`` plugin as the location to attach our sensor. We also set values to the simulated lidar's scan and range properties. Lastly, we set the ``/scan`` as the topic to which it will publish the ``sensor_msgs/LaserScan`` messages. -Next, let us add a depth camera to ``sam_bot``. Paste the following lines after the ```` tag of the lidar sensor. +Next, let us add a depth camera to ``sam_bot``. Paste the following lines after the ```` tag of the lidar sensor. .. code-block:: xml :lineno-start: 314 @@ -161,7 +161,7 @@ Next, let us add a depth camera to ``sam_bot``. Paste the following lines after - + @@ -218,8 +218,8 @@ Similar to the lidar sensor, we create ``camera_link`` which will be referenced Launch and Build Files ====================== -To verify that the sensors are set up properly and that they can see objects in our environment, let us launch ``sam_bot`` in a Gazebo world with objects. -Let us create a Gazebo world with a single cube and a single sphere that are within the range of ``sam_bot``'s sensors so we can verify if it can see the objects correctly. +To verify that the sensors are set up properly and that they can see objects in our environment, let us launch ``sam_bot`` in a Gazebo world with objects. +Let us create a Gazebo world with a single cube and a single sphere that are within the range of ``sam_bot``'s sensors so we can verify if it can see the objects correctly. To create the world, create a directory named ``world`` at the root of your project and create a file named ``my_world.sdf`` inside the ``world`` folder . Then copy the contents of `world/my_world.sdf `_ and paste them inside ``my_world.sdf``. @@ -271,7 +271,7 @@ Lastly, we can also visualize the sensor readings in RViz. To visualize the ``s :align: center :width: 400 -Next, set the ``Reliability Policy`` in RViz to ``Best Effort`` and set the ``size`` to 0.1 to see the points clearer. You should see the visualized ``LaserScan`` detection as shown below. This corresponds to the detected cube and sphere that we added to the Gazebo world. +Next, set the ``Reliability Policy`` in RViz to ``Best Effort`` and set the ``size`` to 0.1 to see the points clearer. You should see the visualized ``LaserScan`` detection as shown below. This corresponds to the detected cube and sphere that we added to the Gazebo world. .. image:: images/demo_laserscan_rviz.png :align: center @@ -294,4 +294,4 @@ You should also see the ``sensor_msgs/PointCloud2``, as shown below. Conclusion ********** -In this section of our robot setup guide, we had a discussion on the common types of sensor messages in Nav2 which standardize the message formats for different sensor vendors. We also discussed how to add sensors to a simulated robot using Gazebo and how to verify that the sensors are working correctly through RViz. +In this section of our robot setup guide, we had a discussion on the common types of sensor messages in Nav2 which standardize the message formats for different sensor vendors. We also discussed how to add sensors to a simulated robot using Gazebo and how to verify that the sensors are working correctly through RViz. diff --git a/setup_guides/transformation/setup_transforms.rst b/setup_guides/transformation/setup_transforms.rst index 124dd5616a..e97f97ef77 100644 --- a/setup_guides/transformation/setup_transforms.rst +++ b/setup_guides/transformation/setup_transforms.rst @@ -16,14 +16,14 @@ Transforms Introduction .. note:: This section of this guide has been adapted from the `Setting Up You Robot using tf `__ tutorial in the ROS (1) Navigation documentation. -Many ROS packages require the transform tree of a robot to be published using the TF2 ROS package. A transformation tree defines the relations between different coordinate systems, in terms of translation, rotation, and relative motion. To make this more concrete, let us apply an example of a simple robot that has a mobile base with a single laser sensor mounted on top of it. +Many ROS packages require the transform tree of a robot to be published using the TF2 ROS package. A transformation tree defines the relations between different coordinate systems, in terms of translation, rotation, and relative motion. To make this more concrete, let us apply an example of a simple robot that has a mobile base with a single laser sensor mounted on top of it. -This robot has two defined coordinate frames: one corresponding to the center point of the mobile base of the robot, and one for the center point of the laser that is mounted on top of the base. We'll call the coordinate frame attached to the mobile base ``base_link`` and we'll call the coordinate frame attached to the laser ``base_laser``. Note that will be talking more about the naming and conventions of these coordinate frames in the next section. +This robot has two defined coordinate frames: one corresponding to the center point of the mobile base of the robot, and one for the center point of the laser that is mounted on top of the base. We'll call the coordinate frame attached to the mobile base ``base_link`` and we'll call the coordinate frame attached to the laser ``base_laser``. Note that will be talking more about the naming and conventions of these coordinate frames in the next section. -At this point, let's assume that we have some data from the laser in the form of distance measurements from the laser's center point. In other words, we have some data in the ``base_laser`` coordinate frame. +At this point, let's assume that we have some data from the laser in the form of distance measurements from the laser's center point. In other words, we have some data in the ``base_laser`` coordinate frame. Now, suppose we want to take this data and use it to help the mobile base avoid obstacles in the world. To do this successfully, we need a way to transform the laser scan we've received from the ``base_laser`` frame to the ``base_link`` frame. In essence, we need to define a relationship between the ``base_laser`` and ``base_link`` coordinate frames. - + .. image:: images/simple_robot.png :align: center @@ -32,11 +32,11 @@ In defining this relationship, let us assume that the only data we have is that We could choose to manage this relationship ourselves, meaning to store and apply the appropriate translations between the frames when necessary, but this becomes a real pain as the number of coordinate frames increases. Luckily, we don't have to do this work ourselves. Instead, we'll define the relationship between ``base_link`` and ``base_laser`` once using TF2 and let it manage the transformation between the two coordinate frames for us. This is especially useful when working with non-static transformations, such as a set of frames that are moving relative to each other, like a robot base frame in a map frame. To define and store the relationship between the ``base_link`` and ``base_laser`` frames using TF2, we need to add them to a transform tree. Conceptually, each node in the transform tree corresponds to a coordinate frame, and each edge corresponds to the transform that needs to be applied to move from the current node to its child. TF2 uses a tree structure to guarantee that there is only a single traversal that links any two coordinate frames together, and assumes that all edges in the tree are directed from parent to child nodes. - + .. image:: images/tf_robot.png :align: center -To create a transform tree for our simple example, we'll create two nodes: one for the ``base_link`` coordinate frame and one for the ``base_laser`` coordinate frame. To create the edge between them, we first need to decide which node will be the parent and which will be the child. Remember — this distinction is important because TF2 assumes that all transforms move from parent to child. +To create a transform tree for our simple example, we'll create two nodes: one for the ``base_link`` coordinate frame and one for the ``base_laser`` coordinate frame. To create the edge between them, we first need to decide which node will be the parent and which will be the child. Remember — this distinction is important because TF2 assumes that all transforms move from parent to child. Let's choose the ``base_link`` coordinate frame as the parent because when other pieces/sensors are added to the robot, it will make the most sense for them to relate to the ``base_laser`` frame by traversing through the ``base_link`` frame. This means that the transform associated with the edge connecting ``base_link`` and ``base_laser`` should be (x: 0.1m, y: 0.0m, z: 0.2m). @@ -71,7 +71,7 @@ You should be able to observe a repeated output similar to the one below. And that's it for this short demo - we were able to successfully publish a transform from ``base_link`` to ``base_laser`` using the TF2 library. Note that we do not recommend using the above demo in publishing transforms for your actual robotics projects, it is just a quick demo to see TF2 in action. For a real robot system, we would create a URDF file which embeds this information and more about your robot for use of the robot_state_publisher rather than the static_transform_publisher. There are more suitable and practical ways to go about this which will be discussed in the :ref:`urdf_handson` tutorial. -.. seealso:: +.. seealso:: If you would like to learn more about TF2 and how to create your own transform publishers, head onto the official `TF2 Documentation `__ @@ -100,7 +100,7 @@ The first transform ``map`` => ``odom`` is usually provided by a different ROS p The ``odom`` => ``base_link`` is usually published by our odometry system using sensors such as wheel encoders. This is typically computed via sensor fusion of odometry sensors (IMU, wheel encoders, VIO, etc) using the ``robot_localization`` package. -All other statically defined transforms (e.g. ``base_link`` => ``base_laser``, ``base_link`` => ``wheels``, ``wheels`` => ``IMU``, etc) is what we will be talking about for the rest of this guide. This transformation tree is used by Nav2 to properly relate the information from sensors or other frame of interest to the rest of the robot. The transformation between these two coordinate frames is usually provided to Nav2 through the Robot State Publisher and the Universal Robot Descriptor File (URDF). In cases where there are more sensor coordinate frames on your platform, then a transform tree from ``base_link`` to each sensor coordinate frame needs to be published. +All other statically defined transforms (e.g. ``base_link`` => ``base_laser``, ``base_link`` => ``wheels``, ``wheels`` => ``IMU``, etc) is what we will be talking about for the rest of this guide. This transformation tree is used by Nav2 to properly relate the information from sensors or other frame of interest to the rest of the robot. The transformation between these two coordinate frames is usually provided to Nav2 through the Robot State Publisher and the Universal Robot Descriptor File (URDF). In cases where there are more sensor coordinate frames on your platform, then a transform tree from ``base_link`` to each sensor coordinate frame needs to be published. .. seealso:: For a more in-depth discussion on the usage of transforms and how these are used to estimate the current state of your robot, we highly recommend having a look at the State Estimation topic in :ref:`concepts`. @@ -108,8 +108,8 @@ All other statically defined transforms (e.g. ``base_link`` => ``base_laser``, ` Conclusion ********** -In this tutorial, we have discussed about the concept of transforms and how they are used in Nav2. +In this tutorial, we have discussed about the concept of transforms and how they are used in Nav2. In the last section, we have also explored using the static_transform_publisher of TF2 to publish our transforms. You may use this to set up your transforms for Nav2, but this is generally not the best way to do it. In most robotics projects, we make use of the Robot State Publisher since it is much easier to use and scales well as our robot gets more complex. We will be talking about the Robot State Publisher, URDF, and how to set it up in the next tutorial on :ref:`urdf_handson`. -Lastly, we also discussed the three published transform requirements of Nav2 and the necessary REPs to keep in mind when setting them up. +Lastly, we also discussed the three published transform requirements of Nav2 and the necessary REPs to keep in mind when setting them up. diff --git a/setup_guides/urdf/setup_urdf.rst b/setup_guides/urdf/setup_urdf.rst index 23d0207f83..df1992871b 100644 --- a/setup_guides/urdf/setup_urdf.rst +++ b/setup_guides/urdf/setup_urdf.rst @@ -13,16 +13,16 @@ For this guide, we will be creating the Unified Robot Description Format (URDF) URDF and the Robot State Publisher ================================== -As discussed in the previous tutorial, one of the requirements for Navigation2 is the transformation from ``base_link`` to the various sensors and reference frames. This transformation tree can range from a simple tree with only one link from the ``base_link`` to ``laser_link`` or a tree comprised of multiple sensors located in different locations, each having their own coordinate frame. Creating multiple publishers to handle all of these coordinate frame transformations may become tedious. Therefore, we will be making use of the Robot State Publisher package to publish our transforms. +As discussed in the previous tutorial, one of the requirements for Navigation2 is the transformation from ``base_link`` to the various sensors and reference frames. This transformation tree can range from a simple tree with only one link from the ``base_link`` to ``laser_link`` or a tree comprised of multiple sensors located in different locations, each having their own coordinate frame. Creating multiple publishers to handle all of these coordinate frame transformations may become tedious. Therefore, we will be making use of the Robot State Publisher package to publish our transforms. -The Robot State Publisher is a package of ROS 2 that interacts with the tf2 package to publish all of the necessary transforms that can be directly inferred from the geometry and structure of the robot. We need to provide it with the correct URDF and it will automatically handle publishing the transforms. This is very useful for complex transformations but it is still recommended for simpler transform trees. +The Robot State Publisher is a package of ROS 2 that interacts with the tf2 package to publish all of the necessary transforms that can be directly inferred from the geometry and structure of the robot. We need to provide it with the correct URDF and it will automatically handle publishing the transforms. This is very useful for complex transformations but it is still recommended for simpler transform trees. The Unified Robot Description Format (URDF) is an XML file that represents a robot model. In this tutorial, it will mainly be used to build transformations trees related with the robot geometry, but it also has other uses. One example is how it can be used in visualizing your robot model in RVIZ, a 3D Visualization tool for ROS, by defining visual components such as materials and meshes. Another example is how the URDF can be used to define the physical properties of the robot. These properties are then used in physics simulators such as Gazebo to simulate how your robot will interact in an environment. Another major feature of URDF is that it also supports Xacro (XML Macros) to help you create a shorter and readable XML to help in defining complex robots. We can use these macros to eliminate the need for repeating blocks of XML in our URDF. Xacro is also useful in defining configuration constants which can be reused throughout the URDF. .. seealso:: - If you want to learn more about the URDF and the Robot State Publisher, we encourage you to have a look at the official `URDF Documentation `__ and `Robot State Publisher Documentation `__ + If you want to learn more about the URDF and the Robot State Publisher, we encourage you to have a look at the official `URDF Documentation `__ and `Robot State Publisher Documentation `__ Setting Up the Environment ========================== @@ -35,7 +35,7 @@ Let's begin by installing some additional ROS 2 packages that we will be using d sudo apt install ros--joint-state-publisher-gui sudo apt install ros--xacro - + Next, create a directory for your project, initialize a ROS 2 workspace and give your robot a name. For ours, we'll be calling it ``sam_bot``. .. code-block:: shell @@ -56,7 +56,7 @@ Now that we have our project workspace set up, let's dive straight into writing | - To get started, create a file named ``sam_bot_description.urdf`` under ``src/description`` and input the following as the initial contents of the file. + To get started, create a file named ``sam_bot_description.urdf`` under ``src/description`` and input the following as the initial contents of the file. .. code-block:: xml :linenos: @@ -90,7 +90,7 @@ Next, let us define some constants using XAcro properties that will be reused th Here is a brief discussion on what these properties will represent in our urdf. The ``base_*`` properties all define the size of the robot's main chassis. The ``wheel_radius`` and ``wheel_width`` define the shape of the robot's two back wheels. The ``wheel_ygap`` adjusts the gap between the wheel and the chassis along the y-axis whilst ``wheel_zoff`` and ``wheel_xoff`` position the back wheels along the z-axis and x-axis appropriately. Lastly, the ``caster_xoff`` positions the front caster wheel along the x-axis. -Let us then define our ``base_link`` - this link will be a large box and will act as the main chassis of our robot. In URDF, a ``link`` element describes a rigid part or component of our robot. The robot state publisher then utilizes these definitions to determine coordinate frames for each link and publish the transformations between them. +Let us then define our ``base_link`` - this link will be a large box and will act as the main chassis of our robot. In URDF, a ``link`` element describes a rigid part or component of our robot. The robot state publisher then utilizes these definitions to determine coordinate frames for each link and publish the transformations between them. We will also be defining some of the link's visual properties which can be used by tools such as Gazebo and Rviz to show us a 3D model of our robot. Amongst these properties are ```` which describes the link's shape and ```` which describes it's color. @@ -127,9 +127,9 @@ After defining our base_link, we then add a joint to connect it to ``base_link`` -Now, we will be adding two large drive wheels to our robot. To make our code cleaner and avoid repetition, we will make use of macros to define a block of code that will be repeated with differing parameters. Our macro will have 3 params: ``prefix`` which simply adds a prefix to our link and joint names, and ``x_reflect`` and ``y_reflect`` which allows us to flip the positions of our wheels with respect to the x and y axis respectively. Within this macro, we can also define the visual properties of a single wheel. Lastly, we will also define a ``continuous`` joint to allow our wheels to freely rotate about an axis. This joint also connects our wheel to the ``base_link`` at the appropriate location. +Now, we will be adding two large drive wheels to our robot. To make our code cleaner and avoid repetition, we will make use of macros to define a block of code that will be repeated with differing parameters. Our macro will have 3 params: ``prefix`` which simply adds a prefix to our link and joint names, and ``x_reflect`` and ``y_reflect`` which allows us to flip the positions of our wheels with respect to the x and y axis respectively. Within this macro, we can also define the visual properties of a single wheel. Lastly, we will also define a ``continuous`` joint to allow our wheels to freely rotate about an axis. This joint also connects our wheel to the ``base_link`` at the appropriate location. -At the end of this code block, we will be instantiating two wheels using the macro we just made through the ``xacro:wheel`` tags. Note that we also define the parameters to have one wheel on both sides at the back of our robot. +At the end of this code block, we will be instantiating two wheels using the macro we just made through the ``xacro:wheel`` tags. Note that we also define the parameters to have one wheel on both sides at the back of our robot. .. code-block:: xml :lineno-start: 38 @@ -199,7 +199,7 @@ Let's start this section by adding some dependencies that will be required once rviz xacro -Next, let us create our launch file. Launch files are used by ROS 2 to bring up the necessary nodes for our package. From the root of the project, create a directory named ``launch`` and a ``display.launch.py`` file within it. The launch file below launches a robot publisher node in ROS 2 that uses our URDF to publish the transforms for our robot. In addition, the launch file also automatically launches RVIZ so we can visualize our robot as defined by the URDF. Copy and paste the snippet below into your ``display.launch.py`` file. +Next, let us create our launch file. Launch files are used by ROS 2 to bring up the necessary nodes for our package. From the root of the project, create a directory named ``launch`` and a ``display.launch.py`` file within it. The launch file below launches a robot publisher node in ROS 2 that uses our URDF to publish the transforms for our robot. In addition, the launch file also automatically launches RVIZ so we can visualize our robot as defined by the URDF. Copy and paste the snippet below into your ``display.launch.py`` file. .. code-block:: python @@ -350,11 +350,11 @@ ROS 2 should now launch a robot publisher node and start up RVIZ using our URDF. Visualization using RVIZ ======================== -RVIZ is a robot visualization tool that allows us to see a 3D model of our robot using its URDF. Upon a successful launch using the commands in the previous section, RVIZ should now be visible on your screen and should look like the image below. You may need to move around and manipulate the view to get a good look at your robot. +RVIZ is a robot visualization tool that allows us to see a 3D model of our robot using its URDF. Upon a successful launch using the commands in the previous section, RVIZ should now be visible on your screen and should look like the image below. You may need to move around and manipulate the view to get a good look at your robot. .. image:: images/base-bot_3.png -As you can see, we have successfully created a simple differential drive robot and visualized it in RVIz. It is not necessary to visualize your robot in RVIz, but it's a good step in order to see if you have properly defined your URDF. This helps you ensure that the robot state publisher is publishing the correct transformations. +As you can see, we have successfully created a simple differential drive robot and visualized it in RVIz. It is not necessary to visualize your robot in RVIz, but it's a good step in order to see if you have properly defined your URDF. This helps you ensure that the robot state publisher is publishing the correct transformations. You may have noticed that another window was launched - this is a GUI for the joint state publisher. The joint state publisher is another ROS 2 package which publishes the state for our non-fixed joints. You can manipulate this publisher through the small GUI and the new pose of the joints will be reflected in RVIz. Sliding the bars for any of the two wheels will rotate these joints. You can see this in action by viewing RVIZ as you sweep the sliders in the Joint State Publisher GUI. @@ -387,7 +387,7 @@ Let us first define macros containing the inertial properties of the geometric p - + diff --git a/tuning/index.rst b/tuning/index.rst index 80375f3d7f..854a5b3b55 100644 --- a/tuning/index.rst +++ b/tuning/index.rst @@ -41,9 +41,9 @@ Using the :ref:`configuring_rotation_shim`, a robot will simply rotate in place This was added due to quirks in some existing controllers whereas tuning the controller for a task can make it rigid -- or the algorithm simply doesn't rotate in place when working with holonomic paths (if that's a desirable trait). The result is an awkward, stuttering, or whipping around behavior when your robot's initial and path heading's are significantly divergent. Giving a controller a better starting point to start tracking a path makes tuning the controllers significantly easier and creates more intuitive results for on-lookers (in one maintainer's opinion). -Note: If using a non-holonomic, kinematically feasible planner (e.g. Smac Hybrid-A\*, Smac State Lattice), this is not a necessary behavioral optimization. This class of planner will create plans that take into account the robot's starting heading, not requiring any rotation behaviors. +Note: If using a non-holonomic, kinematically feasible planner (e.g. Smac Hybrid-A\*, Smac State Lattice), this is not a necessary behavioral optimization. This class of planner will create plans that take into account the robot's starting heading, not requiring any rotation behaviors. -This behavior is most optimally for: +This behavior is most optimally for: - Robots that can rotate in place, such as differential and omnidirectional robots. - Preference to rotate in place when starting to track a new path that is at a significantly different heading than the robot’s current heading – or when tuning your controller for its task makes tight rotations difficult. @@ -58,7 +58,7 @@ In general though, the following table is a good guide for the optimal planning +------------------------+----------------------------------------------------------------------+ | Plugin Name | Supported Robot Types | +========================+======================================================================+ -| NavFn Planner | Circular Differential, Circular Omnidirectional | +| NavFn Planner | Circular Differential, Circular Omnidirectional | +------------------------+ | | Smac Planner 2D | | +------------------------+ | @@ -101,9 +101,9 @@ All of the above controllers can handle both circular and arbitrary shaped robot Regulated Pure Pursuit is good for exact path following and is typically paired with one of the kinematically feasible planners (eg State Lattice, Hybrid-A\*, etc) since those paths are known to be drivable given hard physical constraints. However, it can also be applied to differential drive robots who can easily pivot to match any holonomic path. This is the plugin of choice if you simply want your robot to follow the path, rather exactly, without any dynamic obstacle avoidance or deviation. It is simple and geometric, as well as slowing the robot in the presence of near-by obstacles *and* while making sharp turns. -DWB and MPPI are both options that will track paths, but also diverge from the path if there are dynamic obstacles present (in order to avoid them). DWB does this through scoring multiple trajectories on a set of critics. These trajectories are also generated via plugins that can be replaced, but support out of the box Omni and Diff robot types within the valid velocity and acceleration restrictions. These critics are plugins that can be selected at run-time and contain weights that may be tuned to create the desired behavior, such as minimizing path distance, minimizing distance to the goal or headings, and other action penalties that can be designed. This does require a bit of tuning for a given platform, application, and desired behavior, but it is possible to tune DWB to do nearly any single thing well. +DWB and MPPI are both options that will track paths, but also diverge from the path if there are dynamic obstacles present (in order to avoid them). DWB does this through scoring multiple trajectories on a set of critics. These trajectories are also generated via plugins that can be replaced, but support out of the box Omni and Diff robot types within the valid velocity and acceleration restrictions. These critics are plugins that can be selected at run-time and contain weights that may be tuned to create the desired behavior, such as minimizing path distance, minimizing distance to the goal or headings, and other action penalties that can be designed. This does require a bit of tuning for a given platform, application, and desired behavior, but it is possible to tune DWB to do nearly any single thing well. -MPPI on the other hand implements an optimization based approach, using randomly perturbed samples of the previous optimal trajectory to maximize a set of plugin-based objective functions. In that regard, it is similar to DWB however MPPI is a far more modern and advanced technique that will deal with dynamic agents in the environment and create intelligent behavior due to the optimization based trajectory planning, rather then DWB's constant action model. MPPI however does have moderately higher compute costs, but it is highly recommended to go this route and has received considerable development resources and attention due to its power. This typically works pretty well out of the box, but to tune for specific behaviors, you may have to retune some of the parameters. The README.md file for this package contains details on how to tune it efficiently. +MPPI on the other hand implements an optimization based approach, using randomly perturbed samples of the previous optimal trajectory to maximize a set of plugin-based objective functions. In that regard, it is similar to DWB however MPPI is a far more modern and advanced technique that will deal with dynamic agents in the environment and create intelligent behavior due to the optimization based trajectory planning, rather then DWB's constant action model. MPPI however does have moderately higher compute costs, but it is highly recommended to go this route and has received considerable development resources and attention due to its power. This typically works pretty well out of the box, but to tune for specific behaviors, you may have to retune some of the parameters. The README.md file for this package contains details on how to tune it efficiently. The Rotation Shim Plugin helps assist plugins like TEB and DWB (among others) to rotate the robot in place towards a new path's heading before starting to track the path. This allows you to tune your local trajectory planner to operate with a desired behavior without having to worry about being able to rotate on a dime with a significant deviation in angular distance over a very small euclidean distance. Some controllers when heavily tuned for accurate path tracking are constrained in their actions and don't very cleanly rotate to a new heading. Other controllers have a 'spiral out' behavior because their sampling requires some translational velocity, preventing it from simply rotating in place. This helps alleviate that problem and makes the robot rotate in place very smoothly. @@ -119,12 +119,12 @@ Smac's Hybrid-A* and State Lattice Planners provide an option, ``cache_obstacle_ This is useful to speed up performance to achieve better replanning speeds. However, if you cache this heuristic, it will not be updated with the most current information in the costmap to steer search. During planning, the planner will still make use of the newest cost information for collision checking, *thusly this will not impact the safety of the path*. However, it may steer the search down newly blocked corridors or guide search towards areas that may have new dynamic obstacles in them, which can slow things down significantly if entire solution spaces are blocked. -Therefore, it is the recommendation of the maintainers to enable this only when working in largely static (e.g. not many moving things or changes, not using live sensor updates in the global costmap, etc) environments when planning across large spaces to singular goals. Between goal changes to Nav2, this heuristic will be updated with the most current set of information, so it is not very helpful if you change goals very frequently. +Therefore, it is the recommendation of the maintainers to enable this only when working in largely static (e.g. not many moving things or changes, not using live sensor updates in the global costmap, etc) environments when planning across large spaces to singular goals. Between goal changes to Nav2, this heuristic will be updated with the most current set of information, so it is not very helpful if you change goals very frequently. Costmap2D Plugins ================= -Costmap2D has a number of plugins that you can use (including the availability for you to create your own!). +Costmap2D has a number of plugins that you can use (including the availability for you to create your own!). - ``StaticLayer``: Used to set the map from SLAM (either pre-built or currently being built live) for sizing the environment and setting key features like walls and rooms for global planning. - ``InflationLayer``: Inflates with an exponential function the lethal costs to help steer navigation algorithms away from walls and quickly detect collisions @@ -133,7 +133,7 @@ Costmap2D has a number of plugins that you can use (including the availability f - ``SpatioTemporalVoxelLayer``: 3D costmap layer for 3D lidars, non-planar 2D lidars, or depth camera processing based on temporal decay. Useful for robots with high sensor coverage like 3D lidars or many depth cameras at a reduced computational overhead due to lack of raycasting. - ``RangeLayer``: Models sonars, IR sensors, or other range sensors for costmap inclusion - ``DenoiseLayer``: Removes salt and pepper noise from final costmap in order to remove unfiltered noise. Also has the option to remove clusters of configurable size to remove effects of dynamic obstacles without temporal decay. -- ``PluginContainerLayer``: Combines the costmap layers specified within this plugin, resulting in an internal costmap that is a product of the costmap layers specified under this layer. This would allow different isolated combinations of costmap layers within the same parent costmap, such as applying a different inflation layers to static layers and obstacle layers +- ``PluginContainerLayer``: Combines the costmap layers specified within this plugin, resulting in an internal costmap that is a product of the costmap layers specified under this layer. This would allow different isolated combinations of costmap layers within the same parent costmap, such as applying a different inflation layers to static layers and obstacle layers In addition, costmap filters: - ``KeepoutFilter``: Marks keepout, higher weighted, or lower weighted zones in the costmap @@ -166,7 +166,7 @@ Within ``nav2_bringup``, there is a main entryfile ``tb3_simulation_launch.py``. - ``namespace`` : The namespace to launch robots into. - ``robot_name`` : The name of the robot to launch. - ``robot_sdf`` : The filepath to the robot's gazebo configuration file containing the Gazebo plugins and setup to simulate the robot system. -- ``x_pose``, ``y_pose``, ``z_pose``, ``roll``, ``pitch``, ``yaw`` : Parameters to set the initial position of the robot in the simulation. +- ``x_pose``, ``y_pose``, ``z_pose``, ``roll``, ``pitch``, ``yaw`` : Parameters to set the initial position of the robot in the simulation. Other Pages We'd Love To Offer ============================== diff --git a/tutorials/docs/camera_calibration.rst b/tutorials/docs/camera_calibration.rst index 6599f571ed..d8b56716c4 100644 --- a/tutorials/docs/camera_calibration.rst +++ b/tutorials/docs/camera_calibration.rst @@ -184,9 +184,3 @@ Tutorial Steps ``tar -xvf calibration.tar.gz`` 11-In the folder images used for calibration are available and also “**ost.yaml**” and “**ost.txt**”. You can use the yaml file which contains the calibration parameters as directed by the camera driver. - - - - - - diff --git a/tutorials/docs/docker_dev.rst b/tutorials/docs/docker_dev.rst index b158ed97a5..01eb9f0cc8 100644 --- a/tutorials/docs/docker_dev.rst +++ b/tutorials/docs/docker_dev.rst @@ -18,7 +18,7 @@ Overview This tutorial is a hands on walkthrough from your first Docker usage to commands and processes you can use for development of ROS 2 applications using Docker. This is not an exhaustive introduction by any stretch, but should help you go from nothing to a functional process you can use on a daily basis for development and testing. -If you know some basics about Docker already, you can skip to later sections about development and deployment. +If you know some basics about Docker already, you can skip to later sections about development and deployment. You'll also find a set of Docker images in the Appendix to this tutorial which are useful for developing with Nav2 or a containerized deployment of it. The same process template can be used for other company applications and projects as well. @@ -38,7 +38,7 @@ It gives you a controlled environment to work in that is reproducible on other d For example, you can run a 22.04 Docker container that contains ROS 2 Humble on Nvidia Jetson's Jetpack 5.1 (which is a flavor of 20.04) and deploy that container to a fleet of robots. In common Docker language, an *image* is the built ``Dockerfile`` which can be used to create *containers*. -Thus, *containers* are self-contained, runnable instances of the docker *image*. +Thus, *containers* are self-contained, runnable instances of the docker *image*. The ``Dockerfile`` is a set of instructions for how to build an image to create some kind of environment to work in - and often contain applications to deploy in that environment. The Dockerfile instruct sets have a number of options such as: @@ -63,14 +63,14 @@ But these can be used to do more advanced things like run your application or tr Important Docker Commands ========================= -Similarly unexhaustively, it is important to discuss a few docker commandline commands before we move forward. +Similarly unexhaustively, it is important to discuss a few docker commandline commands before we move forward. There are many others, but these are the basic commands which we will use in this walkthrough and likely the most common you'll use on the day-to-day. Over the tutorial, build up some important option flags for each, but for now lets talk about the basics: - ``docker run``: Runs a given docker image to create a container - ``docker build``: Builds a Dockerfile to create an image - ``docker pull / push``: Pulls a docker image from another location or pushes a built image to another location -- ``docker stop / kill``: Stops or kills a running docker container +- ``docker stop / kill``: Stops or kills a running docker container - ``docker ps``: Lists a set of docker images that are currently running - ``docker attach``: Attach a terminal to a background running docker container - ``docker exec``: Execute a command in a provided container @@ -80,7 +80,7 @@ Exploring Your First Container ============================== Lets start this tutorial with getting the latest-and-greatest of ROS 2 Rolling. -Using the OSRF DockerHub server, we can pull down a number of different ROS 2 docker images to work with without having to create a Dockerfile or build them ourselves. +Using the OSRF DockerHub server, we can pull down a number of different ROS 2 docker images to work with without having to create a Dockerfile or build them ourselves. .. code-block:: bash @@ -92,19 +92,19 @@ You should then see the following, where the image is being pulled down in multi steve@reese:~$ sudo docker pull osrf/ros:rolling-desktop-full rolling-desktop-full: Pulling from osrf/ros - 31bd5f451a84: Already exists - d36cae3fb404: Already exists - 8d68f36a56a7: Already exists - 299f725c4bf1: Already exists - 6e16227afc48: Already exists + 31bd5f451a84: Already exists + d36cae3fb404: Already exists + 8d68f36a56a7: Already exists + 299f725c4bf1: Already exists + 6e16227afc48: Already exists 02457a85146c: Downloading 83.7MB/106.5MB - fe0cbdee2808: Download complete + fe0cbdee2808: Download complete 4b4dbddf506a: Downloading 92.86MB/98.14MB - 0da90b52c355: Download complete - 64de492566b2: Download complete - 167d95ac0fce: Download complete + 0da90b52c355: Download complete + 64de492566b2: Download complete + 167d95ac0fce: Download complete e727072615d0: Downloading 82.61MB/809.8MB - d15e176ed0af: Waiting + d15e176ed0af: Waiting If you then attempt to run this image as a container (the instance of the image): @@ -112,7 +112,7 @@ If you then attempt to run this image as a container (the instance of the image) sudo docker run osrf/ros:rolling-desktop-full -You should see that it runs for a second then exits the terminal. Yay! It works! But... that's not very useful, now is it? +You should see that it runs for a second then exits the terminal. Yay! It works! But... that's not very useful, now is it? Our ``ENTRYPOINT`` for the ROS 2 Docker images only sources the ROS 2 installation and so the program returns as completed. If we want to get into the container to do something useful for ourselves in that environment, we need to open an interactive terminal session with the container. This is easy to do with the ``-it`` flags: @@ -122,7 +122,7 @@ This is easy to do with the ``-it`` flags: sudo docker run -it osrf/ros:rolling-desktop-full You should now see a terminal session open with a command prompt of ``root@:/#``. -This is your docker container. +This is your docker container. Take a look around, it should look like any other linux OS. If you go into ``/opt/ros/rolling``, it should look familiar to you! @@ -159,8 +159,8 @@ You can see that our container exited successfully. If we now run our docker ima While we're here, lets ``ls`` our container. Oh no! Our ``navigator_dockerlayer.txt`` file is missing! That's completely to be expected. When we exit the container, that instance of the image is destroyed - never again to be seen. When we run the image again, we're generating a brand new, clean instance of the image. -Nothing persists. This is an important behavior to understand moving forward. -For development, this is nightmare fuel of losing a day's work by hitting the wrong button. +Nothing persists. This is an important behavior to understand moving forward. +For development, this is nightmare fuel of losing a day's work by hitting the wrong button. For deployment, this is a blessing as you can cleanly restart with no artifacts from a previously failed session and start with a clean slate. We'll discuss how to persist data between sessions later on in the tutorial, so fear not! @@ -199,7 +199,7 @@ If you now open a third terminal to your computer and run ``ros2 topic list``, y .. code-block:: bash - steve@reese:~$ ros2 topic list + steve@reese:~$ ros2 topic list /parameter_events /rosout @@ -266,7 +266,7 @@ Understanding ROS Docker Images Now that we know a bit about Docker's basic features and explored the Rolling Desktop Full container, lets look at the Docker images you have to work with in ROS in more detail. OSRF hosts a DockerHub server containing images of all ROS distributions which you can pull and use. -For each distribution, there are a couple of variants: +For each distribution, there are a couple of variants: - ``ros-core``: Contains only the ROS core communication protocols and utilities - ``ros-base``: Contains ``ros-core`` and other core utilities like pluginlib, bond, actions, etc @@ -320,7 +320,7 @@ If you go to your workspace in another terminal, you should now see that file re rosdep install -r -y --from-paths . --ignore-src colcon build -Now, you can make any changes to your code using VSCode or your favorite code editor and have it reflected in the container for building and testing! +Now, you can make any changes to your code using VSCode or your favorite code editor and have it reflected in the container for building and testing! This is especially powerful if you're working with multiple ROS distributions or with a ROS distribution which your host OS doesn't natively support (such as Humble on Jetpack 5.1 on Nvidia Jetsons). However, it does get annoying over time to have to wait for all of your dependencies to install manually when you spin up a new container. Thus, it is useful to build atop one of the provided ROS Docker images to create your own custom development image containing the packages and environment you need to build your application. @@ -344,7 +344,7 @@ You can build this image using ``docker build`` Where ``-t`` sets the tagged name of the container for later use. Its important to note that even though your install and build spaces will be reflected in your host workspace, they cannot be run locally when compiled inside of a docker container. This example development image also upgrades packages which breaks strict version controlling of system and ``ros-base`` installed packages. -For a deployment situation, you want to ensure you have the same version of all packages -- however for ROS 2 Rolling where ABI and API are not promised to be stable due to live development, +For a deployment situation, you want to ensure you have the same version of all packages -- however for ROS 2 Rolling where ABI and API are not promised to be stable due to live development, it is useful to upgrade so that your source code can build against the latest and greatest. Visualizations from Docker @@ -393,7 +393,7 @@ At the end of this, you should be able to now: - Pull the official ROS 2 docker images of any ROS distribution and choose the right type of image for your needs - Understand how ROS 2 docker containers are formatted and the core part of ``Dockerfile`` image descriptions - Understand Docker's filesystem and network isolation -- and how to bypass it for important use-cases in development -- Be able to detach your docker containers for long-running processes +- Be able to detach your docker containers for long-running processes - Mount your development workspace to the container to work in - Build your own docker image off of ROS' for your development dependencies and setup needs - Visualization and simulation with GUI in docker @@ -402,7 +402,7 @@ Its useful to note at this point that the ``--privileged`` flag is a real hammer Also note that ``--privileged`` also makes it easier to run hardware interfaces like joysticks and sensors by enabling inputs from the host operating system that are processing those inputs. If in production, you cannot use a hammer, you may need to dig into your system a bit to allow through only the interfaces required for your hardware. -As for potential steps forward: +As for potential steps forward: - Setup a config file to hide all those docker run arguments for development - Setup a bash script to enable several different configurations of docker run and execute the run itself @@ -411,7 +411,7 @@ As for potential steps forward: - `Configure computer `_ to avoid use of ``sudo`` for each docker CLI command. - Consider production considerations like build cache management, security, multi-stage builds, and such to get the most out of Docker -We hope that's enough to get you started! +We hope that's enough to get you started! -- Your Friendly Neighborhood Navigators @@ -433,8 +433,8 @@ Instead, it pulls the dependencies so that when you run this container, you obta && DEBIAN_FRONTEND=noninteractive apt install -y --no-install-recommends --no-install-suggests \ ros-dev-tools \ wget - - WORKDIR /root/nav2_ws + + WORKDIR /root/nav2_ws RUN mkdir -p ~/nav2_ws/src RUN git clone https://github.com/ros-navigation/navigation2.git --branch main ./src/navigation2 RUN rosdep init @@ -446,7 +446,7 @@ Nav2 Deployment Image --------------------- This image either downloads and installs Nav2 (Rolling; from source) or installs it (from binaries) to have a self contained image of everything you need to run Nav2. -From here, you can go to the :ref:`getting_started` to test it out! +From here, you can go to the :ref:`getting_started` to test it out! .. code-block:: bash @@ -459,7 +459,7 @@ From here, you can go to the :ref:`getting_started` to test it out! wget # For Rolling or want to build from source a particular branch / fork - WORKDIR /root/nav2_ws + WORKDIR /root/nav2_ws RUN mkdir -p ~/nav2_ws/src RUN git clone https://github.com/ros-navigation/navigation2.git --branch main ./src/navigation2 RUN rosdep init diff --git a/tutorials/docs/filtering_of_noise-induced_obstacles.rst b/tutorials/docs/filtering_of_noise-induced_obstacles.rst index 5f17ddbb65..d436fd9814 100644 --- a/tutorials/docs/filtering_of_noise-induced_obstacles.rst +++ b/tutorials/docs/filtering_of_noise-induced_obstacles.rst @@ -129,4 +129,3 @@ Obstacles marked at the end of the animation will be removed (groups that size l .. image:: images/Filtering_of_noise-induced_obstacles/connected_components.gif :width: 600px - diff --git a/tutorials/docs/get_backtrace.rst b/tutorials/docs/get_backtrace.rst index 55c2fcedb9..e606edcbaa 100644 --- a/tutorials/docs/get_backtrace.rst +++ b/tutorials/docs/get_backtrace.rst @@ -105,7 +105,7 @@ For example: #6 0x00007ffff7c553eb in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 #7 0x000055555555936c in std::vector >::_M_range_check ( this=0x5555555cfdb0, __n=100) at /usr/include/c++/9/bits/stl_vector.h:1070 - #8 0x0000555555558e1d in std::vector >::at (this=0x5555555cfdb0, + #8 0x0000555555558e1d in std::vector >::at (this=0x5555555cfdb0, __n=100) at /usr/include/c++/9/bits/stl_vector.h:1091 #9 0x000055555555828b in GDBTester::VectorCrash (this=0x5555555cfb40) at /home/steve/Documents/nav2_ws/src/gdb_test_pkg/src/gdb_test_node.cpp:44 @@ -224,14 +224,14 @@ From Nav2 Bringup To debug directly from the nav2 bringup launch files you may want to do the following: -- Add ``prefix=['xterm -e gdb -ex run --args']`` to the non-composed node in the appropriate launch file. +- Add ``prefix=['xterm -e gdb -ex run --args']`` to the non-composed node in the appropriate launch file. - Recompile the package of interest with ``-g`` flag for debug symbols. - Launch normally with ``ros2 launch nav2_bringup tb3_simulation_launch.py use_composition:=False``. A separate xterm window will open with the process of interest running in gdb. .. note:: - Turning off composition has serious performance impacts. If this is important to you please follow "From Large Project". + Turning off composition has serious performance impacts. If this is important to you please follow "From Large Project". Once your server crashes, you'll see a prompt like below in the xterm window. At this point you can now get a backtrace. diff --git a/tutorials/docs/get_profile.rst b/tutorials/docs/get_profile.rst index b664f791cd..6ca058c333 100644 --- a/tutorials/docs/get_profile.rst +++ b/tutorials/docs/get_profile.rst @@ -1,4 +1,4 @@ -.. _get_profile: +.. _get_profile: Profiling in ROS 2 / Nav2 ************************* @@ -25,7 +25,7 @@ This tutorial makes use of two tools, callgrind from the ``Valgrind`` set of too Thus, we must install them. .. code-block:: bash - + sudo apt install valgrind kcachegrind More information can be found in the `Valgrind manual `_ including additional valgrind arguments that can be used to specify more information. @@ -56,7 +56,7 @@ As in our generic example, for a given node, we need to compile with debug flags colcon build --packages-select --cmake-args -DCMAKE_BUILD_TYPE=RelWithDebInfo -Optionally, you may add the following line to the ``CMakeLists.txt`` of the package you're looking to profile. This may be preferable when you have a workspace with many packages but would like to only compile a subset with debug information using a single ``colcon build`` invocation. +Optionally, you may add the following line to the ``CMakeLists.txt`` of the package you're looking to profile. This may be preferable when you have a workspace with many packages but would like to only compile a subset with debug information using a single ``colcon build`` invocation. It is important that this should be added to both the host server and plugin packages(s) if you would like the results of a plugin's run-time profile. @@ -131,7 +131,7 @@ This should open a window looking like below. The left side shows all of the cal :height: 450px :width: 600px :align: center - + If you select the top level entry on the left sidebar, then select "Call Graph" at the bottom of the right workspace, it should show you a call graph of where the compute time was spent as a graph of method calls. This can be exceptionally helpful to find the methods where the most time is spent. .. image:: images/call_graph.png diff --git a/tutorials/docs/integrating_vio.rst b/tutorials/docs/integrating_vio.rst index 49c082c110..86ae974598 100644 --- a/tutorials/docs/integrating_vio.rst +++ b/tutorials/docs/integrating_vio.rst @@ -4,7 +4,7 @@ Using VIO to Augment Robot Odometry *********************************** -- `Overview`_ +- `Overview`_ - `Setting Up the ZED X Camera`_ - `Setting Up ZED ROS`_ - `Fusing VIO Into Local State Estimate`_ @@ -13,15 +13,15 @@ Using VIO to Augment Robot Odometry Overview ======== -This tutorial highlights how to setup Visual-Inerial Odometry (VIO) into a Nav2 and ROS 2 based robotics system to augment robot odometry. +This tutorial highlights how to setup Visual-Inerial Odometry (VIO) into a Nav2 and ROS 2 based robotics system to augment robot odometry. Many modern robotics platforms have unideal configurations for high quality wheel odometry. For example, skid-steer, tracked, omnidirectional robots using mecanum wheels, and legged robots are notorious for producing suboptimal odometry. These types of platforms are becoming increasingly common in the robotics landscape and require augmentations or replacement sources of odometry. Further, some applications of robotics technologies involve retrofitting existing equipment which may not have odometry altogether. A subfield of computer vision and robotics focuses on how to use Visual (e.g. camera) and Inertial (e.g. IMU) data in order to compute high-speed relative motion independent of robot mechanics. This is an especially useful technology for UAVs without accurate intrinsic odometric sensing capabilities -- or mobile robots with poor interinsic odometry measurements. -Thus, this tutorial walks through the integration of VIO into a robot system to replace or augment wheel odometry so that your robot can autonomously navigate with quality state estimation required for a well-engineered system that is able to accurately and predictably complete its tasks. +Thus, this tutorial walks through the integration of VIO into a robot system to replace or augment wheel odometry so that your robot can autonomously navigate with quality state estimation required for a well-engineered system that is able to accurately and predictably complete its tasks. -Throughout this tutorial, we will be using the `Stereolabs `_ SDK's `Position Tracking `_ capability as our VIO solution of choice paired with the new `ZED X `_ camera. This VIO solution is easy to use and provides production-quality performance for *free* when using a ZED camera module. +Throughout this tutorial, we will be using the `Stereolabs `_ SDK's `Position Tracking `_ capability as our VIO solution of choice paired with the new `ZED X `_ camera. This VIO solution is easy to use and provides production-quality performance for *free* when using a ZED camera module. .. raw:: html @@ -33,7 +33,7 @@ Throughout this tutorial, we will be using the `Stereolabs `_ or `ZED X Getting Started page `_ to install the SDK, ZED X drivers, and ROS 2 drivers needed to proceed. -At this point, you should be able to run one of the following commands to launch the driver and visualize the sensor data in Rviz. Note that these are ROS 2 component nodes that also may be loaded into your system's component manager to minimize latency due to serialization. +At this point, you should be able to run one of the following commands to launch the driver and visualize the sensor data in Rviz. Note that these are ROS 2 component nodes that also may be loaded into your system's component manager to minimize latency due to serialization. .. code-block:: bash @@ -65,7 +65,7 @@ At this point, you should be able to run one of the following commands to launch .. image:: images/vio.png :width: 1000px -As of September 2023, the driver out of the box produces the full ``map->odom->base_link->camera`` tree on its own. This is since the Pose SDK can produce not only VIO, but loop-closure VSLAM representing the full state estimation TF tree. +As of September 2023, the driver out of the box produces the full ``map->odom->base_link->camera`` tree on its own. This is since the Pose SDK can produce not only VIO, but loop-closure VSLAM representing the full state estimation TF tree. We want to be able to fuse in other information such as an external IMU, wheel odometry, GPS, or other sensors into our local or global state estimates, so we need to disable TF publication of ``map->odom`` and ``odom->base_link`` to be provided by our fused outputs. Especially considering the ZED X camera knows nothing about the nature of the ``base_link`` frame. However, if you would like to use the ZED's state estimate for your entire system without further sensor fusion, you certainly can! @@ -94,7 +94,7 @@ Thus, make the following parameter updates to the ``zed_wrapper``'s default para pos_tracking: publish_tf: false # Disables odom -> base_link TF transformation - publish_map_tf: true # Disables map -> odom TF transformation + publish_map_tf: true # Disables map -> odom TF transformation area_memory: false # Disables loop closure computation, but Pose topic for global VSLAM still published (but now pure VIO) # Optional optimizations @@ -115,11 +115,11 @@ Optionally, remap the zed ``odom`` topic to a topic that isn't reserved or commo Fusing VIO Into Local State Estimate ==================================== -Now that we have the ZED ROS 2 drivers set up to publish our VIO to a topic and leave our TF tree to the fusion algorithm and Robot State Publisher (e.g. URDF), we're finally ready to fuse in VIO into our broader state estimate using the ``robot_localization`` package. +Now that we have the ZED ROS 2 drivers set up to publish our VIO to a topic and leave our TF tree to the fusion algorithm and Robot State Publisher (e.g. URDF), we're finally ready to fuse in VIO into our broader state estimate using the ``robot_localization`` package. -This package is a generalized EKF and UKF solution to state estimation of potentially many different topics, publishing at different rates, of different types. If you're unfamiliar with ``robot_localization`` checkout our :ref:`setup_guides`'s Odometry page for basic information and the `package's extensive documentation `_. +This package is a generalized EKF and UKF solution to state estimation of potentially many different topics, publishing at different rates, of different types. If you're unfamiliar with ``robot_localization`` checkout our :ref:`setup_guides`'s Odometry page for basic information and the `package's extensive documentation `_. -Most users at this point already have a ``robot_localization`` configuration file in their robot systems to fuse existing sensors together, such as wheel odometry (even poor) and robot IMUs. We'll be adding a new odom field, ``odom1``, to our configuration to fuse in VIO's position and orientation into our filter. If this is your first odometry field, use ``odom0`` and you can base your file on `ekf.yaml `_. +Most users at this point already have a ``robot_localization`` configuration file in their robot systems to fuse existing sensors together, such as wheel odometry (even poor) and robot IMUs. We'll be adding a new odom field, ``odom1``, to our configuration to fuse in VIO's position and orientation into our filter. If this is your first odometry field, use ``odom0`` and you can base your file on `ekf.yaml `_. .. code-block:: yaml @@ -134,9 +134,9 @@ Most users at this point already have a ``robot_localization`` configuration fil odom1_queue_size: 2 .. note:: - We're fusing in Roll, Pitch, and Yaw. If operating your EKF or ZED in 2D modes, then set the Roll and Pitch fields to ``false``. If you believe jumps in your VIO may occur, consider using ``odom1_pose_rejection_threshold`` which sets a threshold to reject updates if sufficiently outlandish relative to recent updates. In this case, setting differential to true may also be helpful so that single bogus updates don't move the entire coordinate system. + We're fusing in Roll, Pitch, and Yaw. If operating your EKF or ZED in 2D modes, then set the Roll and Pitch fields to ``false``. If you believe jumps in your VIO may occur, consider using ``odom1_pose_rejection_threshold`` which sets a threshold to reject updates if sufficiently outlandish relative to recent updates. In this case, setting differential to true may also be helpful so that single bogus updates don't move the entire coordinate system. -Make sure to evaluate your EKF's ``frequency``, ``two_d_mode``, ``publish_tf``, and key frames to be appropriate for your application. We generally want to publish TF and have 2D mode on when navigating in flat indoor environments only. +Make sure to evaluate your EKF's ``frequency``, ``two_d_mode``, ``publish_tf``, and key frames to be appropriate for your application. We generally want to publish TF and have 2D mode on when navigating in flat indoor environments only. Fusing VSLAM Into Global State Estimate @@ -146,21 +146,21 @@ While out of the scope of this tutorial, it is possible to continue to produce V - Continue to disable the TF tree for ``map->odom``, but the global pose topic will continue to publish under ``pose`` for fusion -- Fuse that topic into a global localization EKF in ``world_frame: map`` along with other sources of information (e.g. external IMU, AMCL, GPS, etc). +- Fuse that topic into a global localization EKF in ``world_frame: map`` along with other sources of information (e.g. external IMU, AMCL, GPS, etc). -- The fusion of multiple global localization techniques should be done carefully. The most trusted source should be set ``_differential: false`` to use the actual pose information. All other subsequent systems should use ``_differential: true`` so that diverging coordinate systems do not create bouncing solutions. Instead, this will fuse one as absolute poses and the other as the changes of poses between iterations. +- The fusion of multiple global localization techniques should be done carefully. The most trusted source should be set ``_differential: false`` to use the actual pose information. All other subsequent systems should use ``_differential: true`` so that diverging coordinate systems do not create bouncing solutions. Instead, this will fuse one as absolute poses and the other as the changes of poses between iterations. Testing it Out! =============== -In the below example, we're fusing the Stereolabs SDK's Pose Tracking VIO solution with a robot's external IMU and odometry (e.g. ``robot_localization`` has ``odom0`` ``odom1`` and ``imu0``) to improve performance while navigating on a legged robot platform in outdoor environments. The robot's internal odometry based on leg motion is quite poor and causes the robot to have generally poor autonomous navigation performance. +In the below example, we're fusing the Stereolabs SDK's Pose Tracking VIO solution with a robot's external IMU and odometry (e.g. ``robot_localization`` has ``odom0`` ``odom1`` and ``imu0``) to improve performance while navigating on a legged robot platform in outdoor environments. The robot's internal odometry based on leg motion is quite poor and causes the robot to have generally poor autonomous navigation performance. -The Visual-Inertial Odometry's error over these datasets is 4.1% over the 70m path. Typically for 'good' odometry from wheel encoders + IMU, I would like to see 2-3% fully tuned (or less than 1% for 'great' odometry), so this is a great source! Fused in with the legged robot odometry, it improves overall performance to an acceptable level! +The Visual-Inertial Odometry's error over these datasets is 4.1% over the 70m path. Typically for 'good' odometry from wheel encoders + IMU, I would like to see 2-3% fully tuned (or less than 1% for 'great' odometry), so this is a great source! Fused in with the legged robot odometry, it improves overall performance to an acceptable level! .. note:: - - Steve is walking his robot dog through Golden Gate Park in San Francisco, CA with a joystick to collect this data. Steve's a bad robot driver (he doesn't play video games), the zig-zagging you see is due to his lack of good joystick control + the quadruped has a lot of additional asymmetric weight on it. It is not representative of Nav2 and should be mocked. *Its meant to test the accuracy of the VIO solution in more harsh conditions... yeah... lets go with that*. + + Steve is walking his robot dog through Golden Gate Park in San Francisco, CA with a joystick to collect this data. Steve's a bad robot driver (he doesn't play video games), the zig-zagging you see is due to his lack of good joystick control + the quadruped has a lot of additional asymmetric weight on it. It is not representative of Nav2 and should be mocked. *Its meant to test the accuracy of the VIO solution in more harsh conditions... yeah... lets go with that*. .. raw:: html diff --git a/tutorials/docs/navigation2_dynamic_point_following.rst b/tutorials/docs/navigation2_dynamic_point_following.rst index 160f016a33..a1a41cbef5 100644 --- a/tutorials/docs/navigation2_dynamic_point_following.rst +++ b/tutorials/docs/navigation2_dynamic_point_following.rst @@ -38,7 +38,7 @@ The requirements for this task are as follows: - The configuration of the planner and the controller will not be modified. - The action will indefinitely run until it is canceled by who initiated it. -The detection of the dynamic object (like a person) to follow is outside the scope of this tutorial. As shown in the following diagram, your application should provide a detector for the object(s) of interest, +The detection of the dynamic object (like a person) to follow is outside the scope of this tutorial. As shown in the following diagram, your application should provide a detector for the object(s) of interest, send the initial pose to the ``NavigateToPose`` action, and update it on a topic for the duration of the task. Many different types of detectors exist that you can leverage for this application: @@ -132,7 +132,7 @@ For reference, this exact behavior tree is `made available `_. Clone +publish coordinates in the topic ``/clicked_point``. This point needs to be sent to the behavior tree, using the program ``clicked_point_to_pose``, from `this repo `_. Clone this repo in your workspace, build, and type in a terminal. ``ros2 run nav2_test_utils clicked_point_to_pose`` diff --git a/tutorials/docs/navigation2_on_real_turtlebot3.rst b/tutorials/docs/navigation2_on_real_turtlebot3.rst index af7bb079a2..a28f5f52e2 100644 --- a/tutorials/docs/navigation2_on_real_turtlebot3.rst +++ b/tutorials/docs/navigation2_on_real_turtlebot3.rst @@ -21,7 +21,7 @@ Overview This tutorial shows how to control and navigate Turtlebot 3 using the ROS 2 Nav2 on a physical Turtlebot 3 robot. Before completing this tutorials, completing :ref:`getting_started` is highly recommended especially if you are new to ROS and Nav2. -This tutorial may take about 1 hour to complete. +This tutorial may take about 1 hour to complete. It depends on your experience with ROS, robots, and what computer system you have. Requirements @@ -101,7 +101,7 @@ Then, the map should appear in RViz. First, find where the robot is on the map. Check where your robot is in the room. Set the pose of the robot in RViz. -Click on the 2D Pose Estimate button and point the location of the robot on the map. +Click on the 2D Pose Estimate button and point the location of the robot on the map. The direction of the green arrow is the orientation of Turtlebot. .. image:: images/Navigation2_on_real_Turtlebot3/rviz_set_initial_pose.png @@ -109,13 +109,13 @@ The direction of the green arrow is the orientation of Turtlebot. :align: center :alt: Set initial pose in RViz -Now, the 3D model of Turtlebot should move to that location. +Now, the 3D model of Turtlebot should move to that location. A small error in the estimated location is tolerable. 5- Send a Goal Pose -------------------- -Pick a target location for Turtlebot on the map. +Pick a target location for Turtlebot on the map. You can send Turtlebot 3 a goal position and a goal orientation by using the **Nav2 Goal** or the **GoalTool** buttons. Note: Nav2 Goal button uses a ROS 2 Action to send the goal and the GoalTool publishes the goal to a topic. diff --git a/tutorials/docs/navigation2_with_gps.rst b/tutorials/docs/navigation2_with_gps.rst index 2f777923b8..576da7bdf7 100644 --- a/tutorials/docs/navigation2_with_gps.rst +++ b/tutorials/docs/navigation2_with_gps.rst @@ -26,7 +26,7 @@ This tutorial shows how to set up a localization system using a GPS sensor(s) as Requirements ============ -It is assumed ROS2 and Nav2 dependent packages are installed or built locally. Additionally you will have to install robot_localization and mapviz: +It is assumed ROS2 and Nav2 dependent packages are installed or built locally. Additionally you will have to install robot_localization and mapviz: .. code-block:: bash @@ -35,7 +35,7 @@ It is assumed ROS2 and Nav2 dependent packages are installed or built locally. A sudo apt install ros-$ROS_DISTRO-mapviz sudo apt install ros-$ROS_DISTRO-mapviz-plugins sudo apt install ros-$ROS_DISTRO-tile-map - + The code for this tutorial is hosted on `nav2_gps_waypoint_follower_demo `_. Though we will go through the most important steps of the setup, it's highly recommended that you clone and build the package when setting up your dev environment. This is available in ROS 2 Iron and newer. @@ -72,9 +72,9 @@ In the real world GPS sensors can be noisy: With standalone GPSs you should expe Additionally, to fully describe a robot's localization we need to know its heading as well, however standalone GPS sensors do not provide orientation measurements, only position measurements. In this tutorial we will refer to 'absolute heading' as a yaw measurement which is given w.r.t. a cardinal direction (e.g, the east), in contrast to relative heading, which is given w.r.t. the angle the robot is turned on or any other reference that cannot be directly mapped to a cardinal direction. -When using robot_localization with GPS, measuring absolute orientation is mandatory. There are several strategies for getting absolute orientation data, like IMUs with magnetometers, dual GPS systems or matching techniques over a known map; in this tutorial we assume the robot is equipped with an IMU that can accurately measure absolute orientation following the ENU convention, meaning it will output zero yaw when facing east and +90 degrees when facing north. +When using robot_localization with GPS, measuring absolute orientation is mandatory. There are several strategies for getting absolute orientation data, like IMUs with magnetometers, dual GPS systems or matching techniques over a known map; in this tutorial we assume the robot is equipped with an IMU that can accurately measure absolute orientation following the ENU convention, meaning it will output zero yaw when facing east and +90 degrees when facing north. -Despite the above assumption, in the real world commercial grade IMU's mounted in actual robots will often not produce accurate absolute heading measurements because: +Despite the above assumption, in the real world commercial grade IMU's mounted in actual robots will often not produce accurate absolute heading measurements because: 1. They may not have a magnetometer. @@ -82,7 +82,7 @@ Despite the above assumption, in the real world commercial grade IMU's mounted i 3. Robots can be a huge source of electromagnetic noise for magnetometers: Electric motors are full of permanent magnets and can draw several amps, producing significant disturbances to the sensor. -Thus, for a particular application you should consider the behavior and localization quality you require when making decisions about how to estimate your absolute heading. When using IMU's without relative headings to a cardinal direction, the robot may need to move around for a bit in an 'initialization dance' to converge to the right heading using the filter. Using dual-GPS or 3D mapping system overlay, the initial heading is quite good. +Thus, for a particular application you should consider the behavior and localization quality you require when making decisions about how to estimate your absolute heading. When using IMU's without relative headings to a cardinal direction, the robot may need to move around for a bit in an 'initialization dance' to converge to the right heading using the filter. Using dual-GPS or 3D mapping system overlay, the initial heading is quite good. For the purposes of this tutorial, we model a well-built system using an IMU that has absolute orientation already, but that may be augmented or replaced on a practical system using one of the techniques above (or others). @@ -99,8 +99,8 @@ To navigate using GPS we first need to create an outdoors Gazebo world with a ro + therefore we rotate the default frame 180 so that it would go back to ENU + see: https://github.com/osrf/gazebo/issues/2022 --> EARTH_WGS84 38.161479 -122.454630 @@ -149,19 +149,19 @@ Additionally, since we added a new GPS sensor in the ``gps_link`` we need to add -Build the ``nav2_gps_waypoint_follower_demo`` package, source your workspace and test your gazebo world is properly set up by launching: +Build the ``nav2_gps_waypoint_follower_demo`` package, source your workspace and test your gazebo world is properly set up by launching: .. code-block:: bash ros2 launch nav2_gps_waypoint_follower_demo gazebo_gps_world.launch.py -A Turtlebot waffle should appear in the Sonoma Raceway world. You may also echo the topic ``/gps/fix`` to verify the robot is indeed producing GPS measurements +A Turtlebot waffle should appear in the Sonoma Raceway world. You may also echo the topic ``/gps/fix`` to verify the robot is indeed producing GPS measurements .. image:: images/Gps_Navigation/gazebo_sonoma_raceway.png :width: 700px :align: center :alt: Turtlebot in the sonoma raceway - + 1- Setup GPS Localization system -------------------------------- @@ -169,7 +169,7 @@ Once you have your simulation (or real robot) up and running, it's time to set u In this tutorial, the GPS sensor on the robot will replace ``amcl`` in providing global localization. Though you may build a custom module that takes in the ``NavSatFix`` and ``Imu`` messages of your GPS and imu, and outputs a ``tf`` between your ``map`` and ``odom`` frames using a planar projection, Nav2's GPS waypoint follower currently uses robot_localization for converting GPS goals to cartesian goals, and thus at a `navsat_transform_node `_ should be active. Additionally, ``robot_localization`` features reconfigurable state estimation nodes that use Kalman Filters to fuse multiple sources of data, which is yet another reason to use it. -We will setup one Extended Kalman Filter for local odometry, fusing wheel odometry and IMU data; a second one for global localization, fusing the local cartesian converted GPS coordinates, the wheel odometry and the IMU data; and a navsat_transform node to output cartesian odometry messages from GPS data. This is a common setup on robot_localization when using GPS data and more details around its configuration can be found in `RL's docs `_. +We will setup one Extended Kalman Filter for local odometry, fusing wheel odometry and IMU data; a second one for global localization, fusing the local cartesian converted GPS coordinates, the wheel odometry and the IMU data; and a navsat_transform node to output cartesian odometry messages from GPS data. This is a common setup on robot_localization when using GPS data and more details around its configuration can be found in `RL's docs `_. A `configuration file `_ and a `launch file `_ are provided for this purpose. You may take a while before continuing to understand these two files and what they configure. Let's walk through the most relevant setting of each node. @@ -231,7 +231,7 @@ The global odometry is provided by the ``ekf_filter_node_map``, which publishes Navsat Transform ^^^^^^^^^^^^^^^^ -The navsat transform produces an odometry output with the position of the GPS in the ``map`` frame, which is ingested by the global EKF as said above. It exposes the ``datum`` parameter to set the GPS coordinates and heading of the origin of ``map``; if left undeclared it will be set automatically to the coordinates of the first valid ``NavSatFix`` message it gets, and it may be changed in runtime as well calling the ``/datum`` service. +The navsat transform produces an odometry output with the position of the GPS in the ``map`` frame, which is ingested by the global EKF as said above. It exposes the ``datum`` parameter to set the GPS coordinates and heading of the origin of ``map``; if left undeclared it will be set automatically to the coordinates of the first valid ``NavSatFix`` message it gets, and it may be changed in runtime as well calling the ``/datum`` service. In this tutorial we will go with the automatic ``datum`` initialization because there is no information about the environment stored in cartesian coordinates (a static map, semantic navigation waypoints, a 3D pointcloud map, etc), however if that's the case in your application you may fix the ``datum`` so a given pair of coordinates produced by the GPS always correspond to the same cartesian coordinates in your reference system. @@ -257,7 +257,7 @@ Here's the full configuration for the ``navsat_transform`` node: Localization Testing ^^^^^^^^^^^^^^^^^^^^ -As a sanity check that everything is working correctly, launch RL's launch file while Gazebo is still running: +As a sanity check that everything is working correctly, launch RL's launch file while Gazebo is still running: .. code-block:: bash @@ -276,7 +276,7 @@ You should see the window below after properly setting the API key: :align: center :alt: Turtlebot in the sonoma raceway -Finally run the teleop twist keyboard node to teleoperate the simulated Turtlebot: +Finally run the teleop twist keyboard node to teleoperate the simulated Turtlebot: .. code-block:: bash @@ -407,7 +407,7 @@ To run this node source your workspace and with the rest of the system running t ros2 run nav2_gps_waypoint_follower_demo logged_waypoint_follower -You should now see the robot following the waypoints you previously logged: +You should now see the robot following the waypoints you previously logged: .. image:: images/Gps_Navigation/logged_waypoint_follower.gif :width: 800px diff --git a/tutorials/docs/navigation2_with_slam.rst b/tutorials/docs/navigation2_with_slam.rst index 959fadc2e0..b6a8b1a4b9 100644 --- a/tutorials/docs/navigation2_with_slam.rst +++ b/tutorials/docs/navigation2_with_slam.rst @@ -65,7 +65,7 @@ Launch your robot's interface and robot state publisher, for example: Launch Navigation without nav2_amcl and nav2_map_server. It is assumed that the SLAM node(s) will publish to /map topic and provide the map->odom transform. - + ``ros2 launch nav2_bringup navigation_launch.py`` 2- Launch SLAM diff --git a/tutorials/docs/navigation2_with_speed_filter.rst b/tutorials/docs/navigation2_with_speed_filter.rst index 76646e35d1..76c1dd9c63 100644 --- a/tutorials/docs/navigation2_with_speed_filter.rst +++ b/tutorials/docs/navigation2_with_speed_filter.rst @@ -39,7 +39,7 @@ Let's look, how it is being decoded. As we know, ``OccupancyGrid`` values are be speed_limit = filter_mask_data * multiplier + base; -where: +where: - ``filter_mask_data`` - is an ``OccupancyGrid`` value of the corresponding cell on mask where maximum speed should be restricted. - ``base`` and ``multiplier`` are coefficients taken from ``nav2_msgs/CostmapFilterInfo`` messages published by Costmap Filter Info Server (see in next chapter below). diff --git a/tutorials/docs/using_collision_monitor.rst b/tutorials/docs/using_collision_monitor.rst index 5b354b0a58..a61dbb2e8e 100644 --- a/tutorials/docs/using_collision_monitor.rst +++ b/tutorials/docs/using_collision_monitor.rst @@ -161,7 +161,7 @@ Below is the example configuration using 4 sub-polygons to cover the full range theta_max: 1.0 # This is the last polygon to be checked, it should cover the entire range of robot's velocities # It is used as the stopped polygon when the robot is not moving and as a fallback if the velocity - # is not covered by any of the other sub-polygons + # is not covered by any of the other sub-polygons stopped: points: "[[0.25, 0.25], [0.25, -0.25], [-0.25, -0.25], [-0.25, 0.25]]" linear_min: -1.0 @@ -177,7 +177,7 @@ Below is the example configuration using 4 sub-polygons to cover the full range **For holomic robots:** -For holomic robots, the ``holonomic`` property should be set to ``true``. In this scenario, the ``linear_min`` and ``linear_max`` parameters should cover the robot's resultant velocity limits, while the ``theta_min`` and ``theta_max`` parameters should cover the robot's angular velocity limits. Additionally, there will be 2 more parameters, ``direction_start_angle`` and ``direction_end_angle``, to specify the resultant velocity direction. The covered direction will always span from ``direction_start_angle`` to ``direction_end_angle`` in the **counter-clockwise** direction. +For holomic robots, the ``holonomic`` property should be set to ``true``. In this scenario, the ``linear_min`` and ``linear_max`` parameters should cover the robot's resultant velocity limits, while the ``theta_min`` and ``theta_max`` parameters should cover the robot's angular velocity limits. Additionally, there will be 2 more parameters, ``direction_start_angle`` and ``direction_end_angle``, to specify the resultant velocity direction. The covered direction will always span from ``direction_start_angle`` to ``direction_end_angle`` in the **counter-clockwise** direction. .. image:: images/Collision_Monitor/holonomic_direction.png :width: 365px @@ -193,7 +193,7 @@ Preparing Nav2 stack The Collision Monitor is designed to operate below Nav2 as an independent safety node. It acts as a filter for the ``cmd_vel`` messages from the controller to avoid potential collisions. If no such zone is triggered, then the ``cmd_vel`` message is used. -Else, it is scaled or set to stop as appropriate. +Else, it is scaled or set to stop as appropriate. By default, the Collision Monitor is configured for usage with the Nav2 bringup package, running in parallel with the ``navigation_launch.py`` launch file. For correct operation of the Collision Monitor with the Velocity Smoother, it is required to remove the Velocity Smoother's ``cmd_vel_smoothed`` remapping in the ``navigation_launch.py`` bringup script as presented below. This will make the output topic of the Velocity Smoother to be untouched, which will be the input to the newly added Collision Monitor: @@ -223,7 +223,7 @@ By default, the Collision Monitor is configured for usage with the Nav2 bringup If you have changed Collision Monitor's default ``cmd_vel_in_topic`` and ``cmd_vel_out_topic`` configuration, make sure Velocity Smoother's default output topic ``cmd_vel_smoothed`` should match to the input velocity ``cmd_vel_in_topic`` parameter value of the Collision Monitor node, and the output velocity ``cmd_vel_out_topic`` parameter value should be actual ``cmd_vel`` to fit the replacement. -.. note:: As the Collision Monitor acts as a safety node, it must be the last link in the velocity message post-processing chain, making it the node that publishes to the ``cmd_vel`` topic. It could be placed after smoothed velocity, as in our demonstration, or after non-smoothed velocity from Controller Server, e.g. if Velocity Smoother was not enabled in the system, or going after any other module in custom configuration producing the end-velocity. Therefore, in any custom Nav2 launch configuration, the last node publishing to the ``cmd_vel`` topic, should be remapped to publish to the Collision Monitor input topic configured by ``cmd_vel_in_topic`` ROS-parameter (``cmd_vel_smoothed`` by default). +.. note:: As the Collision Monitor acts as a safety node, it must be the last link in the velocity message post-processing chain, making it the node that publishes to the ``cmd_vel`` topic. It could be placed after smoothed velocity, as in our demonstration, or after non-smoothed velocity from Controller Server, e.g. if Velocity Smoother was not enabled in the system, or going after any other module in custom configuration producing the end-velocity. Therefore, in any custom Nav2 launch configuration, the last node publishing to the ``cmd_vel`` topic, should be remapped to publish to the Collision Monitor input topic configured by ``cmd_vel_in_topic`` ROS-parameter (``cmd_vel_smoothed`` by default). Demo Execution ============== diff --git a/tutorials/docs/using_docking.rst b/tutorials/docs/using_docking.rst index b4f929ed92..3167ec1ab0 100644 --- a/tutorials/docs/using_docking.rst +++ b/tutorials/docs/using_docking.rst @@ -20,7 +20,7 @@ This is accomplished via plugins ``ChargingDock`` and ``NonChargingDock`` which A configuration of the docking server can contain a database of many docks of different plugin ``ChargingDock`` and ``NonChargingDock`` types to handle a broad range of docking locations and hardware dock revisions. Included with the package is an example ``SimpleChargingDock`` and ``SimpleNonChargingDock`` plugins which contains features and methods very common for robot docking. These support charging stations and docking with static infrastructure (ex. conveyor belts) or dynamic docking (ex pallets) locations. -It is likely that you may be able to use this as well rather than developing your own dock plugin to get started. +It is likely that you may be able to use this as well rather than developing your own dock plugin to get started. The docking procedure is as follows: @@ -28,7 +28,7 @@ The docking procedure is as follows: 2. If the robot is not within the prestaging tolerance of the dock's staging pose, navigate to the staging pose 3. Use the dock's plugin to initially detect the dock and return the docking pose 4. Enter a vision-control loop where the robot attempts to reach the docking pose while its actively being refined by the vision system -5. Exit the vision-control loop once contact has been detected or charging has started +5. Exit the vision-control loop once contact has been detected or charging has started 6. Wait until charging starts (if applicable) and return success. Thanks to NVIDIA for sponsoring this Docking Server package and this tutorial! @@ -62,7 +62,7 @@ However, one way or another, your system requires an applicable ``ChargingDock`` The plugins has a few key APIs: - ``PoseStamped getStagingPose(const Pose & pose, const string & frame)`` which must provide the pre-docking staging pose given a dock's location and frame. -- ``bool getRefinedPose(PoseStamped & pose)`` which must provide the detected (or pass through) pose of the dock +- ``bool getRefinedPose(PoseStamped & pose)`` which must provide the detected (or pass through) pose of the dock - ``bool isDocked()`` which provides if we've made contact with the dock - ``bool isCharging()`` which provides if we've started charging while docked (charging docks only) - ``bool disableCharging()`` which should disable charging, if under the robot's control for undocking (charging docks only) @@ -78,7 +78,7 @@ The ``SimpleChargingDock`` provides an implementation with common options for th - ``hasStoppedCharging`` - The inverse of ``isCharging`` (charging docks only) Thus, for testing (no detection, no battery information, no joint state information) and realistic application (dock detection, battery status information, joint state information), this dock plugin can be used. -It can also be used when only some of the information if available as well. +It can also be used when only some of the information if available as well. If your robot or dock does not fall into these implementations (i.e. using custom battery or detection messages that cannot be converted into ROS standard types), then you may be required to build your own plugin to meet your particular needs. However, you can use the ``SimpleChargingDock`` assuming you turn off these settings and dock blind to get started. There is an equivalent ``SimpleNonChargingDock`` plugin for non-charging docking needs. @@ -284,7 +284,7 @@ During execution, feedback is provided on the current docking state - which is p The feedback can be obtained from your action client if this information is useful to your application. The ``UndockRobot`` action is even simpler. There are no required goal fields except ``dock_type`` if undocking is being called when the server's instance did not dock the robot to store its current state information (such as after a restart on the dock). -It contains no feedback and returns the ``success`` state and the ``error_code`` if a problem occurs. +It contains no feedback and returns the ``success`` state and the ``error_code`` if a problem occurs. .. code-block:: bash @@ -307,8 +307,8 @@ Putting It All Together At this point, if you haven't already, create your dock plugin (or use ``SimpleChargingDock``), configuration file, and launch file - along with any other nodes required like apriltags or other detectors. You can see an example package used in this tutorial in the ``nova_carter_docking`` package, which contains a configuration file and launch file containing the apriltags detector and ``PoseStamped`` pose publisher. -If you're interested in using Apriltags and an Nvidia Jetson, you can find the tags we used in the ``media/`` directory and the launch file ``isaac_apriltag_detection_pipeline.launch.py`` which sets it all up for you. -If not using the Jetson, you can replace the Isaac ROS apriltag detector with ``image_proc``. +If you're interested in using Apriltags and an Nvidia Jetson, you can find the tags we used in the ``media/`` directory and the launch file ``isaac_apriltag_detection_pipeline.launch.py`` which sets it all up for you. +If not using the Jetson, you can replace the Isaac ROS apriltag detector with ``image_proc``. We can test this using the script ``demo.py`` in ``nova_carter_docking``'s root directory. It will set the robot's pose as virtually the dock's staging pose to bypass navigating to the staging pose and attempt docking immediately, then infinitely loop docking and undocking in a row. @@ -330,7 +330,7 @@ Note that the robot is able to overcome: - Dock repeatedly with a 100% success rate due to the detections and charging state feedback This script demonstrates the essential use of the Docking Server. -However, it does not use the dock database of pre-mapped dock locations that you setup. +However, it does not use the dock database of pre-mapped dock locations that you setup. After you launch Nav2 and localize your robot in your map, we can adjust ``dockRobot()`` to take in your desired ``dock_id`` and perform docking instead: Then, we can see the full docking system in action in a non-trivial environment! @@ -358,7 +358,7 @@ Then, we can see the full docking system in action in a non-trivial environment! self.result_future = self.goal_handle.get_result_async() return True - + ... dock_id = 'home_dock' diff --git a/tutorials/docs/using_groot.rst b/tutorials/docs/using_groot.rst index 5868067ee5..59ac7f27c2 100644 --- a/tutorials/docs/using_groot.rst +++ b/tutorials/docs/using_groot.rst @@ -7,7 +7,7 @@ Groot - Interacting with Behavior Trees :name: groot_startup_menu :align: center -- `Overview`_ +- `Overview`_ - `Visualize Behavior Trees`_ - `Edit Behavior Trees`_ - `Adding A Custom Node`_ @@ -45,7 +45,7 @@ Out of the box, Groot can only display Behavior Trees and nodes that are from th Therefore, we must point Groot to our palette, or index, of Nav2 / custom behavior tree nodes: 1. Open Groot in editor mode. Now, Groot should look like in :numref:`groot_bt_editor`. -2. Select the `Load palette from file` option either via the context menu or the import icon in the top middle of the menu bar. +2. Select the `Load palette from file` option either via the context menu or the import icon in the top middle of the menu bar. 3. Open the file `/path/to/navigation2/nav2_behavior_tree/nav2_tree_nodes.xml` to import all the custom behavior tree nodes used for navigation. This is the palette of Nav2 custom behavior tree nodes. Now, Groot should look like in :numref:`groot_bt_editor_with_nodes`. 4. Select `Load tree` option near the top left corner 5. Browse the tree you want to visualize, then select `OK`. The Nav2 BTs exist in `/path/to/navigation2/nav2_bt_navigator/behavior_trees/` @@ -96,8 +96,8 @@ Implementing the node itself needs to be done separately from Groot, which is de +-----------------------------------------------------------+ Creating a new custom node can be started by clicking the orange marked icon in :numref:`groot_create_custom_node`, while Groot is in Editor mode. -This should load a new window, similar to :numref:`groot_interactive_node_creation`. -In this new window, it asks you to fill in the metadata about this new node, in order to create it. +This should load a new window, similar to :numref:`groot_interactive_node_creation`. +In this new window, it asks you to fill in the metadata about this new node, in order to create it. It will ask you for standard information such as name (green box), type of node (orange box), and any optional ports for parameterization or access to blackboard variables (blue box). After completing, select `OK` in :numref:`groot_interactive_node_creation`, the new custom node should appear in blue in the `TreeNode Palette` as in :numref:`groot_export_new_node`. diff --git a/tutorials/docs/using_shim_controller.rst b/tutorials/docs/using_shim_controller.rst index 4d1a745e04..4c1c27ac70 100644 --- a/tutorials/docs/using_shim_controller.rst +++ b/tutorials/docs/using_shim_controller.rst @@ -4,7 +4,7 @@ Using Rotation Shim Controller ****************************** -- `Overview`_ +- `Overview`_ - `What is the Rotation Shim Controller?`_ - `Configuring Rotation Shim Controller`_ - `Configuring Primary Controller`_ @@ -20,17 +20,17 @@ Before starting this tutorial, completing the :ref:`getting_started` is highly r What is the Rotation Shim Controller? ===================================== -This was developed due to quirks in TEB and DWB, but applicable to any other controller plugin type that you'd like to have rotation in place behavior with. ``TEB``'s behavior tends to whip the robot around with small turns, or when the path is starting at a very different heading than current, in a somewhat surprising way due to the elastic band approach. ``DWB`` can be tuned to have any type of behavior, but typically to tune it to be an excellent path follower also makes it less optimally capable of smooth transitions to new paths at far away headings -- there are always trade offs. Giving both TEB and DWB a better starting point to start tracking a path makes tuning the controllers significantly easier and creates more intuitive results for on-lookers. +This was developed due to quirks in TEB and DWB, but applicable to any other controller plugin type that you'd like to have rotation in place behavior with. ``TEB``'s behavior tends to whip the robot around with small turns, or when the path is starting at a very different heading than current, in a somewhat surprising way due to the elastic band approach. ``DWB`` can be tuned to have any type of behavior, but typically to tune it to be an excellent path follower also makes it less optimally capable of smooth transitions to new paths at far away headings -- there are always trade offs. Giving both TEB and DWB a better starting point to start tracking a path makes tuning the controllers significantly easier and creates more intuitive results for on-lookers. -Note that it is not required to use this with **any** plugin. Many users are perfectly successful without using this controller, but if a robot may rotate in place before beginning its path tracking task (or others), it can be advantageous to do so. +Note that it is not required to use this with **any** plugin. Many users are perfectly successful without using this controller, but if a robot may rotate in place before beginning its path tracking task (or others), it can be advantageous to do so. -The ``nav2_rotation_shim_controller`` will check the rough heading difference with respect to the robot and a newly received path. If within a threshold, it will pass the request onto the ``primary_controller`` to execute the task. If it is outside of the threshold, this controller will rotate the robot in place towards that path heading. Once it is within the tolerance, it will then pass off control-execution from this rotation shim controller onto the primary controller plugin. At this point, the robot's main plugin will take control for a smooth hand off into the task. +The ``nav2_rotation_shim_controller`` will check the rough heading difference with respect to the robot and a newly received path. If within a threshold, it will pass the request onto the ``primary_controller`` to execute the task. If it is outside of the threshold, this controller will rotate the robot in place towards that path heading. Once it is within the tolerance, it will then pass off control-execution from this rotation shim controller onto the primary controller plugin. At this point, the robot's main plugin will take control for a smooth hand off into the task. The ``RotationShimController`` is most suitable for: - Robots that can rotate in place, such as differential and omnidirectional robots. - Preference to rotate in place when starting to track a new path that is at a significantly different heading than the robot's current heading -- or when tuning your controller for its task makes tight rotations difficult. -- Using planners that are non-kinematically feasible, such as NavFn, Theta\*, or Smac 2D (Feasible planners such as Smac Hybrid-A* and State Lattice will start search from the robot's actual starting heading, requiring no rotation since their paths are guaranteed drivable by physical constraints). +- Using planners that are non-kinematically feasible, such as NavFn, Theta\*, or Smac 2D (Feasible planners such as Smac Hybrid-A* and State Lattice will start search from the robot's actual starting heading, requiring no rotation since their paths are guaranteed drivable by physical constraints). .. note:: Regulated Pure Pursuit has this built in so it is not necessary to pair with RPP. However, it is applicable to all others. See :ref:`plugins` for a full list of current controller plugins. @@ -78,11 +78,11 @@ The Rotation Shim Controller is very simple and only has a couple of parameters - ``rotate_to_heading_angular_vel``: The angular velocity (in rad/s) to have the robot rotate to heading by, when the behavior is enacted. - ``max_angular_accel``: The angular acceleration (in rad/s/s) to have the robot rotate to heading by, when the behavior is enacted. - ``simulate_ahead_time``: The Time (s) to forward project the rotation command to check for collision - + Configuring Primary Controller ============================== -There is one more remaining parameter of the ``RotationShimController`` not mentioned above, the ``primary_controller``. This is the type of controller that your application would like to use as the primary modus operandi. It will share the same name and yaml namespace as the shim plugin. You can observe this below with the primary controller set the ``DWB`` (with the progress and goal checkers removed for brevity). +There is one more remaining parameter of the ``RotationShimController`` not mentioned above, the ``primary_controller``. This is the type of controller that your application would like to use as the primary modus operandi. It will share the same name and yaml namespace as the shim plugin. You can observe this below with the primary controller set the ``DWB`` (with the progress and goal checkers removed for brevity). .. code-block:: yaml @@ -108,7 +108,7 @@ There is one more remaining parameter of the ``RotationShimController`` not ment ... ... -An important note is that **within the same yaml namespace**, you may also include any ``primary_controller`` specific parameters required for a robot. Thusly, after ``max_angular_accel``, you can include any of ``DWB``'s parameters for your platform. +An important note is that **within the same yaml namespace**, you may also include any ``primary_controller`` specific parameters required for a robot. Thusly, after ``max_angular_accel``, you can include any of ``DWB``'s parameters for your platform. Demo Execution