comment out wheels_stop_threshold_sec param section and typos/wording fixes

Signed-off-by: Alberto Soragna <[email protected]>

Author: alsora

docs/api/moving-the-robot.md

@@ -23,9 +23,11 @@ For example, to move the robot straight forward using the ROS 2 command line:
 ros2 topic pub -r 20 /cmd_vel geometry_msgs/msg/Twist "{linear: {x: 0.2, y: 0.0, z: 0.0}, angular: {x: 0.0, y: 0.0, z: 0.0}}"
 ```
 
-The robot will keep executing the last received message until a new message arrives, which will be executed from from now, or a pre-fixed timeout expires without new messages being received.
+The robot will execute the last received message on the topic until a fixed timeout period has passed or a new message is received, at which point the timer is restarted and this process begins again.
 The purpose of the timeout is to provide an easy way to stop the robot, i.e. just stop sending messages rather than having to send an explicit "0", and to prevent the robot to keep moving if it has lost connectivity with the process controlling it (e.g. a script on the user's laptop).
 
+<!---
+THIS PARAMETER IS NOT YET AVAILABLE: uncomment after release
 The timeout is controlled by a ROS 2 parameter provided by the `/motion_control` node and named `/wheels_stop_threshold_sec`.
 This parameter can't be modified at runtime.
 You can change the value of this parameter using the application ROS 2 parameters file exposed by the webserver (see details [here](../webserver/application/#application-ros-2-parameters-file)), for example adding this snippet to the file
@@ -41,10 +43,11 @@ You can read the currently set value using ROS 2 command line tools:
 ```bash
 ros2 param get /motion_control wheels_stop_threshold_sec
 ```
+--->
 
-Note that, these raw velocity commands have lower "priority" than the other request-based approaches to move the robot (described in the next sections).
+Note that these raw velocity commands have lower "priority" than the other request-based approaches to move the robot (described in the next sections).
 The request of a position control or autonomous behavior goal will block the execution of the `cmd_vel` messages, which will be ignored until the goal terminates.
-The corollary is that it's no use to publish `cmd_vel` messages while those are running, you should rather first wait for the behavior to finish or actively cancel it.
+The corollary is that it's of no use to publish `cmd_vel` messages while those are running; you should rather first wait for the behavior to finish or actively cancel it.
 
 ## Position Control
 

docs/api/wall-follow.md

@@ -19,7 +19,7 @@ The spiral will be clockwise if `follow_side` is left (1) or counter-clockwise i
     **If your Create® 3 robot has additional equipment mounted on top, you need to ensure that the obstacles being followed have enough vertical clearance. **
 
 This behavior won't take into account the potentially increased height of the robot, so it may get stuck and damage your equipment or furniture.
-If the obstacles you are trying to follow have gaps from the ground or low-hanging parts, it's required that the vertical clearance is either lower than the robot's base height (roughly 12 cm), such that the robot won't try to get undearneath, or higher than the height of the robot, so that it will fully fit.
+If the obstacles you are trying to follow have gaps from the ground or low-hanging parts, it's required that the vertical clearance is either lower than the robot's base height (roughly 12 cm), such that the robot won't try to get underneath, or higher than the height of the robot, so that it will fully fit.
 
 [^1]: ROS 2 is governed by Open Robotics
 [^2]: All trademarks mentioned are the property of their respective owners.