Implement Al's suggestions

docs/sources/configuration/credentials.rst

@@ -5,15 +5,11 @@ The *Credentials* page is shown in this image:
 
 .. image:: ../data/cpanel1.png
    :width: 800px
-   :alt: Configuration > Credentials: Control Panel page presenting Credentials, Robot name, and Company ID
+   :alt: Configuration > Credentials: Control Panel page presenting Credentials, Robot name
 
-The 3Laws Supervisor is designed to work in conjunction with a cloud-based server.  When you purchase the Supervisor, 3Laws will provide you with the
-credentials to connect to the web-based server and with the official company
-name that is used for your serivces.
+- **Credentials**: 3Laws will provide you with a license key based on the version of Supervisor that you have purchased with an expiration date. If you downloaded the trial version, the expiration date is 60 days from the date when you registered for the trial. If you have arranged with 3Laws to also use the cloud-based dashboards, the license you receive will also include the information necessary for that connection.
+- **Robot Name**: This identifier will be different for each robot where you install Supervisor. It should contain a name you can use to identify an individual robot.
 
-- **Credentials**: 3Laws will provide you with a license key based on the version of Supervisor that you have purchased with an expiration date. If you downloaded the trial version, the expriation date is 60 days from the date when you registered for the trial.  If you have arranged with 3Laws to also use the cloud-based dashboards, the license you receive will also include the information necessary for that connection.
-- **Robot Name**: This identifier will be different for each robot where you install Supervisor.  It should contain a name you can use to identify an individual robot.
-
-The upper-right of the display contains the Rosbridge connection status (upper right), configuration for the Rosbridge (gear next to the status), and a link to this documentation.  There is an "Update Instructions" link in the lower right that brings up a reminder of the instruction to run the installer script.
+The upper-right of the display contains the Rosbridge connection status (upper right), configuration for the Rosbridge (gear next to the status), and a link to this documentation. There is an "Update Instructions" link in the lower right that brings up a reminder of the instruction to run the installer script.
 
 The **Save** button on each page of the Control Panel should be pressed before moving on to another page.

docs/sources/configuration/localization.rst

@@ -1,14 +1,11 @@
 Localization
 ============
 
-Dialogs to connect to the state information provided for the robot and for configuring alerts based on state are on the Configuration > Localization page. contains configuration entries for both the RDM (monitor) and RTA (Copilot) components.
+Dialogs to connect to the state information provided for the robot and for configuring alerts based on state are on the Configuration > Localization page. contains configuration entries for both the monitoring and input filtering components.
 
 .. image:: ../data/cpanel4.png
    :width: 800px
    :alt: Configuration > Localization page where monitoring of the vehicles location/state is configured.
 
 
-- **Localization topic**: The connection to the ROS state topic is configured in this area. As with input commands, the message topic name, message topic type, expected message topic quality, and expected message rates are specified. If the message quality fails or the message receipt rate is not met, the monitor will issue alerts, and the Copilot will switch to the Failsafe strategy.  The mask needs to be customized if the localization topic is a vector of values that is not a standard ROS message.  The index in the input vector relating to the individual states (x, y, yaw) nees to be set correctly.
-
-
-- **Robot state constraints**: Limits on the absolute location (relative to the origin of the world frame) and limits on the measured rates of change (with respect to time) of the vehicle state are set in this area in order to trigger events and alerts for the monitoring function.  The "no bounds" option allows infinite travel in the respective directions or speeds.
+- **Localization topic**: The connection to the ROS state topic is configured in this area. As with input commands, the message topic name, message topic type, expected message topic quality, and expected message rates are specified. If the message quality fails or the message receipt rate is not met, the monitor will issue alerts, and the Copilot will switch to the Failsafe strategy. The mask needs to be customized if the localization topic does not respect the standard ROS message. The index in the input vector relating to the individual states (x, y, yaw) needs to be set correctly.

docs/sources/configuration/perception.rst

@@ -1,23 +1,23 @@
 Perception
 ============
 
