Merge pull request #173 from clearpathrobotics/development

README.md

@@ -57,20 +57,22 @@
 6.  Resolve any errors that the terminal reports, and rerun the command `npm run build`.
 7.  Finally, check that your updates adhere to our code formatting standard, by running the command `npm run format-check`.
     The terminal will either report:
+
     - _All matched files use Prettier code style!_
     - _Code style issues found in the above file(s). Forgot to run Prettier?_
       You can fix the errors by running Prettier on a single file, with `npx prettier --write <FILE PATH>`.
       For example, you can run the command `npx prettier --write README.md` to format this README.
+
       - Refer to the _package.json_ to understand what this script calls.
       - Refer to the _.prettierrc.json_ to understand the rules Prettier is using when checking files.
-      
+
       Note, we used to suggest the command `npm run format-write` to update all the files in this repository.
       We don't suggest this command anymore, since it is then difficult for reviewers of Pull Requests to find the intended content changes.
       If you do continue to use this entire repositry command, you may see files that claim to be updated in Source Control, but don't have any visible changes.
       If so, you should run these commands in your terminal to prevent Git from noting these types of changes:
 
-        git config --global core.filemode false
-        git config --global core.autocrlf false
+      git config --global core.filemode false
+      git config --global core.autocrlf false
 
 8.  When ready, publish your branch on GitHub, and submit a Pull Request to merge your changes into the _development_ branch.
     Pull Requests to the _production_ branch will not merged.
@@ -258,7 +260,8 @@ Follow this process to keep the _development_ and _production_ branches aligned,
 4.  After the Pull Request has been approved, you can merge it using the Create-a-Merge-Commit option.
     You should not use the Squash-and-Merge option here, otherwise _production_ will not have the latest commits from _development_, which were created in step 1 of this list. The source data will be the same on the 2 branches, but the commit hashes will not be aligned.
 
-     The Create-a-Merge-Commit option prevents this issue, by adding all the commits from _development_ to _production_, and also adding a commit to _production_ that mentions the Pull Request.
+    The Create-a-Merge-Commit option prevents this issue, by adding all the commits from _development_ to _production_, and also adding a commit to _production_ that mentions the Pull Request.
+
 5.  _production_ has been updated, but it is one commit ahead of _development_.
     We want to update _development_ so we do not experience rebase issues next time we want to update the _production_ branch.
     To update _development_, go to VS Code:
@@ -268,7 +271,7 @@ Follow this process to keep the _development_ and _production_ branches aligned,
     4.  Run `git rebase production`.
         This should pull one commit into _development_. It should be the commit related to merging the Pull Request.
     5.  Force Push this commit to the _development_ branch on GitHub.
-        Note: our branch protection rules in the GitHub repository only allow Administrators and Owners to Force Push to the _production_ and _development_ branches.    
+        Note: our branch protection rules in the GitHub repository only allow Administrators and Owners to Force Push to the _production_ and _development_ branches.
 
 ## How does the deployed website get updated?
 

components/introduction_husky_observer.mdx

@@ -0,0 +1,8 @@
+<center>
+  <img
+    src="/img/robot_images/husky_observer_images/husky_observer_banner.png"
+    width="400"
+  />
+</center>
+
+---

docs/robots/accessories/manipulators/kinova_gen3_lite.mdx

@@ -18,7 +18,7 @@ import TabItem from "@theme/TabItem";
 
 | Description                       |                         CPR Item                         |
 | :-------------------------------- | :------------------------------------------------------: |
-| Kinova Gen3 lite Bundle           | [022586](/assets/pdf/clearpath_robotics_015822-TDS1.pdf) |
+| Kinova Gen3 lite Bundle           | [022586](/assets/pdf/clearpath_robotics_022586-TDS2.pdf) |
 | Kinova Gen3 lite, PACS™ kit |                          027219                          |
 
 ---

