Fix smart quotes (backport #5030) (#5044)

* Fix smart quotes (#5030)

(cherry picked from commit ecdc45f)

Signed-off-by: Christophe Bedard <[email protected]>
Co-authored-by: David V. Lu!! <[email protected]>
Co-authored-by: Christophe Bedard <[email protected]>

source/Concepts/Basic/About-Client-Libraries.rst

@@ -109,7 +109,7 @@ Language-specific functionality
 -------------------------------
 
 Client library concepts that require language-specific features/properties are not implemented in the RCL but instead are implemented in each client library.
-For example, threading models used by “spin” functions will have implementations that are specific to the language of the client library.
+For example, threading models used by "spin" functions will have implementations that are specific to the language of the client library.
 
 Demo
 ----

source/Concepts/Intermediate/About-Executors.rst

@@ -202,4 +202,4 @@ Further information
   ROS Industrial Conference.
   Virtual event.
   16 December 2020.
-* Daniel Casini, Tobias Blass, Ingo Lütkebohle, and Björn Brandenburg: `“Response-Time Analysis of ROS 2 Processing Chains under Reservation-Based Scheduling” <https://drops.dagstuhl.de/opus/volltexte/2019/10743/pdf/LIPIcs-ECRTS-2019-6.pdf>`_, Proc. of 31st ECRTS 2019, Stuttgart, Germany, July 2019.
+* Daniel Casini, Tobias Blass, Ingo Lütkebohle, and Björn Brandenburg: `"Response-Time Analysis of ROS 2 Processing Chains under Reservation-Based Scheduling" <https://drops.dagstuhl.de/opus/volltexte/2019/10743/pdf/LIPIcs-ECRTS-2019-6.pdf>`_, Proc. of 31st ECRTS 2019, Stuttgart, Germany, July 2019.

source/Concepts/Intermediate/About-Quality-of-Service-Settings.rst

@@ -58,7 +58,7 @@ The base QoS profile currently includes settings for the following policies:
 
 * Liveliness
 
-  * *Automatic*: the system will consider all of the node’s publishers to be alive for another "lease duration" when any one of its publishers has published a message.
+  * *Automatic*: the system will consider all of the node's publishers to be alive for another "lease duration" when any one of its publishers has published a message.
   * *Manual by topic*: the system will consider the publisher to be alive for another "lease duration" if it manually asserts that it is still alive (via a call to the publisher API).
 
 * Lease Duration
@@ -103,7 +103,7 @@ The currently defined QoS profiles are:
 
 * Sensor data
 
-  For sensor data, in most cases it’s more important to receive readings in a timely fashion, rather than ensuring that all of them arrive.
+  For sensor data, in most cases it's more important to receive readings in a timely fashion, rather than ensuring that all of them arrive.
   That is, developers want the latest samples as soon as they are captured, at the expense of maybe losing some.
   For that reason the sensor data profile uses best effort reliability and a smaller queue size.
 
@@ -114,7 +114,7 @@ The currently defined QoS profiles are:
 
 * System default
 
-  This uses the RMW implementation’s default values for all of the policies.
+  This uses the RMW implementation's default values for all of the policies.
   Different RMW implementations may have different defaults.
 
 `Click here <https://github.com/ros2/rmw/blob/{REPOS_FILE_BRANCH}/rmw/include/rmw/qos_profiles.h>`__ for the specific policies in use for the above profiles.

source/Contact.rst

@@ -26,11 +26,11 @@ It's better to send all questions to `Robotics Stack Exchange <https://robotics.
 Contributing support
 ^^^^^^^^^^^^^^^^^^^^
 
-ROS 2 users come from a wide range of technical backgrounds, use a variety of different operating systems, and don’t necessarily have any prior experience with ROS (1 or 2).
+ROS 2 users come from a wide range of technical backgrounds, use a variety of different operating systems, and don't necessarily have any prior experience with ROS (1 or 2).
 So, it's important for users with any amount of experience to contribute support.
 
-If you see an issue on `Robotics Stack Exchange <https://robotics.stackexchange.com/>`__ that is similar to something you’ve run into yourself, please consider providing some pointers to what helped in your situation.
-Don’t worry if you aren't sure if your response is correct.
+If you see an issue on `Robotics Stack Exchange <https://robotics.stackexchange.com/>`__ that is similar to something you've run into yourself, please consider providing some pointers to what helped in your situation.
+Don't worry if you aren't sure if your response is correct.
 Simply say so, and other community members will jump in if necessary.
 
 Issues
@@ -95,7 +95,7 @@ To start a discussion with other ROS 2 community members, visit the official `RO
 Content on the Discourse should be high-level;
 it's not a place to get *questions* about code answered, but it would be suitable to start a conversation about best practices or improving standards.
 
-Discussions about ROS 2 development and plans are happening on the `“Next Generation ROS” Discourse category <https://discourse.ros.org/c/ng-ros>`__.
+Discussions about ROS 2 development and plans are happening on the `"Next Generation ROS" Discourse category <https://discourse.ros.org/c/ng-ros>`__.
 Participating in these discussions is an important way to have a say on how different features of ROS 2 will work and be implemented.
 
 The diverse community behind the ROS ecosystem is one of its greatest assets.

source/How-To-Guides/DDS-tuning.rst

@@ -46,7 +46,7 @@ Reduce the value, for example, to 3s, by running:
 
     sudo sysctl net.ipv4.ipfrag_time=3
 
-Reducing this parameter’s value also reduces the window of time where no fragments are received.
+Reducing this parameter's value also reduces the window of time where no fragments are received.
 The parameter is global for all incoming fragments, so the feasibility of reducing its value needs to be considered for every environment.
 
 **Solution:** Increase the value of the ``ipfrag_high_thresh`` parameter.
@@ -60,7 +60,7 @@ Increase the value, for example, to 128MB, by running:
 
     sudo sysctl net.ipv4.ipfrag_high_thresh=134217728     # (128 MB)
 
-Significantly increasing this parameter’s value is an attempt to ensure that the buffer never becomes completely full.
+Significantly increasing this parameter's value is an attempt to ensure that the buffer never becomes completely full.
 However, the value would likely have to be significantly high to hold all data received during the time window of ``ipfrag_time``, assuming every UDP packet lacks one fragment.
 
 **Issue:** Sending custom messages with large variable-sized arrays of non-primitive types causes high serialization/deserialization overhead and CPU load.
@@ -102,7 +102,7 @@ Cyclone DDS tuning
 **Issue:** Cyclone DDS is not delivering large messages reliably, despite using reliable settings and transferring over a wired network.
 
 This issue should be `addressed soon <https://github.com/eclipse-cyclonedds/cyclonedds/issues/484>`_.
-Until then, we’ve come up with the following solution (debugged using `this test program <https://github.com/jacobperron/pc_pipe>`_):
+Until then, we've come up with the following solution (debugged using `this test program <https://github.com/jacobperron/pc_pipe>`_):
 
 **Solution:** Increase the maximum Linux kernel receive buffer size and the minimum socket receive buffer size that Cyclone uses.
 
@@ -158,12 +158,12 @@ By tuning ``net.core.rmem_max`` to 4MB in the Linux kernel, the QoS profile can
 This configuration has been proven to reliably deliver messages via SHMEM|UDPv4, and with just UDPv4 on a single machine.
 A multi-machine configuration was also tested with ``rmem_max`` at 4MB and at 20MB (two machines connected with 1Gbps ethernet), with no dropped messages and average message delivery times of 700ms and 371ms, respectively.
 
-Without configuring the kernel’s ``rmem_max``, the same Connext QoS profile took up to 12 seconds for the data to be delivered.
+Without configuring the kernel's ``rmem_max``, the same Connext QoS profile took up to 12 seconds for the data to be delivered.
 However, it always at least managed to complete the delivery.
 
 **Solution:** Use the `Connext QoS profile <https://github.com/jacobperron/pc_pipe/blob/master/etc/ROS2TEST_QOS_PROFILES.xml>`_ *without* adjusting ``rmem_max``.
 
-The ROS2TEST_QOS_PROFILES.xml file was configured using RTI’s documentation on `configuring flow controllers <https://community.rti.com/forum-topic/transfering-large-data-over-dds>`_.
+The ROS2TEST_QOS_PROFILES.xml file was configured using RTI's documentation on `configuring flow controllers <https://community.rti.com/forum-topic/transfering-large-data-over-dds>`_.
 It has slow, medium and fast flow controllers (seen in the Connext QoS profile link).
 
 The medium flow controller produced the best results for our case.

source/How-To-Guides/Getting-Backtraces-in-ROS-2.rst

@@ -134,14 +134,14 @@ For GDB debugging, use it as follows:
 **Why Direct GDB Usage Can Be Tricky**
 
 ``--prefix`` will execute some bits of code before our ROS 2 command allowing us to insert some information.
-If you attempted to do ``gdb ex run --args ros2 run <pkg> <node>`` as analog to our example in the preliminaries, you’d find that it couldn’t find the ``ros2`` command.
+If you attempted to do ``gdb ex run --args ros2 run <pkg> <node>`` as analog to our example in the preliminaries, you'd find that it couldn't find the ``ros2`` command.
 Additionally, trying to source your workspace within GDB would fail for similar reasons.
 This is because GDB, when launched this way, lacks the environment setup that normally makes the ``ros2`` command available.
 
 **Simplifying the Process with --prefix**
 
 Rather than having to revert to finding the install path of the executable and typing it all out, we can instead use ``--prefix``.
-This allows us to use the same ``ros2 run`` syntax you’re used to without having to worry about some of the GDB details.
+This allows us to use the same ``ros2 run`` syntax you're used to without having to worry about some of the GDB details.
 
 .. code-block:: bash
 
@@ -168,7 +168,7 @@ After you obtain a backtrace using GDB, here's how to interpret it:
 
 **How to Debug once your Node Crashes**
 
-Once your node crashes, you’ll see a prompt like below.
+Once your node crashes, you'll see a prompt like below.
 At this point you can get a backtrace.
 
 .. code-block:: bash
@@ -219,7 +219,7 @@ From a Launch File
 Just as in our non-ROS example, we need to setup a GDB session before launching our ROS 2 launch file.
 While we could set this up through the commandline, we can instead make use of the same mechanics that we did in the ``ros2 run`` node example, now using a launch file.
 
-In your launch file, find the node that you’re interested in debugging.
+In your launch file, find the node that you're interested in debugging.
 For this section, we assume that your launch file contains only a single node (and potentially other information as well).
 The ``Node`` function used in the ``launch_ros`` package will take in a field prefix taking a list of prefix arguments.
 We will insert the GDB snippet here.

source/How-To-Guides/Overriding-QoS-Policies-For-Recording-And-Playback.rst

@@ -43,7 +43,7 @@ The YAML schema for the profile overrides is a dictionary of topic names with ke
 
 If a policy value is not specified, the value will fallback to the default used by Ros2Bag.
 If you specify a Duration based policy such as ``deadline`` or ``lifespan``, you will need to specify both seconds and nanoseconds.
-Policy values are determined by the policy’s short keys which can be found using ``ros2topic`` verbs such as ``ros2 topic pub --help``.
+Policy values are determined by the policy's short keys which can be found using ``ros2topic`` verbs such as ``ros2 topic pub --help``.
 All values are replicated below for reference.
 
 .. code-block:: yaml

source/How-To-Guides/Sync-Vs-Async.rst

@@ -127,7 +127,7 @@ They can be made from anywhere without running the risk of blocking other ROS an
 An asynchronous client will immediately return ``future``, a value that indicates whether the call and response is finished (not the value of the response itself), after sending a request to a service.
 The returned ``future`` may be queried for a response at any time.
 
-Since sending a request doesn’t block anything, a loop can be used to both spin ``rclpy`` and check ``future`` in the same thread, for example:
+Since sending a request doesn't block anything, a loop can be used to both spin ``rclpy`` and check ``future`` in the same thread, for example:
 
 .. code-block:: python
 

source/How-To-Guides/Using-Python-Packages.rst

@@ -36,14 +36,14 @@ In a new workspace, you can also quickly install all rosdep keys with:
 
     rosdep install -yr ./path/to/your/workspace
 
-If there aren’t currently ``rosdep`` keys for the package that you are interested in, it is possible to add them by following the `rosdep key contribution guide`_.
+If there aren't currently ``rosdep`` keys for the package that you are interested in, it is possible to add them by following the `rosdep key contribution guide`_.
 
 To learn more about the ``rosdep`` tool and how it works, consult the `rosdep documentation`_.
 
 Installing via a package manager
 --------------------------------
 
-If you don’t want to make a rosdep key, but the package is available in your system package manager (eg ``apt``), you can install and use the package that way:
+If you don't want to make a rosdep key, but the package is available in your system package manager (eg ``apt``), you can install and use the package that way:
 
 .. code-block:: console
 
@@ -78,7 +78,7 @@ Then setup your virtual environment:
     # Make a virtual env and activate it
     virtualenv -p python3 ./venv
     source ./venv/bin/activate
-    # Make sure that colcon doesn’t try to build the venv
+    # Make sure that colcon doesn't try to build the venv
     touch ./venv/COLCON_IGNORE
 
 Next, install the Python packages that you want in your virtual environment:

source/How-To-Guides/Using-callback-groups.rst

@@ -94,7 +94,7 @@ in mind when working with callback groups.
   the edge of the system (user and sensor inputs etc).
 * Sometimes the callbacks are hidden and their presence may not be obvious
   from the user/developer API.
-  This is the case especially with any kind of “synchronous” call to a
+  This is the case especially with any kind of "synchronous" call to a
   service or an action (in rclpy).
   For example, the synchronous call ``Client.call(request)`` to a service
   adds a Future's done-callback that needs to be executed during the

source/Releases/Beta1-Overview.rst

@@ -60,6 +60,6 @@ For the complete list, see `earlier release notes <../index>`.
 Known issues
 ^^^^^^^^^^^^
 
-* We’re tracking issues in various repositories, but the main entry point is the `ros2/ros2 issue tracker <https://github.com/ros2/ros2/issues>`__
-* We’d like to highlight a `known issue <https://github.com/ros2/rmw_fastrtps/issues/81>`__ that we are working with eProsima to fix that results in significantly degrated performance for large messages under FastRTPS.
+* We're tracking issues in various repositories, but the main entry point is the `ros2/ros2 issue tracker <https://github.com/ros2/ros2/issues>`__
+* We'd like to highlight a `known issue <https://github.com/ros2/rmw_fastrtps/issues/81>`__ that we are working with eProsima to fix that results in significantly degrated performance for large messages under FastRTPS.
   This will be observed when running some of the demos with larger image resolutions.

source/Releases/Beta2-Overview.rst

@@ -86,6 +86,6 @@ For the complete list, see `earlier release notes <../index>`.
 Known issues
 ^^^^^^^^^^^^
 
-* We’re tracking issues in various repositories, but the main entry point is the `ros2/ros2 issue tracker <https://github.com/ros2/ros2/issues>`__
-* We’d like to highlight a `known issue <https://github.com/ros2/rmw_connext/issues/234>`__ that we are looking into which doesn't allow two topics with the same base name but different namespaces to have a different type when using ``rmw_connext_cpp``.
+* We're tracking issues in various repositories, but the main entry point is the `ros2/ros2 issue tracker <https://github.com/ros2/ros2/issues>`__
+* We'd like to highlight a `known issue <https://github.com/ros2/rmw_connext/issues/234>`__ that we are looking into which doesn't allow two topics with the same base name but different namespaces to have a different type when using ``rmw_connext_cpp``.
 * Services with long responses are not working with Fast-RTPS. The fix, while not being part of beta2, is available upstream so you can work around this issue by building from source using Fast-RTPS master branch.

source/The-ROS2-Project/Contributing.rst

@@ -77,9 +77,9 @@ What to work on
 We have identified a number of tasks that could be worked on by community members: they can be listed by `searching across the ROS 2 repositories for issues labeled as "help wanted" <https://github.com/search?q=user%3Aament+user%3Aros2+is%3Aopen+label%3A"help+wanted"&type=Issues>`__.
 If you see something on that list that you would like to work on, please comment on the item to let others know that you are looking into it.
 
-We also have a label for issues that we think should be more accessible for first-time contributors, `labeled “good first issue” <https://github.com/search?q=user%3Aament+user%3Aros2+is%3Aopen+label%3A%22good+first+issue%22&type=Issues>`__.
+We also have a label for issues that we think should be more accessible for first-time contributors, `labeled "good first issue" <https://github.com/search?q=user%3Aament+user%3Aros2+is%3Aopen+label%3A%22good+first+issue%22&type=Issues>`__.
 If you are interested in contributing to the ROS 2 project, we encourage you to take a look at those issues first.
-If you’d like to cast a wider net, we welcome contributions on any open issue (or others that you might propose), particularly tasks that have a milestone signifying they’re targeted for the next ROS 2 release (the milestone will be the next release's e.g. 'crystal').
+If you'd like to cast a wider net, we welcome contributions on any open issue (or others that you might propose), particularly tasks that have a milestone signifying they're targeted for the next ROS 2 release (the milestone will be the next release's e.g. 'crystal').
 
 If you have some code to contribute that fixes a bug or improves documentation, please submit it as a pull request to the relevant repository.
 For larger changes, it is a good idea to discuss the proposal `on the ROS 2 forum <https://discourse.ros.org/c/ng-ros>`__ before you start to work on it so that you can identify if someone else is already working on something similar.

source/The-ROS2-Project/Contributing/Developer-Guide.rst

@@ -541,7 +541,7 @@ Don't mix the streams
 
 We strongly recommend against mixing ROS packages from upstream Debian/Ubuntu and from http://packages.ros.org on the same system.
 In some cases such a mixed system will work correctly, but there can be negative interactions between the two sets of packages.
-We’re working with Jochen and friends to minimize the chance of problems via documentation and package conflict specifications, but we expect some risks to remain, including some fairly subtle issues.
+We're working with Jochen and friends to minimize the chance of problems via documentation and package conflict specifications, but we expect some risks to remain, including some fairly subtle issues.
 
 As such, we recommend that you choose to either install packages from upstream or from http://packages.ros.org, but not both.
 Not only should you not install packages from both at the same time, but if you intend to use the upstream packages then you should not even have the http://packages.ros.org entries in your apt sources (i.e. in any files in ``/etc/apt/sources*``).

source/The-ROS2-Project/Contributing/Quality-Guide.rst

@@ -191,7 +191,7 @@ However, this step-by-step is a great place to start!
 
     https://clang.llvm.org/docs/ThreadSafetyAnalysis.html#negative-capabilities
 
-    Negative Capability Analysis lets you specify “this lock must not be held when calling this function”. It can reveal potential deadlock cases that other annotations cannot.
+    Negative Capability Analysis lets you specify "this lock must not be held when calling this function". It can reveal potential deadlock cases that other annotations cannot.
 
     * Where you specified ``-Wthread-safety``, add the additional flag ``-Wthread-safety-negative``
     * On any function that acquires a lock, use the ``RCPPUTILS_TSA_REQUIRES(!mutex)`` pattern