-The collision avoidance depends mostly on the Configuration > Perception dialog where the connection and description of either a laserscan sensor or an obstacle map message is configured.
+Collision avoidance uses settings in this dialog to describe the sensors used during operation.
 
 .. image:: ../data/cpanel5.png
    :width: 800px
    :alt: Configuration > Perception page: The laserscan or list of obstacles is configured here.
 
-- **Laserscan sensor**: The Supervisor can handle data points from one 2-dimensional laser (LIDAR) scanner.
+- **Laserscan sensor**: The Supervisor processes data points from a single 2-dimensional laser scanner (LIDAR).
 
-  * **Display name**: A user-specified name can be provided so that diagnostic information can quickly be understood.
+  * **Display name**: This display name is used when aggregated statistics about the scanner are uploaded to the 3Laws cloud dashboard. This name is chosen by the user to help keep track of the scanner, e.g. "front_lidar".
 
-  * **ROS Topic**: The ROS message name, topic type, quality of service and Signal Rate must all be specified so that the Supervisor can subscribe to the sensor data.
+  * **ROS Topic**: Supervisor needs to subscribe to the ROS message published by the LIDAR, so this topic name (plus type, quality-of-service, and expected signal rate) need to match the sensor's output. *ros2 topic * with options *list, info, hz" can be useful to obtain this information.
 
-  * **Specs**:  The expected number of points per scan along with the first (typically minimum) and last (typically maximum) angle must be specified so that the angular resolution can be calculated for the nominal case. The first and last angle values should normally describe a laser that scans in the clockwise direction, so the first is smaller than the last. However, if the laser scans in the counter-clockwise direction the first angle should be set to be smaller than the last.  It is very important that the total range of the laser is less than 2π.  The Supervisor does not disambiguate angles if the total field is larger than 2π.  The scanner's range can be set so that readings smaller than the minimum or larger than the maximum are discarded.
+  * **Specs**:  The expected number of points per scan along with the first (typically minimum) and last (typically maximum) angle must be specified so that the angular resolution can be calculated for the nominal case. The first and last angle values should normally describe a laser that scans in the clockwise direction, so the first is smaller than the last. However, if the laser scans in the counter-clockwise direction the first angle should be set to be smaller than the last. It is very important that the total range of the laser is less than 2π. The Supervisor does not disambiguate angles if the total field is larger than 2π. The scanner's range can be set so that readings smaller than the minimum or larger than the maximum are discarded.
 
   * **Laserscan Pose**: The orientation and position of the laserscan relative to the vehicle body or whichever frame is used must be specified. As with the robot's body position, the user is advised to plot the data in rviz to ensure that the geometry is set correctly.
 
-- **Obstacle Map**: An existing perception system can be used instead of a 2D-LIDAR, but it most provide an ObjectArray that matches the definition for an lll_rsgs/ObjectArray.  The definition is as follows:
+- **Obstacle Map**: An existing perception system can be used instead of a 2D-LIDAR, but it most provide an ObjectArray that matches the definition for an lll_msgs/ObjectArray. The definition is as follows:
 
 .. code::
 
@@ -27,7 +27,7 @@ The collision avoidance depends mostly on the Configuration > Perception dialog
 where Object[] is defined by:
 
 .. code::
-          
+
   std_msgs/Header header
   # Identifier of the object
   string id

docs/sources/configuration/robot_model.rst

@@ -8,22 +8,22 @@ The Configuration page for the Robot Model is where the robot's geometry and kin
 
 Throughout this documentation, a red asterisk (*) indicates a *required* field.
 