docs/robots/indoor_robots/boxer/user_manual_boxer.mdx

@@ -215,7 +215,7 @@ Pull the robot out of the crate by hand, and then roll the robot down the wood r
       />
     </center>
 3.  Wait for the system to boot.
-    The Boxer's lights will go through a sequence of colors during this process:
+    The Boxer's lights will go through a sequence of colours during this process:
 
     - All white for approximately 30 seconds
     - All red for approximately 30 seconds

docs/ros/config/live.mdx

@@ -11,27 +11,33 @@ Users familiar with Clearpath's robots, know we provide desktop packages that fa
 This functionality requires a desktop manager to be installed; in other words, these commands will not work on robot computers since these run Ubuntu 22.04 server rather than desktop.
 
 # Installation
+
 Install the desktop packages using `apt`. Make sure to have [added Clearpath packages](https://packages.clearpathrobotics.com/) to the source list before installation.
+
 ```bash
 sudo apt install ros-humble-clearpath-desktop ros-humble-clearpath-config-live
 ```
 
 # Setup
+
 Before running the node, we will need to setup the working directory.
 First, create the directory `/etc/clearpath`.
 Then, copy your `robot.yaml` to `/etc/clearpath/robot.yaml`.
 
 # Run the Node
+
 Running `view_model.launch.py` will generate the URDF of the robot from the `/etc/clearpath/robot.yaml` and then start RViz.
 
 It will then monitor the `/etc/clearpath/robot.yaml` for changes. Whenever changes are detected, the URDF will be regenerated and the RViz model will be updated.
 
 To run the node:
+
 ```bash
 ros2 launch clearpath_viz view_model.launch.py
 ```
 
 # Example
+
 Starting off with the default A200 Husky YAML, we switch the top plate, add the sensor arch, a fath pivot mount, and finally a RealSense. Every time we want changes to take effect, we save the file. If after saving no changes take place, then it's an indication that these were invalid.
 
 <center>

docs/ros/config/yaml.mdx

@@ -131,7 +131,7 @@ sensors:
         camera:
           camera_name: camera_0
           device_type: d435
-          serial_no: '0'
+          serial_no: "0"
           enable_color: true
           rgb_camera.profile: 640,480,30
           enable_depth: true
@@ -267,8 +267,8 @@ There are three types of attachments:
 
 1. **bumpers** modify the front face and rear face of the robot platform.
 2. **fenders** modify the area above the wheels on the front and rear of the platform.
-2. **top_plates** modify the top face of the robot platform.
-3. **structures** are large custom parts that are added atop the top plate.
+3. **top_plates** modify the top face of the robot platform.
+4. **structures** are large custom parts that are added atop the top plate.
 
 #### Husky A200 {#attachments-a200}
 
@@ -352,11 +352,13 @@ extras:
 ```
 
 #### ROS Parameters
+
 A common use case is to set and update the parameters to the `platform_velocity_controller` node. These can be used to modify the linear and angular velocity and acceleratation.
 
 These can be passed in as follows:
 
 **A200 Husky Controller Defaults:**
+
 ```yaml
 platform:
   extras:
@@ -373,8 +375,8 @@ platform:
         platform_velocity_controller.angular.z.min_acceleration": -6.0
 ```
 
-
 **J100 Jackal Controller Defaults:**
+
 ```yaml
 platform:
   extras:
@@ -641,6 +643,7 @@ fath_pivot:
 ```
 
 - **sick:** are mounts specifically designed to mount SICK LiDARs. The orientation of the LiDAR on the mount can be set to either `upright` or `inverted`.
+
 ```yaml
 sick:
   - parent: base_link
@@ -650,6 +653,7 @@ sick:
 ```
 
 - **post:** are vertical extrusion rails to which sensors can be added.
+
 ```yaml
 post:
   - parent: base_link
@@ -661,6 +665,7 @@ post:
 ```
 
 - **disk:** are circular plates which are used to mount circular sensors, i.e. the Velodyne
+
 ```yaml
 disk:
   - parent: base_link
@@ -813,6 +818,7 @@ gps:
 ```
 
 - **_garmin_18x_**
+
 ```yaml
 gps:
   - model: garmin_18x
@@ -829,6 +835,7 @@ gps:
 ```
 
 - **_novatel_smart6_**
+
 ```yaml
 gps:
   - model: novatel_smart6
@@ -845,6 +852,7 @@ gps:
 ```
 
 - **_novatel_smart7_**
+
 ```yaml
 gps:
   - model: novatel_smart7
@@ -897,6 +905,7 @@ imu:
 ```
 
 - **_redshift_um7:_**
+
 ```yaml
 imu:
   - model: redshift_um7
@@ -1064,7 +1073,7 @@ camera:
       camera:
         camera_name: camera_0
         device_type: d435
-        serial_no: '0'
+        serial_no: "0"
         enable_color: true
         rgb_camera.profile: 640,480,30
         enable_depth: true
@@ -1097,7 +1106,7 @@ sensors:
         camera:
           camera_name: camera_0
           device_type: d435
-          serial_no: '0'
+          serial_no: "0"
           enable_color: true
           rgb_camera.profile: 640,480,30
           enable_depth: true
@@ -1136,7 +1145,6 @@ sensors:
           model: VLP16
           fixed_frame: lidar3d_0_laser
           target_frame: lidar3d_0_laser
-
 ```
 
 </p>

docs_outdoornav_user_manual/api/api_endpoints/autonomy_api.mdx

@@ -79,6 +79,14 @@ status, and whether the robot is dead reckoning.
 
   **Description:** Result topic from the mission action.
 
+#### /navigation/cmd_vel
+
+  **Message Type:** geometry_msgs/Twist
+
+  **Description:** This output commanded velocity from the autonomy
+software (OutdoorNav) to control the velocity of the platform. It is
+commonly relayed directly into the UGV's velocity controller.
+
 #### /navigation/distance_to_goal
 
   **Message Type:** [clearpath_navigation_msgs/DistanceToGoal](definitions#msg-distance-to-goal)
@@ -187,14 +195,6 @@ between the robot and the reference path) and as well as the heading
 error (ie. the difference between the current heading and the path
 direction).
 
-#### /navigation/cmd_vel
-
-  **Message Type:** geometry_msgs/Twist
-
-  **Description:** This output commanded velocity from the autonomy
-software (OutdoorNav) to control the velocity of the platform. It is
-commonly relayed directly into the UGV's velocity controller.
-
 #### /safety/safety_stop
 
   **Message Type:** std_msgs/Bool
@@ -326,6 +326,12 @@ The new dock will appear on the UI.
   **Description:** Remove and existing dock from the database. Input to this service requires ether the UUID
 or the semantic name of the dock.
 
+#### /dock/clear_data
+
+  **Service Type:** [std_srvs/srv/Trigger](definitions#srv-clear-dock-data)
+
+  **Description:** Remove all existing dock data from storage.
+
 #### /dock/set_location/by_id
 
   **Service Type:** [clearpath_dock_msgs/srv/SetDockLocationByID](definitions#srv-set-dock-location-by-id)
@@ -351,12 +357,11 @@ localization according to the current sensor readings. If you are
 sending a mission to the UGV without using the UI and through the API,
 you must call this service before sending the mission.
 
-#### /localization/set_pose (IN DEVELOPMENT)
+#### /localization/reset
 
-  **Service Type:**
+  **Service Type:** [clearpath_localization_msgs/srv/ResetLocalization](definitions#srv-reset-localization)
 
-  **Description:** This service can be used to reset or reinitialize the
-localization of the UGV.
+  **Description:** This service can be used to trigger a reset of the UGVs localization.
 
 #### /navigation/set_collision_avoidance