-- **Kinematics**: Supervisor currently supports differential drive, front-steered, and omni-directional mobile platforms.  A differential drive vehicle can rotate around a fixed location by driving one wheel forward and its pair in reverse. It can move forward or backwards by driving both wheels in the same direction.  A front-steered vehicle operates like a car or bicycle. It can move forwards or backwards, but direction is controlled by steering, and the vehicle has a fixed wheelbase distance between the forward axle and the rear axle. An omni-directional robot is usually implemented using wheels that have a series of smaller wheels mounted at 45 degrees on the outer rim.  By moving one axle forward and others backwards, the vehicle can move sideways. Rotation can be effected by moving the wheels on one side forwards and the wheels on the other side in reverse.
+- **Kinematics**: Supervisor currently supports differential drive, front-steered, and omni-directional mobile platforms. A differential drive vehicle can rotate around a fixed location by driving one wheel forward and its pair in reverse. It can move forward or backwards by driving both wheels in the same direction. A front-steered vehicle operates like a car or bicycle. It can move forwards or backwards, but direction is controlled by steering, and the vehicle has a fixed wheelbase distance between the forward axle and the rear axle. An omni-directional robot is usually implemented using wheels that have a series of smaller wheels mounted at 45 degrees on the outer rim. By moving one axle forward and others backwards, the vehicle can move sideways. Rotation can be effected by moving the wheels on one side forwards and the wheels on the other side in reverse.
 - **Geometry**: The vehicle's reference coordinate frames and geometry are specified in this section.
 
-  * **Shape Details**: The robot's shape is used in order to calculate the distance between the outer boundaries of the robot body and any scan points.  Basic shapes that are currently supported include sphere, box, capsule, point, cone and cylinder.  The size entries change based on the selected shape. Cylinders and capsules both require length and radius. The difference is that a capsule will have hemispheres on the ends while the cylinder ends are flat. A box frame consists of x-length, y-length, and z-length.
+  * **Shape Details**: The robot's shape is used in order to calculate the distance between the outer boundaries of the robot body and any scan points. Basic shapes that are currently supported include sphere, box, capsule, point, cone and cylinder. The size entries change based on the selected shape. Cylinders and capsules both require length and radius. The difference is that a capsule will have hemispheres on the ends while the cylinder ends are flat. A box frame consists of x-length, y-length, and z-length.
 
-   * **Shape Pose in Robot Frame**: The relative orientation of the robot's shape with respect to the base frame needs to be specified. Note that the rotation can be specified either using quaternions or Euler angles. The quaternion order is w, x, y, z.  When Supervisor is running, it is a good idea to run rviz (or rviz2) to display the orientations and frames.
+   * **Shape Pose in Robot Frame**: The relative orientation of the robot's shape with respect to the base frame needs to be specified. Note that the rotation can be specified either using quaternions or Euler angles. The quaternion order is w, x, y, z. When Supervisor is running, it is a good idea to run rviz (or rviz2) to display the orientations and frames.
 
-  * **Frames**: The name of the robot base coordinate frame must be specified here. The base frame is in robot body-coordinates. It moves in space as the robot does.  Additional static frames can be defined by clicking the + icon. The additional frames are static, and will follow the motion of the base robot frame.
+  * **Frames**: The name of the robot base coordinate frame must be specified here. The base frame is in robot body-coordinates. It moves in space as the robot does. Additional static frames can be defined by clicking the + icon. The additional frames are static, and will follow the motion of the base robot frame.
 
 - **Dynamics**: The Dynamics section has 3 subsections: Input, Parameters, and State.
 
   * The Input section supports specification of maximum and minimum limits for the translational and rotational speeds at which the robot can be commanded. For monitoring, if these values are exceeded, an event to this effect will be issued. If the Copilot component is active, these limits will be applied to the filtered outputs. For steered vehicles, instead of limits on rotational speeds, steering limits are specified.
 
   * **Parameters**: The only robot type that has inputs in the parameters section is the steered robot. *wheel_dx* is the wheelbase length for the vehicle. *origin_x* is the distance from the rear axle to the robot base frame.
 
-  * **State**: For all robot types, the State category provides the definitions of the variables that are considered as the "states".  These definitions are important when trying to create "masks" to map between the input ROS variable types and the robot states.  The first, is considered state 0 (typically x position), the second is state 1 (typically y position) and the third is state 2 (typically yaw).
+  * **State**: For all robot types, the State category provides the definitions of the variables that are considered as the "states". These definitions are important when trying to create "masks" to map between the input ROS variable types and the robot states. The first, is considered state 0 (typically x position), the second is state 1 (typically y position) and the third is state 2 (typically yaw).
 
 .. important::